Drag’n’drop revisited

I got a message from a screen-reader user of The Session recently, letting me know of a problem they were having. I love getting any kind of feedback around accessibility, so this was like gold dust to me.

They pointed out that the drag’n’drop interface for rearranging the order of tunes in a set was inaccessible.

Drag and drop

Of course! I slapped my forehead. How could I have missed this?

It had been a while since I had implemented that functionality, so before even looking at the existing code, I started to think about how I could improve the situation. Maybe I could capture keystroke events from the arrow keys and announce changes via ARIA values? That sounded a bit heavy-handed though: mess with people’s native keyboard functionality at your peril.

Then I looked at the code. That was when I realised that the fix was going to be much, much easier than I thought.

I documented my process of adding the drag’n’drop functionality back in 2016. Past me had his progressive enhancement hat on:

One of the interfaces needed for this feature was a form to re-order items in a list. So I thought to myself, “what’s the simplest technology to enable this functionality?” I came up with a series of select elements within a form.

Reordering

The problem was in my feature detection:

There’s a little bit of mustard-cutting going on: does the dragula object exist, and does the browser understand querySelector? If so, the select elements are hidden and the drag’n’drop is enabled.

The logic was fine, but the execution was flawed. I was being lazy and hiding the select elements with display: none. That hides them visually, but it also hides them from screen readers. I swapped out that style declaration for one that visually hides the elements, but keeps them accessible and focusable.

It was a very quick fix. I had the odd sensation of wanting to thank Past Me for making things easy for Present Me. But I don’t want to talk about time travel because if we start talking about it then we’re going to be here all day talking about it, making diagrams with straws.

I pushed the fix, told the screen-reader user who originally contacted me, and got a reply back saying that everything was working great now. Success!

Have you published a response to this? :

Responses

Daniel

Thinking with a progressive enhancement mindset, that is starting with the most basic HTML features and enhancing with more advanced stuff, is in my opinion the best way to go about building inclusive, accessible websites. Jeremy Keith wrote about some accessibility feedback he got and how his originally robust code made the solution an easy fix:

Drag’n’drop revisited

# Posted by Daniel on Monday, April 8th, 2019 at 5:35pm

3 Likes

# Liked by Gunnar Bittersmann on Sunday, April 7th, 2019 at 10:01pm

# Liked by Carlos Molina on Sunday, April 7th, 2019 at 10:31pm

# Thursday, June 27th, 2019 at 7:43pm

Previously on this day

4 years ago I wrote Accessible progressive disclosure revisited

From buttons to links.

4 years ago I wrote Mistakes on a plane

In which Comic Book Guy critiques in-flight entertainment.

5 years ago I wrote 100 words 016

Day sixteen.

6 years ago I wrote The tragedy of the commons

Digital destruction courtesy of the Brooklyn Museum.

6 years ago I wrote Connections #2

Come along to chat about organisational stuff’n’shit.

9 years ago I wrote Skillful stories

An excellent night of narrative exploration in Brighton.

11 years ago I wrote Inkosaurs

Moving from the denial phase into anger.

12 years ago I wrote Mi.gration

Moving bookmarks.

14 years ago I wrote Further comment

Following up on the comments controversy.

15 years ago I wrote Junk not found

If only this were a server response instead of a message count…

16 years ago I wrote What is Web Design?

"Who are we? Why are we here?"

16 years ago I wrote Beatallica on the brat

Beatallica perform Beatles songs in the style of Metallica.