Using ARIA Roles Correctly in Your Web App
Understand how to enhance screen reader support using ARIA roles and landmarks.
The First Rule of ARIA
The first rule of ARIA is: don't use ARIA. That sounds contradictory, but it's the official guidance from the W3C. If a native HTML element or attribute provides the semantics you need, use that instead. A <button> element is always better than a <div role="button"> because it comes with keyboard handling, focus management, and screen reader announcements built in.
ARIA exists to fill gaps where HTML falls short — custom widgets, dynamic content updates, and complex interaction patterns that don't have native equivalents.
Landmark Roles
Landmark roles define the major regions of a page. Screen reader users rely on these to navigate quickly — they can jump between landmarks the same way sighted users scan visual layout.
The key landmarks and their HTML equivalents:
<header>→role="banner"(site-wide header)<nav>→role="navigation"<main>→role="main"<footer>→role="contentinfo"(site-wide footer)<aside>→role="complementary"
In most cases, you should use the HTML elements directly. They carry the correct roles automatically. Only add explicit ARIA roles when you need to override default behavior or support older assistive technologies.
Live Regions
One area where ARIA is genuinely essential is announcing dynamic content updates. When content changes without a page reload — a form validation error appears, a notification pops up, a counter updates — sighted users see the change immediately. Screen reader users need to be told about it.
The two most useful live region attributes:
aria-live="polite"— announces the change when the user is idle (use this for most cases)aria-live="assertive"— interrupts whatever the screen reader is currently saying (use only for urgent messages like errors)
Common Mistakes to Avoid
These are the ARIA antipatterns we see most frequently in code reviews:
- Using
role="button"on a<div>without adding keyboard event handlers. The role alone doesn't make it behave like a button — you still needtabindex="0",keydownhandlers for Enter and Space, and proper focus styling. - Redundant ARIA. Adding
role="navigation"to a<nav>element, oraria-required="true"to an input that already has therequiredattribute. This clutters the accessibility tree without adding information. - Using
aria-hidden="true"on focusable elements. This creates a confusing experience where keyboard users can focus on something that screen readers can't see. - Missing
aria-labelon icon-only buttons. If a button contains only an icon with no visible text, it needs anaria-labelto communicate its purpose.
Triforce Team
The Triforce Software team shares insights on software development, accessibility, and performance.
No comments yet. Login to start a new discussion Start a new discussion