Drag and Drop for table rows is not accessible to screen-reader users
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | admin.module |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | needs review |
| Issue tags: | accessibility, screenreader, Usability |
hi.
I have been following all the issues with the accessibility tag, and I find this to be a very nice gesture from the community to be accessibility aware. I have been using drupal since the days of 4.6 until today, doing all sorts of websites using a screen reader only.
the biggest threat in the drupal system to me has always been the absolute inability to arrange fields by drag and drop like arranging blocks, menus, etc. I know though that this feature is very attractive and user friendly to those who don't depend on screen readers.
that's why I don't know what we could do to conpensate for this and at the same time keeping that attractive feature in place. it's the only thing that I have to ask for sighted assistance to do in the whole system. perhaps an optional alternative setting to use the old good combo boxes for determining weight?
thanks.
#1
Some threads on this here:
http://groups.drupal.org/node/18563#comment-64225
http://groups.drupal.org/node/15695
Just having a link where you can disable the javascript would also be useful to deal with ordering lists that are broken by pagination. Large lists really don't work all that well with the drag/drop concept in my opinion.
Think that http://groups.drupal.org/user/33730 had some ideas on this at Drupalcon, but can't remember the details.
Mike
#2
Hi all,
We should take a look at Fluid Project. See below links.
Drag and Drop Pattern - Fluid Project Wiki
http://wiki.fluidproject.org/display/fluid/Drag+and+Drop+Design+Pattern
Shiny New API for the Reorderer (blog)
http://fluidproject.org/blog/2008/05/29/shiny-new-api-for-the-reorderer/
Layout Reorderer Specification - Fluid Project Wiki
http://wiki.fluidproject.org/display/fluid/Layout+Reorderer+Specification
Thanks,
Mike
#3
Thanks Mike,
I was a bit worried that this was a project that had been hibernating for the last couple months, but found some good demos of this code:
I think this meets the needs we have with reordering the lists.
http://www.fluidproject.org/releases/1.0/standalone-demos/quick-start-ex...
They have lots of other interesting demos here:
http://fluidproject.org/products/fluid-infusion/infusion-demos/
In the Download of the 1.0 version though:
http://fluidproject.org/products/fluid-infusion/download-infusion/
I am a bit concerned thought that there will be a license conflict that will stop it from being included with Drupal:
http://wiki.fluidproject.org/display/fluid/Fluid+Licence
It's a neat model though. Definitely when looking at where http://www.d7ux.org/ is taking Drupal 7.
Some other traffic on fluid here - http://groups.drupal.org/node/7750
Mike
#4
Just turning off the javascript has been an issue that has been brought up before. Seems the page uses progressive enhancement and if the javascript can be turned off you can still edit/order the page.
Not that the labels for the checkboxes are all that understandable:
<label class="option" for="edit-mlid:1259-hidden"><input type="checkbox" name="mlid:1259[hidden]" id="edit-mlid:1259-hidden" value="1" checked="checked" class="form-checkbox" /> </label>And the select boxes for weight don't seem to even have any labels associated with them.
But it is editable if you spent a bunch of time trying to figure out the grid (from what I've been told).
The function drupal_add_tabledrag() could be modified to allow a user to insert a session variable (say something like $_SESSION['tabledrag'] = 'disabled';) which would disable the tabledrag options for that users session. Seems like a hack compared to the fluid solution, but for a few reasons it is worth considering I think.
I'm thinking that the menu page could have a link like:
echo t('You can disable the drag & drop.', array('@drag' => url('admin/accessibility/dragdrop_disable')));
About here /admin/build/menu-customize/main-menu which would enable/disable this.
Wouldn't be an ideal approach though.
#5
Hm. We built keyboard support into drag and drop. Are you saying this doesn't work for you? Or are you saying it works, but doesn't help because you have no concept of what you just moved it above or below?
#6
hi Webchick! what do you mean by: "We built keyboard support into drag and drop." that doesn't work for me at all. was that a new feature in d7? other than the fact that I have no concept where I'd moved the menu, block, etc, I can't do anything to drag and drop using my keyboard. all I can do is click "drag" which doesn't apeare to do anything, or so my screen reader makes me think.
#7
No, this was added in Drupal 6. It was a prerequisite to the feature getting committed because we would never want to leave unsighted users in the cold!
In Safari, what I do to activate this is opt+tab to the drag and drop handler (It has alt text of "Drag to re-order") and press the up/down keys. Then it will move the current table row above/below other rows in the table, and also between regions.
On pages such as menu and taxonomy, which support a hierarchy as well as weighting, the left and right arrow keys work as well.
I have not tried this in something like JAWS, however...
#8
For menu items you can still do it the old fashioned way by setting weight when editing a menu item, however I found it hard to know exactly what I was editing.
I was able to configure my blocks with the keyboard, however only because I am sighted. Listening to my screen reader I get zero feedback about about which block is which. I have no idea which block I am actually changing. When you tabbing through the blocks page the first link you get is the drag and drop handle - screen reader says "Blank". There is no feedback that it is a widget and that I can do something with it.
The lack of labels is an accessibility barrier. For example for check boxes the only feedback I get from NVDA is "check box, not checked". Check box for what?
If I could choose the region and weight when editing the actual block that would improve things a lot, at least I would have a way to get it done.
BTW, does anyone know if the keyboard shortcuts for drag and drop for Windows are documented, I haven't got a clue how this is supposed to work.
#9
hey Webchick,
thanks alot for the hint. guess what? that really does work with a screen reader. but I had to be careful and count my presses because my screen reader had no clue I was moving the block. so it works by trial and error now, much better than nothing at all. the thing is that we are never used to treating links like we do combo boxes.
that said, I don't think it's at all an elegant way for us because it's not documented. had I not raised this issue I probably wouldn't have known.
can't we treat blocks like we treat pages such as menu and taxonomy, and make it support a hierarchy as well as weighting?
#10
Glad to see that this issue is document here. As a screen-reader dependent Drupal developer this is the first major accessibility issue that I noticed with the administrative interface.
I have set this issue to Bug Fix and Critical as it completely blocks my ability to successfully administer sites, without disabling JS in my browser and guessing at form fields.
1. Providing an option to switch between the drag and drop, and weighted user interfaces would be a good first step at addressing this issue from both an accessibility and usability perspective. I have had many other Drupal developers tell me that the drag and drop interface is less than ideal for long lists of content.
2. If they currently are not, the form fields used for the weighted reorder need to be properly labeled.
3. Having done some work with Fluid Project I will say that their reorder is in good working state, but I have not tested it thoroughly enough to recommend it for this interface. Fluid Project is currently looking into compatibility between their BSD license and the GPL. If this is to be implemented it would likely be best to modularize the Fluid Infusion http://fluidproject.org/products/infusion/ product for inclusion in core.
4. It is also possible to learn from Fluid's reorder widget and to apply appropriate ARIA markup to the drag and drop interface that currently exists, presuming that the keyboard only functionality is accessible to AT on more than one OS, not tested.
#11
I have checked and it appears that it would be a great deal of work to get Fluid's Infusion (aria toolkit) into d7, even as a contributed module. Drag-and-drop is a core issue and requires a core solution.
AFAIK, the following D7 UIs implement a drag-and-drop interface: administer/blocks, administer/menu, administer/taxonomy, administer/cck, administer/content type, administer/forum
Are there any UIs that I have missed? And, can someone please provide a description of what drag-and-drop is used for in each of these UIs?
#12
Going to start looking into adding a control to UIs that have drag-and-drop functionality to allow administrators to select to use the non-drag-and-drop UI. A couple of questions:
1. Should state be retained: a. only for the particular page visit, b. for the session, c. until the administrator chooses to switch back to drag-and-drop mode?
2. What type of control would work best: a. link, b. select, c. radio / checkbox?
Thanks for any input.
#13
See the solution at Views 1 interface, regarding reordering list items. It's going to be a though thing to push forward if this patch adds another UI element to the already pretty filled table.
#14
Renamed issue for better clarity
Resource
I found that a lot of the code responsible for this can be found in /misc/tabledrag.js
#15
Subscribe
#16
Add tag.
#17
@Everett
#12.1. C is best. B is better than nothing. A is acceptable.
#12.2. I recommend using a link. Link text could be "Disable drag and drop" or "Re-order by selecting weight". I would avoid using a select box or a radio/check box, because that might make users think that this field is part of the form they should fill out before clicking Save.
+1 for this issue. I'm glad to know what webchick told us about keyboard access, but I know many people will still prefer to use the weight dropdown.
#18
Is this documented somewhere? Seems quite useful, but this is the first I've heard of it.
#19
One of the current implementation problems with keyboard access to drag and drop is that the keys used for reordering table rows are the arrow keys. Some screen-readers, like JAWS, capture the arrow keys for their own purposes and don't pass this along to the browser. So, alternative key bindings would be required to make an screen-reader accessible drag and drop.
#20
Please review this patch. It is a rough demonstration to help advance our discussion about what approach is best.
To try it out:
It has a number of problems: it needs to be translatable, changing the weight fields needs to refresh the actual row order, and more. But I'd like to know what people think of this approach.
I believe this approach would enhance accessibility. I agree with other comments that although the drag-n-drop functionality is keyboard-friendly, I know users with assistive technology who would prefer to use the weight fields.
#21
Brandon, could you post a screenshot of your changes?
#22
@Brandon
I haven't tested out the patch. But, I think that it is important that the switch appear before the table so that it is easier to find.
Also, as long as the non-JS functionality of the weighting for the table is available, then I wouldn't worry about table rows moving around when the weight is changed. Not sure what happens currently if JS is disabled.
#23
This seems to work to disable the Javascript in the drag/drop. Thanks Brandon.
#24
Attached are two screenshots of the patch in 20:
Again, the patch has known problems but I'd appreciate feedback on this approach.
#25
Had to add in Drupal.t() to translate the string.
I also removed the commented out line in the code.
My previous screenshots included some code fragment that was leftover from my previous work. @brandonojc's look right.
@Everett Zufelt, I don't know how to move it up to the top. I'm not a javascript person.
#26
@brandon @mgifford
I took a look at a page with thi patch applied.
1. Functionally it does work, after activating the toggle the weight column reappears and I can reorder the table rows by selecting a weight and selecting the save button.
2. The toggle still should be before, not after, the table so that it is more easily located.
3. The current toggle only persists the urrent page visit, and should have a longer persistence, perhaps session?
#27
I'd love to see a solution to this... and I agree with @Everett Zufelt that the toggle should be placed before rather than after the table.
#28
I do think this would be better to do within PHP rather than javascript. This would allow us to store a preference in a session variable or perhaps even a user setting (like may WYSIWYG editors allow).
This solution does work, but I think we can do better.
#29
Subscribe. Will review this weekend. (So consider this my zeroth pass.)
#30
This is an improved JQuery solution where the link appears before the table. It is available to sighted keyboard only users along with screen-reader users.
I am hoping that we'll have time to produce a better solution in PHP that stores preferences in sessions, but this is an improvement.
#31
+1 this patch looks like a good intermediary step to allow users to show the weight column for reordering rows in tables. Ideally the next iteration will allow for the ability to save the state of the users option.
I question if the wording of the show / hide link should:
1. Be Show / Hide weight column.
2. If Show and Hide should toggle with the state of the weight column.
Also, testing this patch on the blocks page I wonder if we might visit changing the text that comes before the table on some UIs to give direction on the weight field.
#32
To clarify my earlier comment.
Show / Hide weight field
Show / Hide weight column
Show weight column
Hide weight column
Ideally whether we choose column or feild for the wording on the link, the show and hide would toggle with the visibility of the weight column.
#33
@Everett, why not simply "Show weight"? (And then, of course, "Hide weight" when the weights are showing.)
I wonder if the ability to set the weight for a block should be added to the "Configure" screen as well. In other words, if I couldn't see, as best I can tell, the only way for me to activate a disabled block or to move an active block from one region to another would be through the "configure" link. So if all I wanted to do was add "Who's online" to the very bottom of the page content, why couldn't I give it a weight of 8 at the same time — in other words, on the same screen I would have to use to configure it?
As designed, I think it's great. I suspect this addition would make it even better.
#34
Patch in #30 is done without much extra javascript. Unfortunately getting the state right & putting in the proper show/hide into a description with a link requires more jQuery chops than I've got. I did give a go of it previously, but came up blank.
However, since we're hopefully going to have a PHP/session solution rather than this jQuery one I'm going to leave it for now. Hopefully we'll have a different solution in a week or two.
#35
I look forward to reviewing it then.
#36
The php solution is still the preferred one, but we don't have a champion to develop it yet.
#37
Yes, this really needs work and a champion.
#38
Ok, here's a first draft of this in any case. Unfortunately it isn't possible to save the chosen preference at this time. Yes, it's a big flaw, but need to get some discussion around this started.
#39
1) I wonder how many other JS behaviors we have in core that are not suitable.
2) I wonder whether this couldn't be stored on the client side.
#40
@sun I suppose if the problem isn't there when javascript is enabled that it could be tossed back to the client side to resolve.
Is there a default way for jQuery to set cookies in Drupal. There is at least one plugin. Alternately there is code like http://www.quirksmode.org/js/cookies.html
#41
Drupal uses cookies for other similar user preferences. Here's a new-ish example from modules/toolbar/toolbar.js:
Drupal.admin.toolbar.init = function() {
// Retrieve the collapsed status from a stored cookie.
var collapsed = $.cookie('Drupal.admin.toolbar.collapsed');
// Expand or collapse the toolbar based on the cookie value.
if (collapsed == 1) {
Drupal.admin.toolbar.collapse();
}
#42
This is an issue that's gotten away from me. I almost had an implementation organized, but the logic wasn't sticking.
@brandonojc's cookie solution will work fine, but I think I need to find someone else to implement it. Certainly for turning on/off the flag in the cookie all was good.
This is a critical issue as without an alternative this major feature of Drupal 6 & 7 is a significant accessibility barrier.
#43
Ok, I've spent the morning trying to work through this jQuery problem but haven't gotten any further. I'm posting it here for further refinement & discussion.
I can get it to set a cookie, but initially on load it doesn't seem to respect the cookie's status. Also, it seems like I have to click twice to get it to switch the first time (which is likely related).
I'm really not a jQuery person so calling out for help to bring this along so that a user can save the state with which they last viewed a dragable table item.
This is a critical issue and hope we don't have to jump in with #30 which really isn't sufficient!
#44
Please review this updated patch. It is based on the prior version and I believe it fixes all the issues @mgifford mentioned. I also did an overhaul of some of the code and function names for coding standards and readability. Mike, please let me know if I went too far.
I attached a screenshot to show the 'Show/hide weight fields' link that is inserted above any draggable table.
I believe this is working well and might be close to finished. I tested in Safari 3 and Firefox 3.5 on Mac.
However, I do think we might want to set the Show/hide link
element-invisiblebefore this is committed. My reasoning is that the table-drag feature works fine for sighted as well as keyboard-only users, so I believe the main user community served by this patch is screenreader users. If others agree, making it hidden would help us avoid cluttering the visual interface.#45
It works great for me Brandon! I agree that we're very close to RTBC now.
I haven't tested very long menus, but I have in the past been quite frustrated with the drag/drop as a sighted, mouse-using user. Being able to access the raw numbers is useful if you have a long list that is split over several pages. Might also be useful in other cases, so not sure that just sighted people will benefit from it.
Like most of the keyboard only controls, they do need to be better documented. It does work, but sometimes just tabbing over to the number and manually forcing it to be in the order that you want might be easier than trying to guess how to do it with the keyboard.
Someone had recommended that the Show/Hide should be separated so that it isn't the same link text for both commands.
The critical stuff is in though. Thanks!
#46
Okay, let's tag this for Needs Usability Review and see what feedback we can get. Maybe the link should be invisible until focus/hover.
#47
Ok, thanks for using this tag - although I agree that for long menu's it might get somewhat frustrating at times, I am not very keen on introducing this as a feature for tackling that issue (Understand we already discussed this feature in many times - in the 2 year lifecycle). To me that seems more of a orientation and workflow issue we should solve differently.
Could we make this on-focus? With that allowing those who really need it to use it, and to avoid visual clutter for others? To understand why it adds visual clutter, its the only element we are "attaching" to a table both visually and in terms of functionality. These are both very enticing changes, we have no real good pattern for in core - I hope with Drupal 8 where searching in a table and other patterns like these emerge we are able to provide better standards for this.
#48
Because there are a number of ideas about this discussed above I'm fine with this link displaying on hover.
I would like to have it be either themable or over-ridable though. Should