Your daily frequent11y newsletter, brought to you by @ChrisBAshton:
aria-label is a code smell
Eric Bailey highlights a snippet from the WebAIM Million report:
Increased ARIA usage on pages correlated to higher detected errors. The more ARIA attributes that were present, the more detected accessibility errors could be expected.
He references the increased complexity of ‘support’ in the context of ARIA, which is determined by:
- Operating system being used,
- Operating system’s version,
- Browser being used,
- Browser’s version,
- Assistive technology being used,
- Assistive technology’s version, and
- Complexity of the underlying code.
When aria-label is used on a non-interactive element – which is not what it is intended for – assistive technology handles it in different ways. It will either not be announced at all, or will be announced in strange ways.
Even when declared on an interactive element, there are known issues. It only has partial support in Edge with Narrator, and, if you think of a play/pause toggle, in many cases it does not convey name changes when focused.
Eric also cites examples of people using aria-label to override an otherwise visible name. Users who use their voice to navigate, such as “Click ‘snapshot'”, may be surprised when their voice command does not work, as the underlying accessible name is different (and not visible to them).
Some browsers do not translate aria-label content, so things like Google translated pages won’t work properly. Finally, aria-label content is not very robust to things like stylesheets failing to load. An alternative – visually hidden text – will at least still be visible if the styles fail to load.
Worth reading the Hacker News comments on this too.
Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with ♥ by developer @ChrisBAshton.
