As a general rule, no ARIA is better than bad ARIA. This is because bad ARIA can cause screen readers and other assistive technologies to misunderstand how a page fits together and this can make web pages unusable for end users.
When using ARIA, following the 5 rules of ARIA can help prevent us from making costly mistakes.
Don't use ARIA!
Aria should only be used to fill in gaps that HTML does not provide. ARIA should be the last resort, don't use it if native HTML elements will do the same thing.
Don't replace native semantics
Don't define an item as one type and use ARIA to override the type to something else. Instead of <div role="button">, use <button>, this already provides interactivity such as keyboard press & simplifies code requirements.
Interactive controls must be keyboard accessible
Everything you can do with a mouse, you should be able to do with keyboard. For example, if a mouse is required to operate menus then it should be possible to operate these from the keyboard - this extends to using home/end to select the first and last items, typing to search, escape to clear selection, etc.
Beware of role="presentation" and aria-hidden="true"
Users can get stuck if keyboard users can see items, but screen readers can't. Therefore hiding items from ARIA needs to be done with extreme care.
All interactive elements must have an accessible names
All interactive elements such as links, buttons, inputs, etc should have accessible names. This helps assistive technologies to understand how everything fits together.
For example, we can use the for attribute to draw a link between an <input> and the associated <label> control.
Top comments (0)