“screen readers” Articles

I know it’s been awhile (*checks notes* wow, almost two years!), but I’m finally back with the next article in my “screen readers and drag-and-drop” article series. Here, I’ll be diving into how to convey to screen reader users when an element has been picked up or put down. Ideally, I’ll be able to identify at least a few approaches to prototype into full patterns to test later.

Most screen reader users have limited to no vision and will miss visual cues showing an item’s been grabbed. So it’s important to communicate these actions programmatically as well so that everyone can perceive the interaction.

I recently needed to test the support of a dynamic accessible description – a element’s description that is initially one (or no) value, then changes to another value after an action takes place.

I created a page of examples to test and a document to record my findings, but then realized that I could just make this a blog post that I periodically update. That way, others can use it as a reference as well, if they choose.

The other day I was skimming Webkit’s Safari Technology Preview 153 release notes and noticed that they had added support for aria-description.

I always found it odd that developers could set an element’s accessible name/label with the aria-label and aria-labelledby attributes, but only had aria-describedby for setting accessible descriptions. So seeing aria-description being added to Safari was an interesting surprise.

I decided to do a mini dive and test of support for aria-description to fill in my knowledge gap and be prepared to use it when the time comes. A sort of crash-course, if you will. I’m sharing my findings here in case it’s valuable for anyone else.

I’ve been using the HTML Drag and Drop API (DNDAPI) a fair amount lately, which is a native way to build draggable interfaces. Despite some quirks, it works pretty well – making it easy for developers to create drag-and-drop functionality.

But the DNDAPI has a big flaw: there’s no built-in accessibility features. This means screen reader users (and many others) won’t be able to use interfaces built with it without a lot of mindful, additional work from developers (which, let’s face it, most don’t do).