Avoid aria-roledescription
April 30, 2020; 6 Comments
HTML has all sorts of built-in features that, when used correctly, are accessible, will localize, and which just work. For example, if I want a button, I use <button>, and a screen reader will announce it as button. For users in other languages, they will hear whatever is their word for button.
Other recent posts on my site that talk about leaning too hard on ARIA without consideration for users:
- My Priority of Methods for Labeling a Control
- aria-label Does Not Translate
- Stop Giving Control Hints to Screen Readers
- Basic Custom Control Requirements
For cases where HTML does not have the control built in, ARIA can be used to fill that gap. If you want a tabbed interface, for example, you can use the tab, tablist, and tabpanel roles. A screen reader will announce those components for users in their own language through no additional effort on your part.
A New Property
ARIA 1.1 introduced a new property: aria-roledescription
Defines a human-readable, author-localized description for the role of an element.
[…]
The aria-roledescription property gives authors the ability to override how assistive technologies localize and express the name of a role. Thus inappropriately using aria-roledescription may inhibit users’ [...]