WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Drag n drop

for

From: Birkir R. Gunnarsson
Date: Jun 27, 2018 7:24PM

aria-grabbed and aria-dropeffect are depricated in ARIA 1.1 (no longer
recommended though they could be used for backwards compatibility).
Strange as it may seem, nobody has really come up with an accessible
drag and drop solution for the web, neither using ARIA nor HTML.
Every solution you implement has to be based on a series of
unfortunate hacks using text to describe the actions.
If you can give us more detail about exactly what the drag and drop
action entails we might be able to provide more helpful examples or
advice.



On 6/27/18, Guy Hickling < <EMAIL REMOVED> > wrote:
> 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
> > > > >


--
Work hard. Have fun. Make history.