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 start with 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, <nav> or <footer> can give you an idea of what they do from reading their tag names.
To set one <nav>, <footer> or <section> region apart from another (because you'll likely have multiple), include an aria-label or aria-labelledby attribute to specify the purpose of that particular landmark.
These attributes create something called an accessible name for an element that is relevant in Assistive Technologies. Other elements that need accessible names exposed include links, form controls with labels, and buttons. This also applies to icon buttons, which aren't fully functional when only a visual icon is present. What does that vague, custom icon represent? Who knows!?
There are multiple ways to add an accessible name to an interactive element. Using regular text content is an obvious choice, since a visual text label can benefit all users. It could also clear up what those darn icons mean (looking at you, Google apps!).
Alternatively, you could use the same ARIA labeling attributes I mentioned for landmark regions: aria-label and aria-labelledby will create accessible names under the hood.
Or, you can include a visually-hidden span in a button or link under some circumstances to expose an accessible name to users of Assistive Technologies. This technique will technically render the text in a screen reader and expose it as an accessible name to the parent button, but hide it visually for sighted users.
When deciding what content to use for an accessible name, try to keep things simple. Describe the purpose of the element in basic terms. What does this particular thing do?
Remember that the role of an element will be announced, so it doesn't need to be repeated in the label (button, link, image, etc.). There may be slight differences across screen readers that you need to live with, too–it's similar to chasing pixel perfection cross-browser. At some point, your attempts at "fixing" something for one screen reader might make things worse in another. At that point, your time may be better spent on creating simple solutions, such as labels that can be easily translated.
While we're discussing the benefit of using semantic HTML elements, using a <button> instead of styling a generic element provides both accessibility information and interactive 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 with decent support. 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. When coupled with an accessible name, these programmatic state and role declarations can make an interactive experience work quite well with Assistive Technologies.
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.
