ARIA roles let you describe custom widgets to assistive technology when HTML has no native equivalent. Used correctly they fill real gaps; used incorrectly they actively break accessibility that native HTML would have handled for free.
1The First Rule Of ARIA Use
The W3C's ARIA Authoring Practices open with an explicit warning known informally as the 'First Rule of ARIA': if a native HTML element or attribute has the semantics and behavior you need, use it instead of re-purposing an element and adding an ARIA role, state, or property.
This exists because ARIA is purely declarative — it tells assistive technology what something is, but implements none of the actual behavior. Adding role="button" to a <div> does not make it focusable, does not make Enter or Space activate it, and does not give it a pointer cursor. All of that has to be added manually with tabindex, JavaScript key handlers, and CSS — every one of which is a place to introduce a bug that a native <button> never has.
2Landmark, Document, And Widget Roles
ARIA roles fall into a handful of families. Landmark roles (banner, navigation, main, contentinfo) mark large page regions; in modern HTML you get these automatically from <header>, <nav>, <main>, and <footer>, so explicit roles are rarely needed.
Widget roles (button, tab, slider, dialog, combobox, menu) describe interactive components. Some, like button, duplicate a native element and should be avoided per the First Rule. Others, like tab or slider (without a native <input type="range">-style fit), describe patterns HTML genuinely has no equivalent for — this is ARIA's legitimate, necessary use case.
3Roles Carry Real Behavioral Contracts
A role is not just a label read once — it's a contract. role="dialog" implies the assistive technology should expect focus to be trapped inside it and Escape to close it. role="alert" implies immediate, unprompted announcement, interrupting whatever the user was doing.
Applying these roles without implementing the matching behavior (trapping focus for a dialog, or reserving alert for genuinely urgent messages) creates a mismatch between what's promised and what actually happens — often a worse experience than having no ARIA at all, because the user's expectations, set by the role, go unmet.
4Step-by-Step Breakdown
Roles: Telling Assistive Tech What Something Is. An ARIA role declares what an element *is* to assistive technology: a button, a dialog, a tab, a slider. Native elements already carry an implicit role — <button> is role="button" for free. The role attribute exists mainly to patch semantics onto generic elements when no native equivalent exists.
The First Rule Of ARIA. The official First Rule of ARIA Use is simple: if a native HTML element or attribute already has the semantics you need, use it instead of re-purposing an element and adding ARIA. role="button" on a div is always a worse choice than a real <button>.
First Rule Of ARIA. According to the First Rule of ARIA Use, when should you reach for role="button" on a <div>?
- →Always, it's more flexible than <button>
- →Only when no native element provides that semantic
- →Whenever you need custom CSS styling
Landmark & Widget Roles. Roles fall into families. Landmark roles (navigation, main, banner) mark page regions and are usually better expressed with HTML5 elements like <nav> and <main>, which imply them automatically. Widget roles (tab, slider, dialog, combobox) describe interactive components HTML has no native equivalent for.
Role Families. Why is role="tab" a legitimate, necessary use of ARIA, unlike role="button"?
- →It isn't legitimate; <button> should always be used instead
- →HTML has no native tab-panel widget, so ARIA fills a genuine gap
- →It's purely for applying tab-shaped CSS styling
Roles Change Behavior, Not Just Labels. Adding role="dialog" doesn't just relabel an element — it changes how assistive technology and often the browser itself treats it, including focus trapping expectations. Misusing a role can actively break behavior that worked correctly before, which is why untested ARIA is often worse than no ARIA.
Roles Affect Behavior. Adding role="alert" to a <div> that appears after a failed form submission does what, beyond labeling?
- →Nothing beyond a cosmetic label change
- →It causes assistive technology to announce the content immediately, unprompted
- →It automatically moves keyboard focus into the div
ARIA Roles Mastered. You now know when ARIA roles are genuinely necessary versus when a native element is the better choice, and that roles like alert and dialog carry real behavioral consequences, not just labels.
Mark A Live Alert Region. ARIA roles describe what an element is when the tag itself doesn't say (role="alert" on a plain div).
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1ARIA Is Purely Declarative — It Implements Zero Behavior
Setting role="button" changes what assistive technology announces, but adds no focusability, keyboard handling, or styling; all of that remains the developer's responsibility, unlike with native elements.
2Misapplied Roles Can Make A Page Less Accessible Than No ARIA At All
A role sets an expectation contract with assistive technology (e.g. dialog implies focus trapping); failing to fulfill that contract confuses users more than omitting the role entirely.
SEO Implications
- 1
Excessive Or Incorrect ARIA Roles Can Confuse Structured-Data Parsers
Some SEO tooling and rich-result parsers reason about page landmarks; conflicting or redundant roles on top of already-semantic HTML can muddy that signal.
- 2
Native Landmark Elements Are Better Understood By Crawlers Than role Attributes Alone
Using <nav>, <main>, and <footer> gives both accessibility and SEO tooling a consistent, well-supported structural signal without relying on role attributes.
Best Practices
Reach For ARIA Only After Confirming No Native Element Fits
This is literally the W3C's First Rule of ARIA Use — it prevents the most common category of ARIA misuse, which is reimplementing native behavior poorly.
Test Every Custom role Against Its Full Behavioral Contract, Not Just Its Label
role="dialog" without focus trapping, or role="tab" without arrow-key navigation, breaks the interaction pattern users expect from that role in assistive technology.
Frequent Bugs
A custom modal has role="dialog" but focus escapes to the page behind it when tabbing.
The role's behavioral contract (focus trapping) wasn't implemented. Add a focus trap that cycles Tab/Shift+Tab within the dialog while it's open.
A status message uses role="alert" for routine, non-urgent updates and users complain about constant interruptions.
role="alert" is reserved for urgent, time-sensitive content. Use a softer live region (aria-live="polite") or no live region for routine updates.
Real-World Examples
Accessible Tab Pattern
A settings page with tabbed panels, built with the ARIA tab pattern since HTML has no native tabs element.
<div role="tablist" aria-label="Settings">
<button role="tab" aria-selected="true" id="t1">Profile</button>
<button role="tab" aria-selected="false" id="t2">Billing</button>
</div>
<div role="tabpanel" aria-labelledby="t1">...</div>