Triforce Software

Using ARIA Roles Correctly in Your Web App

Understand how to enhance screen reader support using ARIA roles and landmarks.

 · 2 min read

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:

  1. Using role="button" on a <div> without adding keyboard event handlers. The role alone doesn't make it behave like a button — you still need tabindex="0", keydown handlers for Enter and Space, and proper focus styling.
  2. Redundant ARIA. Adding role="navigation" to a <nav> element, or aria-required="true" to an input that already has the required attribute. This clutters the accessibility tree without adding information.
  3. 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.
  4. Missing aria-label on icon-only buttons. If a button contains only an icon with no visible text, it needs an aria-label to communicate its purpose.

TT
Triforce Team

The Triforce Software team shares insights on software development, accessibility, and performance.

No comments yet.

Add a comment
Ctrl+Enter to add comment