![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
deborahtl;dr: Use ARIA, and use it wisely.
This spring, I gave a tutorial at Ebooklib, "WAI-ARIA In Practice: E-Books That Are Dynamic, Beautiful, and Accessible". My whole session basically boils down to "look at all these awesome things you can do with WAI-ARIA, but look at all of these terrible things you can do with WAI-ARIA, so please use it, but pretty please with sugar on top only use it mindfully -- read the documentation!" (Powerpoint slides with notes, PDF reading list.)
I'm thinking about this as I read Marco Zehe's post "Easy ARIA tip #8: Use aria-roledescription to selectively enhance the user experience", on the roledescription attribute in WAI-ARIA. I'm not yet sure how this will play out in practice, both because it is new and presumably virtually unused, and because I couldn't get it show any effect with either Vivaldi + NVDA or with Dragon 14.
But this is one of the many places I can see ARIA, if applied poorly, could negatively affect speech recognition users. If I say "click button", then Dragon knows what to do. But if the button role is overriden by the role "buy my product" then suddenly I can no longer click the button.
The roledescription "buy my product", crucially, is never exposed to a speech recognition user. The speech recognition user don't know what the button's role is, and has no way of finding out, rendering the button much more difficult to use.
(If you think nobody would ever implement an example as badly designed as this, unfortunately you are mistaken. Examples of such bad design — with webdevs not understanding the difference between plain old title and alt, let alone the ARIA labelling and description family — abound on the web.)
This is similar to the problem speech recognition users have been encountering for years now with unlabelled icons in interfaces, especially icons which are placed with CSS pseudo-elements. The sighted, mouse-friendly user sees the icons, theoretically[1] recognizes their purpose, and clicks on them. The screen reader user reaches the icons and hears the textual name, which they can then activate. But the screen reader user is stranded. They may recognize the general purpose of the icon, but unless they know the actual text label, they have no way of activating it. Sometimes they can guess wildly (eg. "click save"), but other times there's no way a person could reasonably guess.
Here's top navigation bar for a logged-in user at GitHub:
The speakable labels for those three unlabelled icons are created with aria-label, and they are: "Homepage" for the site logo on the left, "Create new..." for the plus sign, and "View profile and more" for my user profile image. Now that I've looked those up (by looking at the page source), I can dictate those icon labels in the future. But without looking at the source, I had no way of knowing them, and I'd never have guessed. (Worse, if the icons are placed there with pseudo-elements, I probably can't even say, generically, "click button" or "click link", because of the way the DOM is constructed.)
This kind of design pattern is one of the major reasons I get het up when accessibility people use "accessibility" or "AT" to mean screen readers. They gap between what is useful for screen readers and what can cause breakage for users with other accessibility tools can cause real problems.
This spring, I gave a tutorial at Ebooklib, "WAI-ARIA In Practice: E-Books That Are Dynamic, Beautiful, and Accessible". My whole session basically boils down to "look at all these awesome things you can do with WAI-ARIA, but look at all of these terrible things you can do with WAI-ARIA, so please use it, but pretty please with sugar on top only use it mindfully -- read the documentation!" (Powerpoint slides with notes, PDF reading list.)
I'm thinking about this as I read Marco Zehe's post "Easy ARIA tip #8: Use aria-roledescription to selectively enhance the user experience", on the roledescription attribute in WAI-ARIA. I'm not yet sure how this will play out in practice, both because it is new and presumably virtually unused, and because I couldn't get it show any effect with either Vivaldi + NVDA or with Dragon 14.
But this is one of the many places I can see ARIA, if applied poorly, could negatively affect speech recognition users. If I say "click button", then Dragon knows what to do. But if the button role is overriden by the role "buy my product" then suddenly I can no longer click the button.
<button aria-roledescription="buy my product">Purchase</button> The roledescription "buy my product", crucially, is never exposed to a speech recognition user. The speech recognition user don't know what the button's role is, and has no way of finding out, rendering the button much more difficult to use.
(If you think nobody would ever implement an example as badly designed as this, unfortunately you are mistaken. Examples of such bad design — with webdevs not understanding the difference between plain old title and alt, let alone the ARIA labelling and description family — abound on the web.)
This is similar to the problem speech recognition users have been encountering for years now with unlabelled icons in interfaces, especially icons which are placed with CSS pseudo-elements. The sighted, mouse-friendly user sees the icons, theoretically[1] recognizes their purpose, and clicks on them. The screen reader user reaches the icons and hears the textual name, which they can then activate. But the screen reader user is stranded. They may recognize the general purpose of the icon, but unless they know the actual text label, they have no way of activating it. Sometimes they can guess wildly (eg. "click save"), but other times there's no way a person could reasonably guess.
Here's top navigation bar for a logged-in user at GitHub:
The speakable labels for those three unlabelled icons are created with aria-label, and they are: "Homepage" for the site logo on the left, "Create new..." for the plus sign, and "View profile and more" for my user profile image. Now that I've looked those up (by looking at the page source), I can dictate those icon labels in the future. But without looking at the source, I had no way of knowing them, and I'd never have guessed. (Worse, if the icons are placed there with pseudo-elements, I probably can't even say, generically, "click button" or "click link", because of the way the DOM is constructed.)
This kind of design pattern is one of the major reasons I get het up when accessibility people use "accessibility" or "AT" to mean screen readers. They gap between what is useful for screen readers and what can cause breakage for users with other accessibility tools can cause real problems.
Note: Label your icons. Seriously, if you want people (any people) to be able to use your site, label your icons. Pretty much every single user testing group, ever, has found when testing with real users that there are almost no icons with universally recognizable purpose and labelling icons reduces interaction cost.
- Myth #13: Icons enhance usability
- Labels Always Win
- The Best Icon is a Text Label
- Do icons need labels?
