Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.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.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | tabledrag-keyboard-819724-1.patch | 2.22 KB | David_Rothstein |
Comments
Comment #1
David_Rothstein CreditAttribution: David_Rothstein commentedHere is the patch.
Comment #2
Frando CreditAttribution: Frando commentedI think WSAD is the most standard combo for simulating arrow keys (apart from hjkl - finally a vi mode for drupal? ;)
Comment #3
aspilicious CreditAttribution: aspilicious commentedIf you use wsad will drupal convert zsqd to wasd ;)
Else that combination is useless :p
Comment #5
David_Rothstein CreditAttribution: David_Rothstein commentedHard 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.
Comment #6
mgiffordJust 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.
Comment #7
Frank Ralf CreditAttribution: Frank Ralf commentedJFTR
Keyboard Navigation - Resources & Best Practices
Comment #8
Frank Ralf CreditAttribution: Frank Ralf commented#1: tabledrag-keyboard-819724-1.patch queued for re-testing.
The only error was SQL related with setting up the test database.
Comment #9
David_Rothstein CreditAttribution: David_Rothstein commentedHehe, 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?
Comment #10
Frank Ralf CreditAttribution: Frank Ralf commented@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.
Comment #11
Everett Zufelt CreditAttribution: Everett Zufelt commentedIt 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).
Comment #12
mgiffordI'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.
Comment #13
Everett Zufelt CreditAttribution: Everett Zufelt commentedWe'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.
Comment #14
David_Rothstein CreditAttribution: David_Rothstein commentedIf 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.)
Comment #15
mgiffordCan this be brought into D7 using the Accessible Helper Module?
Comment #16
Everett Zufelt CreditAttribution: Everett Zufelt commentedChanged 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/
Comment #17
Everett Zufelt CreditAttribution: Everett Zufelt commentedI 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.
Comment #18
mgiffordAdding tag for WAI-ARIA.
Comment #19
mgifford#1: tabledrag-keyboard-819724-1.patch queued for re-testing.
Comment #21
bowersox CreditAttribution: bowersox commented@Everett Zufelt, @mgifford, @leenwebb and @bowersox discussed this at Drupal Accessibility Sprint.
We are setting closed (won't fix). Accessible Drag-n-drop in ARIA and HTML5 is years away from being supported by browsers and assistive technology. Everett suggests it could be 5 years away.
@David_Rothstein's original issue (before this issue was repurposed about ARIA), was all about keyboard mappings to try to make the drag-n-drop interface better for screenreader users. Everett feels that there is no way to improve this because so many screenreaders map so many keys for their own purposes. The way for screenreader users to currently use tabledrag is the 'show row weights' mode.
If anyone feels strongly otherwise, maybe we can talk about proposed improvements during one of our monthly Accessibility Skype meetings.