![]() VoiceOver + Safari (15.4) on MacOS 12.3.I’ll be testing four common desktop browser and screen reader combinations, which reflect the most commonly used primary screen reader for each browser, per the 2021 WebAIM Screen Reader User Survey #9: So the base markup will look something like this: Its presence can change how screen readers announce an element, so I'll include it. This role is sometimes applied to complex widgets that manually manage focus or use custom keyboard functionality. Lastly, I’ll test the draggable button in two situations – with and without a parent container that has a role="application". In production, it may be clearer to use something like “click to grab” that matches the actual functionality better. In those cases, I keep it simple by using the text "draggable". In some tests, I provide my own drag information. It will also be assumed that this implementation allows users to pick up an item by activating it. This doesn’t cover every element that developers use in drag-and-drop builds, like li or img, but it’s a good starting point. I'll be using a simple draggable element – a basic button. The goal is to get an idea of support so we might better plan a usable screen reader experience to prototype and test. Any techniques are purposely simple and exist without wider context. Note: This article is not intended to present vetted patterns or offer a copy-paste solution. Future articles will look at picking up and moving items, then I'll end by testing any promising options to see what actual users think. I'll start in this article by looking at ways to convey an item's draggability. So can we even make these interfaces usable to screen reader users, or is it a fool's errand? I believe that we can, but in terms of "how", I don't know yet.Īs part of a series, I'm going to attempt to learn how we can communicate these interactions to screen reader users. Or in some cases, like if you provide alternate controls, you might choose not to at all. Indicators, states, and feedback conveyed or implied visually now need to be communicated aurally. Until a baseline accessible experience gets baked into the DNDAPI, developers will need to roll out their own solutions – a messy endeavor with no best practices.ĭrag-and-drop implementations can be quite different – so solutions to make them coherent for screen reader users are going to vary widely. ![]() 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). ![]() So its use is only going to grow.īut the DNDAPI has a big flaw: there’s no built-in accessibility features. It also has good support: it’s available in the big four desktop browsers (Chrome, Edge, Firefox, Safari), and with iOS 15’s release in 2021 it’s now on both major mobile platforms (Android Chrome, iOS Safari). Despite some quirks, it works pretty well – making it easy for developers to create drag-and-drop functionality. I’ve been using the HTML Drag and Drop API (DNDAPI) a fair amount lately, which is a native way to build draggable interfaces.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |