A Practical Guide to Accessible Names and Roles
The name, role and state that assistive technology reports for every interface component, such as "Menu, button, collapsed", which custom widgets must provide explicitly.
Marcus Adeyemi
Where most projects go wrong
The usual mistakes:
- Div and span elements used as buttons
- Icon buttons with no accessible name
- States that change visually but not in code
- ARIA roles that contradict the element's behavior
What good looks like instead
- Use native elements before building custom ones
- Give every control an accessible name
- Update states such as aria-expanded when they change
- Check names and roles with browser accessibility tools
- Test custom widgets with a screen reader
Why it matters
Native HTML elements expose these automatically, but custom components often expose nothing, leaving screen reader users with unlabeled controls, which fails WCAG at level A.
The specs that matter
| Measure | Figure |
|---|---|
| WCAG 4.1.2 Name, Role, Value, A | the name and role of components can be determined, and states can be set and changed |
| Native elements | buttons, links and form controls expose name and role by default |
| Custom widgets | need ARIA roles, states and properties |
| Common failure | clickable div elements with no role or name |
Knowing when to hand it over
Tip: Bring in help when a component library uses custom controls, or when screen reader users report unlabeled buttons.
Where this comes from
- W3C Web Accessibility Initiative — Understanding SC 4.1.2 Name, Role, Value
- MDN Web Docs — Accessibility tree
The figures and practices above come from the sources listed.
Working on something like this?
We take on Performance & Accessibility work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.
