WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Drag n drop

for

From: Brandon Keith Biggs
Date: Jun 27, 2018 8:26PM


Hello,
If we are going to look at non semantic interfaces, Audio Games allow for
drag and drop functionality. Most effective are strategy games where you
need to move objects around the grid. You can either press enter on the
object you want to move and have a sound play letting you know you are
dragging the object and press enter to set it down in another square, or
have the user press something like shift and the arrow keys to move the
object to an adjacent square.
Thanks,


Brandon Keith Biggs <http://brandonkeithbiggs.com/>;

On Wed, Jun 27, 2018 at 7:19 PM, Steve Green < <EMAIL REMOVED>
> wrote:

> We have just won a testing project, part of which involves drag and drop
> functionality in online tests exactly as Guy described. When this thread
> appeared I hoped (without any expectation) that someone might have cracked
> the problem by now, but it seems not.
>
> In our case the problem is even worse because when one item is moved, all
> the ones below it move too. I haven't started work on it yet, but my
> initial thoughts are that it's just not possible to make it accessible so I
> expect to have to experiment with other means of interaction while trying
> to maintain something like the existing appearance and functionality.
>
> Unlike the PowerPoint example, the tests could be designed without
> dragging at all. I am considering using comboboxes, each of which contains
> all the answers, but when an answer is selected in one combobox it is made
> unselectable in all the others.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Birkir R. Gunnarsson
> Sent: 28 June 2018 02:25
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Drag n drop
>
> 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
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > at http://webaim.org/discussion/archives
> > > > > >