Frontend Patterns

Pattern

ARIA Roles and Attributes

Use ARIA roles and attributes to provide semantic information to assistive technologies when HTML semantics are insufficient.

ARIA Roles and Attributes

Problem

When semantic HTML alone cannot convey the full meaning or state of UI components, assistive technologies like screen readers lack the information needed to help users navigate and interact with the interface. Custom widgets, dynamic content, and complex interactions become inaccessible to users who rely on these technologies.

Solution

Add ARIA roles to define widget types (dialog, menu, tab) and ARIA attributes to communicate state (aria-expanded, aria-selected) and properties (aria-label, aria-describedby). This gives screen readers the semantic information they need to describe and operate custom components.

Example

This example demonstrates using ARIA attributes to create an accessible dropdown menu that communicates its state and purpose to screen readers.

<!-- Button that controls a dropdown menu -->
<button
  aria-expanded="false"         <!-- Indicates the menu is currently collapsed -->
  aria-controls="dropdown-menu" <!-- Links this button to the menu it controls -->
  aria-label="User settings"    <!-- Provides descriptive label for screen readers -->
>
  Settings
</button>

<!-- The dropdown menu itself -->
<ul id="dropdown-menu" role="menu" aria-hidden="true">
  <li role="menuitem">Profile</li> <!-- Each item is identified as a menu item -->
  <li role="menuitem">Logout</li>
</ul>

Benefits

  • Makes custom widgets understandable to screen readers and assistive technologies.
  • Communicates dynamic state changes that HTML alone cannot express.
  • Essential for creating accessible complex components like tabs and dialogs.
  • Provides semantic context for elements that have no native HTML equivalent.
  • Improves keyboard navigation by clarifying component relationships.

Tradeoffs

  • Incorrect ARIA is worse than no ARIA, creating confusing experiences.
  • Requires deep understanding of accessibility specifications to use properly.
  • Easy to misuse or apply redundantly when semantic HTML would suffice.
  • Testing requires actual screen reader usage to verify correct behavior.
  • Browser and screen reader support can vary for less common ARIA attributes.
Stay Updated

Get New Patterns
in Your Inbox

Join thousands of developers receiving weekly insights on frontend architecture patterns

No spam. Unsubscribe anytime.