As the joke goes, three of the hardest things in computer science are naming things and off-by-one errors. 🥁
While it can be tricky sometimes to think of good names for variables and components, there are some other considerations to take into account when it comes to accessible naming for identifying components in Assistive Technologies like screen readers.
One of the most important things you can do is use semantic HTML elements in your markup. Instead of going with
divs for everything, choose an element that includes an implicit role and behavior that matches your purpose. For example,
<footer> can give you an idea of what they do from reading their tag names. Similarly, using
<button> instead of styling a different element provides accessibility information and functionality in the browser for “free” without using ARIA (Accessible Rich Internet Applications).
So when is the right time to use ARIA?
Just like “when all you have is a hammer, everything looks like a nail,” ARIA is a powerful tool that’s not always the right one to use. It can also sometimes make a real mess of a web application if not used correctly. It’s best to use ARIA for the components you create that are more complex than the available semantic elements alone, along with testing in Assistive Technologies to ensure a positive user experience.
There are many aspects of ARIA that can be safely and routinely utilized. Name and role are common, and there are also more specialized attributes. For example, in the workshop demo app I use the
aria-expanded state to inform screen readers that the custom mega menu component is opened or closed.
In Testing Accessibility, we get deeper into the “when” and “how” of ARIA best practices including hands-on practice coding and writing real-world tests.