Accessibility Review
mgifford opened this issue · comments
Would be great to get feedback on:
https://www.drupal.org/project/drupal/issues/2920006#comment-12322128
First of all, thanks for reviewing Dragon Drop! I think some very useful things came out of this. A common theme in the feedback is the lack of discoverability. This is a direct result of there being no widely adopted convention on how keyboard users interact with drag-and-drop lists. I hope my approach can be refined and become widely used so keyboard users have expectations on how it all works. Unfortunately there are no ARIA authoring practices and nothing but deprecated aria-grabbed and aria-dropeffect attributes in regard to dragging and dropping. This is why I had to get creative and fallback to utilizing live regions.
Here is my feedback:
It only has examples of draggable rows, not 2-dimensional movement.
Yep, would love to add support for that but haven't had time. This is open source so feel free to contribute!
The first example has clear grab-buttons with a clear icon, text fallback, and focus styles. The grab behaviour isn't as discoverable in the second example.
Keep in mind Dragon Drop is a module so it can be implemented any way you want. Things like making it discoverable and even describing how to interact with it is up to the implementer. The demo is just an example call to dragon drop.
The grab-button is a so we'd expect enter and spacebar to both activate it. However enter and spacebar have two different behaviours:
Enter toggles the grab state. To move it you either press enter (grab), arrows keys, enter (ungrab).
Spacebar acts more like a shift key, so it's grabbed while spacebar is held down. To move it, press spacebar + arrow keys together.
This different behaviour is a bit hard to discover. I initially pressed + released spacebar, then used arrows. My first impression was that it was broken.
Enter and space are coded to do the exact same thing (that's how native button elements work). The 2 behaving differently is definitely the result of the screen reader being used during your testing. With VoiceOver, enter and space both toggle the button but I have't tested dragon drop in a while with JAWS and NVDA so I will look into whats going on there.
Escape cancels the re-ordering, and leaves things where they were before you tried dragging. Nice, assuming you discover it.
The only way I can think of making this functionality discoverable is including this info in the help text so I suggest doing so in implementing DragonDrop
The aria-live messages tend to queue up, so you can sometimes hear a long sequence of grabbed/ungrabbed messages. Meh, needs a throttle.
Agreed, a throttle would be nice!
The grab-buttons are all aria-describedby a piece of visible help text. This gets announced after every movement, which is very verbose and repetitive. It will likely respect the verbosity settings of different screen readers, but they don't all offer this. I didn't like this part.
This is just how the demo happens to do it. Once again, its up to the implementer to decide how they want to associate help text with the controls. An approach I personally like to use is the make the <ul /> aria-labelledby the help text so it is only read out when the AT user first enters the list.
The DragonDrop demo does not use HTML tables or ARIA grid semantics. It's just draggable rows, so it gets away with an ordered list. For our layout builder, I still think we'll need ARIA grid.
That shouldn't be a problem. The 2 demos happen to use lists but if you pass DragonDrop a grid, that's fine
Also, I noticed that dragula was in list of modules to review. I think its important to note that DragonDrop uses dragula for it's mouse functionality (I didn't want to re-invent the wheel with mouse dragging and dropping).
I don't have a drupal account so I couldn't respond there. If you could link to this comment that would be appreciated
@schne324 thanks for this response. I'll make sure to add it to the thread. There is some movement with Shopify/draggable#48 that might have some ideas to build on too. We're trying to share best practices here so that there are patterns that are easier to adapt.
@schne324 I was doing some testing on NVDA today, and tried out Dragon Drop. It took me a few tries to remember I was in browse mode, and that's why I couldn't use the arrow keys to move the grabbed item. It might be worth adding a screen reader only block of instructions that include a reminder for NVDA to switch into focus mode before interacting with a Dragon Drop list.
@1Copenut thanks for the suggestion! I've actually noticed that too while performing NVDA tests. IMO that should be up to the implementer of dragon drop. As I described above, I can only provide demos of recommended approaches. I will add some offscreen text directing NVDA users to ensure they are in focus mode to the demos though
@schne324 You're welcome. I agree, you can only provide demos of recommended approaches. I feel that sets a good precedent; many times I've used code as the demo described, so having that allowance in place encourages adoption.
Thank you for the work on Dragon Drop.
I think this conversation is a great resource for the general a11y of Dragon Drop which is why I am linking to it in the readme.
Thanks again to @mgifford and the others at drupal for the valuable feedback.
@1Copenut thanks to your great feedback I have updated the demos with offscreen instructions to switch screen reader into focus mode!
closing this ticket -- if any specific a11y issues are found please create a new ticket
Cheers!