| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | javascript |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | accessibility, aria |
Issue Summary
This is a minor spinoff of #448292: Drag and Drop for table rows is not accessible to screen-reader users.
It was pointed out there (e.g., http://drupal.org/node/448292#comment-1911038) that having keyboard controls for table drag-and-drop only make use of the arrow keys is a problem for screen readers, since some screen reader software programs hijack the arrow keys for their own purposes.
We can easily address that problem by allowing an additional set of keys to control the tabledrag as well. In this patch, I chose 'i', 'j', 'k', and 'm' for up/left/right/down, respectively. I picked this somewhat randomly, due to their location on the keyboard, but obviously we can use a different set if there is a better or more standard one.
The arrow keys of course will continue to work - this patch just adds an additional, alternative set.
This patch doesn't address the documentation of using these keys (since better documentation or instructions for keyboard use of drag-and-drop is probably its own issue). It also won't completely solve the accessibility problem for screen reader users by any means (there are still a number of reasons why drag-and-drop is problematic for screen readers, discussed more fully in the issue linked to above); however, it should help at least a little bit.
Comments
#1
Here is the patch.
#2
I think WSAD is the most standard combo for simulating arrow keys (apart from hjkl - finally a vi mode for drupal? ;)
#3
If you use wsad will drupal convert zsqd to wasd ;)
Else that combination is useless :p
#4
The last submitted patch, tabledrag-keyboard-819724-1.patch, failed testing.
#5
Hard to imagine that test failure is real, so I'm setting it back to "needs review"...
Googling WSAD a bit, I can't figure out if it's standard everywhere or just in video games? :) Seems like it makes sense for video games because it's on the left side of the keyboard, so for a two-player game one person can use the arrow keys on the right side and the other can use WSAD on the left. I don't know if it makes as much sense for us - seems like we'd just be biasing Drupal towards left-handed people or something :) But if it really is somewhat standard, that's what we should go with.
#6
Just adding an accessibility tag.
Thanks for opening this based on an early comment back in that other thread! Hopefully we can bring this in with some review from AT users.
#7
JFTR
Keyboard Navigation - Resources & Best Practices
#8
#1: tabledrag-keyboard-819724-1.patch queued for re-testing.
The only error was SQL related with setting up the test database.
#9
Hehe, for a bit I thought J-F-T-R were the four keys you were suggesting to use, but then eventually realized it stood for "just for the record" :)
That is a great set of resources. I poked around a couple of them a bit (not extensively) but didn't see anything that referred to specific alternatives to the arrow keys... do you know of anything in that list that would talk about that?
#10
@David
It's been a while since I assembled all those links and admittedly I haven't read everything thoroughly but AFAIR - no, that's not another suggestion for the keys to use ;-) - there's no real consensus on which keys to use alternatively. I think JIKM is a good solution.
NB: From the discussion on Accessibility improvements for vertical tabs I remember that arrow keys have their pre-defined behavior within a form where they usually toggle between radio buttons but I suppose this is catered for already by the drag&drop feature.
#11
It is quite difficult to find free keys for screenreader users. J for example, opens the 'Jump to Line' dialog and K jumps to the next place marker. These keys are only passed to the browser in forms mode (when interacting with a form element), or when in application mode (ARIA applications).
#12
I'm wondering if we should mark this as "Won't fix".
Is this something that should be managed in a module rather than in core?
Doesn't look like it will be dealt with in D7 in any case, so bumping it up to D8 for now.
#13
We'll leave it postponed for D8 at the moment. It would be nice to add aria-live support in D8, along with an alternate set of keys, so that tabledrag can be accessible to screen-reader usres without needing to switch the table into 'show weights' mode.
#14
If it's already for D8, there's no need to postpone it also. That just guarantees that people will forget it exists when D8 development rolls around :)
(Unless there's already some D8 issue for the aria-live stuff, in which case I guess it could be postponed on that one.)
#15
Can this be brought into D7 using the Accessible Helper Module?
#16
Changed the title and slight repurposing of this issue.
When screen-readers are in virtual document (virtual buffer) mode it is tricky to find keys to use that are not already used by the screen-reader, and thus not passed to the UA. We should look at finding a way to improve tabledrag accessibility using WAI-ARIA for users with supporting screen-readers.
1. Users can interact with tabledrag as they do now.
2. Users who cannot use drag, or do not have ARIA compliant screen-readers can "Show row weights"
3. Users with ARIA compliant screen-readers can use the enhancements we will add
We can take some ideas from the Fluid Infusion reorderer widgets at http://fluidproject.org/releases/1.3.1/demos/
#17
I have not tested it at all, but the jQuery tree table plugin http://ludo.cubicphuse.nl/jquery-plugins/treeTable/doc/index.html#examples claims to be able to do drag and drop reordering w/ parent child relationships. This plugin is used in token module, and it might be nice to assess needs of table drag and see if improving the accessibility of this plugin would allow it to be used in core.
#18
Adding tag for WAI-ARIA.
#19
#1: tabledrag-keyboard-819724-1.patch queued for re-testing.
#20
The last submitted patch, tabledrag-keyboard-819724-1.patch, failed testing.