Boosting Accessibility with ARIA Roles and Attributes

Published on: by Dr. Talib

Using semantic HTML is the first and most important step toward an accessible website. But what happens when you build complex, JavaScript-driven widgets like tab panels, custom dropdowns, or modals? Standard HTML tags often can't describe the purpose or state of these components. This is where **ARIA (Accessible Rich Internet Applications)** comes in. ARIA is a set of attributes you can add to HTML elements to bridge these gaps for assistive technologies like screen readers.

The First Rule of ARIA: Don't Use ARIA

This sounds contradictory, but it's the most important principle. Before you reach for an ARIA attribute, always try to use a native semantic HTML element instead. A native <button> is already keyboard-accessible and understood by screen readers. A <div> that you make look like a button with CSS is not. You should only use ARIA when a native HTML element doesn't exist for your purpose.

If you can use a native HTML element (like <button>, <nav>, <dialog>), use it. It comes with built-in accessibility for free.

Understanding ARIA Roles

The Concept: The role attribute tells assistive technology what an element *is* or what it *does*. For example, if you build a set of tabs using `div` elements, a screen reader has no idea it's a tab interface. By adding roles, you provide that crucial context.

Example of an Accessible Tab List:

<!-- By adding these roles, a screen reader can announce:
     "Tab list, with 3 tabs. Tab 1 of 3, selected." -->
<div role="tablist">
  <button role="tab" aria-selected="true">Tab 1</button>
  <button role="tab" aria-selected="false">Tab 2</button>
  <button role="tab" aria-selected="false">Tab 3</button>
</div>

<div role="tabpanel">Content for Tab 1.</div>
<div role="tabpanel" hidden>Content for Tab 2.</div>
<div role="tabpanel" hidden>Content for Tab 3.</div>

Other common roles include dialog (for modals), alert (for error messages), progressbar, and menu.

Understanding ARIA States and Properties

The Concept: While roles define *what* an element is, ARIA properties and states define its current condition. These attributes, which all start with aria-, are typically managed with JavaScript.

Key ARIA Attributes:

  • aria-label: Provides an accessible name for an element that has no visible text. This is perfect for icon-only buttons.
  • aria-selected: Indicates whether a tab in a `tablist` is currently selected (`true` or `false`).
  • aria-expanded: Indicates whether a collapsible element like an accordion panel is currently open (`true`) or closed (`false`).
  • aria-hidden: Hides an element from assistive technology. Setting aria-hidden="true" is useful for off-screen menus or decorative elements that would just add noise.
  • aria-required: Indicates that a form input must be filled out (`true` or `false`).

Example of `aria-label` for an icon button:

<!-- A screen reader will ignore the icon and announce: "Close" -->
<button aria-label="Close">
  <svg> ... an X icon ... </svg>
</button>

Putting it together: A good developer will use JavaScript to update these ARIA states as the user interacts with the page. When a user clicks a tab button, the script should set its aria-selected to `true` and all others to `false`.

Making the Dynamic Web Accessible

As web applications become more complex and interactive, relying solely on standard HTML isn't enough to ensure they are usable by everyone. ARIA provides the essential toolkit for describing the roles, states, and properties of your custom widgets to assistive technologies. It's a fundamental part of modern, professional front-end development and a cornerstone of building an inclusive web.