WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Drag n drop

for

From: Guy Hickling
Date: Jun 27, 2018 6:15PM

Not a lot has been said yet about making this accessible for screen and
Braille reader users, but they must be catered for as well. This is likely
to require explaining things in greater detail so they know what's
happening, as well as giving them a mechanism they can use.

A common use case is in online tests, where the user is given several items
to drag and an equal number of targets, and they must drop the right item
in each target. Here it is probably simple to take the keyboard version and
ensure all the items and targets are announced correctly when the screen
reader user lands on them, but they might need more instructions. For
instance, if the on screen text simply says "drop the items into the
correct boxes", that doesn't tell the user how many items there are or or
how many boxes they have to drop into taking place, so tell them upfront
using aria-describedby or hidden text.

It must also be announced when the user has successfully dropped the item
into the box they wanted (confirm which box they actually dropped it into,
not just "item has been dropped", so they are certain it went where they
meant it to go. The Whatsock example someone suggested earlier in this
thread doesn't announce the drop, it simply repeats the label on the
selected item which is not helpful. (And it also uses links for the drag
items, which gives screen reader users the wrong information as they don't
go to another page. A button would be better.)

Screen reader user should also be able to traverse the targets at the end
of it all and hear announcements of what item is now in each target, to
confirm what they have done. The page should not move on to the next page
in the sequence, for instance, automatically as soon as the last item has
been dropped. (And all users need a means to change their choices if they
make a mistake in the drop.)

Some more complex situations may be too complex to simply use the existing
keyboard mechanism for screen reader users. In that case you might need to
provide a whole separate version of the component for screen reader users,
accessed via a link placed beside the visual version (a bit like
alternative texts for very complex images can be provided via a link beside
the image). Then provide an alternative choose-and-drop mechanism that is
meaningful and usable by screen reader users. The process would not
necessarily have to mimic the visual component exactly, so long as a screen
reader user can make all the same choices that a sighted user can. (Just
deciding a version for screen reader users is not possible would only be a
last resort, if it really truly is not meaningful or possible to so it. In
which case SC1.1.1 would require an alternative text to say what is there.)

​Finally, ARIA has the aria-dropeffect attribute to use where appropriate.

​
Regards,
Guy Hickling
​Freelance ​
Accessibility Consultant