Jump to:
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | javascript |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
| Issue tags: | accessibility, screenreader, Usability |
Issue Summary
During Everett Zufelt's talk on "accessibility in D7" at DrupalCamp Montreal, he highlighted some D7 critical issues due to the javascript being inaccessible:
#448292: Drag and Drop for table rows is not accessible to screen-reader users
#567192: Clean up Javascript implementation of Expanding simpletest groups
#323112: Vertical Tabs
If Javascript is entirely disabled, these are not problems, but as Everett pointed out, he shouldn't have to disable all javascript and lose all of the other working items, merely because certain ones fail to be accessible.
Discussing this with him and @webchick, I was inspired with a solution...
Proposed:
If Drupal 'accessible_mode' is true (via session variable or preference), Drupal sets a javascript variable 'accessible_mode' to true for the page. Javascript which isn't 100% accessible checks for this variable first thing, top of the relevant functions, and if true, code stops running, falling back to the non-javascript accessible method otherwise on the page already.
This would disable _only_ those items that don't meet accessibility requirements, leaving the other javascript on the page alone to run correctly.
Requirements:
- One line of code added to any inaccessible scripts (the 3 above, for starters).
- A front page link, "Increase Accessibility" at top of page, to turn this feature on, for screenreaders. Using the new 'invisible' element, this would only appear for screenreaders and others using accessibility tools to begin with. If clicked, sets Drupal into accessible mode (session variable) and then no longer appears on front page once that mode is on. Link to turn off now appears very bottom of page (just in case?)
- (Optional) Also appear on pages where referrer is external, to catch new visitors.
- (Optional - contrib?) A site setting variable "Accessibility mode" (true/false), set by the admin, sets entire site to this mode globally, no click required. aka "Never run known inaccessible javascript on my site"
- (Optional - contrib?) A user setting to match, for per user turn on preference.
Benefits:
- Add one line of code to the top of any javascript that isn't 100% accessible, and it now will go away when need be.
- Contrib maintainers could use this as well, especially while no patch exists to solve an accessibility problem.
- Contrib items impossible to make easily accessible (true "visual only" items) could handle this more gracefully rather than just not work at all.
The solution proposed in #448292: Drag and Drop for table rows is not accessible to screen-reader users is to add this sort of 'turn off' link before every Drop and Drag table, only for that one table. A global solution would be cleaner, imho.
Disadvantages:
- Could discourage actually fixing the accessibility issues with the javascript version, since a workaround would exist.
I am NOT proposing NOT fixing the accessibility of individual items. Please don't read the above as if I am. This is not meant to avoid fixing inaccessible javascript, merely to turn it off for those who can't use it, until/if it is made more accessibility. Normal bug reports would still be appropriate, but the workaround would prevent these from being marked critical.
Feedback?
Since accessibility bugs are still fair game... Worth coding this up?
Comments
#1
minor correction: the proposed Drop and Drag patch doesn't "turn off", but re-adds the previous hidden weight fields.
That sort of behavior is still easily controlled thru an 'accessible_mode' variable being set, rather than requiring an individual link for each table.
#2
I attended Everett Zufelt's discussion in Montreal as well. I agree with Seth that this appears to be a viable solution.
#3
subcribe
#4
So what actually changes in the interface, for a non-disability person?
#5
I would suggest implementing that as a javascript-only solution. After all, if the problem is javascript, the solution is also javascript. Moreover, it will allow us not to modify anything in the page itself (preserving stuff like cacheability of the page, etc.).
#6
I'd much rather have the energy invested in making the tools more accessible rather than writing what seems like a hack to disable them.
There are also a range of different accessibility challenges. Not sure that disabling Javascript will work for all. Vertical tabs for instance has problems with keyboard only users.
Drag & Drop does need to have either a user based or session based means to turn it off. The javascript one that has been developed has limitations.
Simpletest should be re-using the expand/collapse fieldset solution here - http://drupal.org/node/541568
There are still a lot of accessibility issue to focus on - http://drupal.org/project/issues/search/drupal?text=&assigned=&submitted=&participant=&status[]=Open&version[]=7.x&issue_tags_op=or&issue_tags=accessibility
reviewing, these is very worthy and yes there still is time for accessibility issues in D7.
#7
I might well be wrong about what's the best way to address this, see http://drupal.org/node/448292#comment-2254630
If the problems are introduced because of bad javascript, maybe it's ok to have a way using javascript to just turn them off.
Still would rather have more accessible tools, but....
#8
Sorry, but this is won't fix for me. Core needs to ensure our stuff is accessible; can't take the 'lazy' way out.
But it'd be possible for a contrib module to add such a feature with hook_js_alter().