In modern web development, digital accessibility (commonly abbreviated as A11y) is no longer a luxury or an afterthought—it is a core quality standard. Creating interfaces that everyone can navigate, regardless of physical or cognitive ability, begins with semantic HTML.
However, when building complex, custom UI components like accordions, modal dialogs, and tab panels, standard native HTML elements sometimes fall short in describing their role or state to assistive technologies. That is where WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) comes into play.
In this article, we’ll cover the fundamental rules of WAI-ARIA and dissect how to properly use attributes such as role, aria-label, and aria-hidden to enhance your application’s accessibility.
1. Why Do We Need WAI-ARIA?
HTML5 provides native “semantic” elements such as <button>, <nav>, <main>, and <header>. Browsers automatically map these tags to the accessibility tree, translating them into roles and states that screen readers can interpret.
But semantic gaps appear in two primary scenarios:
- When constructing interactive widgets not natively represented in HTML (e.g., custom dropdowns, carousels, or trees).
- When dynamic state changes (driven by JavaScript) must be synchronized with assistive devices (e.g., announcing when an expandable section collapses).
WAI-ARIA acts as a bridge, enriching native HTML elements with the metadata necessary for assistive technologies to accurately interpret the layout and state of your application.
2. The First Rule of ARIA: Don’t Use It
The WAI-ARIA specification features a fundamental rule that all developers must learn first:
“If you can use a native HTML element or attribute with the semantics and behavior you require already built-in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.”
For example, if you need to create a clickable button, it is far better to use the native <button> element rather than attaching role="button" to a <div> element.
Native <button> elements naturally support:
- Keyboard focus (automatically added to the Tab order).
- Default execution keys (triggers on Enter and Space keypresses).
- Explicit screen-reader announcements identifying it as a “button”.
<!-- Anti-pattern: Requires manual javascript and tabindex configuration -->
<div role="button" tabindex="0" onclick="submitForm()">Submit</div>
<!-- Correct: Fully accessible and interactive by default -->
<button onclick="submitForm()">Submit</button>
3. Core WAI-ARIA Attributes and Practices
When native elements are not enough, leverage WAI-ARIA properties carefully. Here are the three most common tools in the ARIA suite:
① The role Attribute (Component Context)
Defines what a specific element does or is (e.g., tablist, dialog, status, or alert).
<div role="tablist">
<button role="tab" aria-selected="true" id="tab-a">Tab A</button>
<button role="tab" aria-selected="false" id="tab-b">Tab B</button>
</div>
② aria-label and aria-labelledby (Explicit Naming)
Supplies a readable text label when no visible text is present (like icon buttons), or connects an element to a heading.
<!-- Textless icon button labeled explicitly for screen readers -->
<button aria-label="Close Dialog">×</button>
<!-- Labeling a wrapper container using an existing header's ID -->
<h2 id="modal-title">Settings</h2>
<div role="dialog" aria-labelledby="modal-title">
<!-- Dialog Content -->
</div>
③ aria-hidden (Hiding Visual Noise)
Excludes pure decorative visuals (like icon fonts, SVGs, or illustrations) from the accessibility tree, preventing screen readers from reading raw text glyphs or useless elements.
<button>
<span class="icon-trash" aria-hidden="true"></span>
<span>Delete Item</span>
</button>
Conclusion
WAI-ARIA is a powerful tool designed to make rich, dynamic interfaces accessible. However, incorrect ARIA configurations—such as conflicting roles or neglecting keyboard event handlers—can actually make interfaces worse for users of assistive technologies.
Always prioritize clean, semantic, native HTML markup, and layer WAI-ARIA on top only when native structures cannot represent the current user interface’s states and roles.