What Is ARIA and Why Does It Matter?
ARIA (Accessible Rich Internet Applications) is a set of W3C attributes that allow developers to communicate the purpose, state, and behavior of UI elements to assistive technologies. When native HTML falls short of conveying meaning to screen reader users, ARIA bridges that gap. Getting it right can mean the difference between an experience that works for everyone and one that actively misleads users who rely on AT.
The First Rule of ARIA: Do Not Use ARIA
The WAI-ARIA specification itself states to use native HTML elements whenever possible before reaching for ARIA. A native button already communicates its role, state, and focusability without a single ARIA attribute. If you use a div styled to look like a button, you must manually add role, keyboard interaction, and focus handling to recreate what you get for free with a native element.
Common ARIA Roles Every Developer Must Know
- role="button" — marks interactive elements that are not native buttons
- role="dialog" — identifies modal overlays; requires aria-modal and focus trapping
- role="navigation" — landmark for nav regions; pair with aria-label when multiple exist
- role="main" — marks the primary page content; only one per page
- role="alert" — announces urgent messages automatically to screen readers
- role="tablist", "tab", "tabpanel" — compose the tab widget pattern
aria-label vs aria-labelledby vs aria-describedby
aria-label: When There Is No Visible Text
Use aria-label directly on the element when there is no visible text that can serve as its name, such as a button containing only an SVG icon. Set the value to a concise, action-oriented phrase like 'Close dialog' or 'Search site.'
aria-labelledby: Pointing to Existing Visible Text
When a visible heading or label already exists in the DOM, reference its ID with aria-labelledby rather than repeating the text in an aria-label. This keeps your accessible name tied to what the visual user sees.
aria-describedby: Adding Context
Think of aria-describedby as a footnote: it adds detail after the primary accessible name and role. Pair it with inline error messages on form fields so the screen reader announces the label first, then the error.
ARIA Anti-Patterns That Break Accessibility
- Do not add role="button" to a native button element
- Do not use aria-hidden="true" on focusable elements like links or buttons
- Do not use role="presentation" on elements with meaningful content
- Do not nest interactive roles inside each other
- Do not use aria-required without a corresponding visual indicator
- Do not forget to update aria-expanded when a disclosure widget opens or closes
Dr. Lisa Chen
Director of Accessibility
A certified accessibility consultant at BuildWithAccess helping organizations achieve WCAG compliance and build more inclusive digital experiences.
Need help making your site accessible?
We offer free consultations to assess your current accessibility posture and recommend a path forward.
Get a Free Consultation