5 ARIA attributes every dev should know (and 2 to avoid) Most developers know ARIA exists, but which attributes actually matter for everyday accessibility work? Before we get started, remember the first rule of ARIA: Don't use ARIA unless you have to. If semantic HTML can do the job, use that instead. But when you do need ARIA, here are 5 ARIA attributes that are actually useful: 1. aria-labelledby - Describe the current element with the text from another element on the page. Better than aria-label because it allows you to reference existing visible text on the page and keep it translatable. 2. aria-describedby - Connects help text, error messages, or extra context to form fields and other elements. Screen readers announce this after the main label. 3. aria-expanded - Essential for dropdowns, accordions, mobile menus - anything that opens and closes. Bonus: pair it with aria-controls to define which element it's controlling. 4. aria-current - Perfect for programatically defining the current page in navigation, active step in a process, or current item in pagination. Much clearer than visual styling alone. 5. aria-live - Announces dynamic updates to screen readers. Use "polite" for status messages, "assertive" for urgent alerts. Two to avoid (or use carefully and thoughtfully): 1. aria-label - It's typically a better choice to choose another way to label elements, with text inside a button tag, a label tag associated with a form field, or visible text associated with the aria-labelledby attribute. Treat aria-label as a last resort when no other method of labeling an element can be used. 2. role - Most of the time, there's no need for that role attribute when you use semantic HTML. Skip adding role="button" on a div - just use a button tag. A proper heading tag doesn't need a heading role or an aria-level attribute. The best accessibility starts with good semantic HTML. ARIA is intended to fill in the gaps, not replace the foundation. What ARIA attributes do you find most useful? Any that trip up your team?
Fab advice, often see aria-label being over-used and even seen it together with alt text and title in code.
Excellent advice Natalie. I see so many sites (even big orgs and we’ll known companies) who are failing ARIA from a WCAG point of view and could prove costly if any of the Accessibility laws catch on. Another one I see neglected is the use of landmarks, which again always flags up in tools like AxeDev. Seems to me some of the basics are still being forgotten or ignored, despite it being a legal requirement now rather than a ‘nice to have’ as previously thought of.
ARIA supports not substitutes when HTML falls short use it to enhance not to replace
Thanks, Natalie, for this and all of your neatly-described accessibility tips!
ARIA roles are really only useful when building custom components like tabs, carousel, combobox, etc.
How about aria-label for generic links like “more” “about” etc, especially when those are provided by the client?
UX Copywriter. Mouthy broad. Making online content friction-free and accessible for all.
3wI keep hearing that I’m not supposed to use aria-label but if I have a button that reads “Learn more,” how else am I supposed to communicate “learn more absout restarting your router”?