Learn how to implement ARIA roles in your HTML to enhance web accessibility. This tutorial covers best practices for adding ARIA roles, states, and properties, ensuring a more inclusive and user-friendly website experience.
In Part 1, we walked through the categories of ARIA roles and why they matter. That was the map. This part is the driving. We’ll put roles into real HTML, then go one level deeper into the states and properties that tell assistive tech what an element is actually doing right now.
Section 2: Implementing ARIA Roles in HTML
You assign a role with the role attribute, followed by the role you want. That’s the whole mechanism:
<nav role="navigation"></nav>Here’s the honest caveat, and it’s a big one: you wouldn’t actually write that. A nav element already carries an implicit navigation role, so spelling it out adds nothing. We’re showing it because it’s the clearest way to see the syntax, not because it’s code you should ship.
ARIA Role Best Practices
Which leads to the rule that governs all of this. The first rule of ARIA is: if a native HTML element gives you the semantics you need, use it instead of ARIA. A real <button> beats a <div role="button"> every time, because you get focus, keyboard behavior, and the role for free. Reach for ARIA when native HTML genuinely can’t express what you’re building.
With that in mind:
- Pick the accurate role: match the element’s real purpose and behavior, not the one that sounds close.
- Don’t duplicate implicit roles:
nav,main,header, and friends already announce themselves. Addingrole="navigation"to anavis redundant. - Test with a real screen reader: fire up VoiceOver, NVDA, or JAWS and listen. Correct-looking markup and correct-sounding markup aren’t always the same thing.
Section 3: Enhancing ARIA with States and Properties
Roles say what an element is. States and properties say what it’s doing and how it relates to everything around it. You need all three to describe a component accurately.
The line between the two is worth learning, because it explains when each one changes.
ARIA States
States are dynamic. They flip as the user interacts, and your JavaScript is responsible for keeping them accurate:
aria-checked: whether a checkbox or radio is checked.aria-disabled: whether an element is disabled.aria-expanded: whether a collapsible section is open or closed.
A stale state is worse than none. If a menu is visually open but aria-expanded still reads false, you’ve actively lied to a screen reader user. Update these the moment the UI changes.
ARIA Properties
Properties are the structural side. They tend to stay put, describing an element or wiring it to another one:
aria-label: gives an element a name when there’s no visible text to borrow.aria-describedby: points to other elements that describe this one.aria-controls: names the element this one controls.
Roles, states, and properties together give you a component that assistive tech can read the way a sighted user reads the screen.
Wrapping up
ARIA is powerful, but it’s a scalpel, not a coat of paint. Use native HTML wherever it does the job, add roles only when the native element can’t say what you mean, and keep states honest as the interface moves. Then test with a real screen reader, because that’s the only way to know it landed.
Want to go further? These are the references worth bookmarking:
- WAI-ARIA Overview by W3C: the official guidelines and technical spec, straight from the source.
- MDN Web Docs on ARIA: Mozilla’s deep, practical reference for roles, states, and properties.
- Web.dev ARIA Guide: Google’s take, with real examples for modern sites.
- The A11Y Project: community-driven tutorials, checklists, and patterns.
- WebAIM ARIA Techniques: field-tested techniques from people who test accessibility for a living.
Read a couple, then go break something in a screen reader. That’s where it actually clicks.