What Is ARIA?
ARIA stands for Accessible Rich Internet Applications. It is a technical specification from the W3C's Web Accessibility Initiative that extends HTML with a set of attributes designed to communicate the purpose, state, and properties of interactive interface elements to assistive technologies.
When a developer builds a custom dropdown menu, a modal dialogue, a tab panel, or a live-updating notification area using divs and JavaScript rather than native HTML elements, the browser has no way to communicate the interactive nature of those elements to a screen reader without ARIA.
ARIA attributes fall into three categories. Roles define what an element is, for example role="dialogue" tells a screen reader that a container functions as a modal dialogue, and role="tablist" identifies a set of navigable tabs.
States describe the current condition of an element, for example aria-expanded="true" tells a screen reader that a dropdown is currently open, and aria-checked="false" communicates a checkbox's unchecked state.
Properties provide additional descriptive information, for example aria-label="Close" gives an icon-only button a human-readable name, and aria-live="polite" tells a screen reader to announce updates to a region of the page as they occur.
The foundational rule of ARIA is that no ARIA is better than bad ARIA. If a native HTML element already communicates the correct semantics, use the native element.
A button element is inherently keyboard-focusable, activatable with both Enter and Space, and already exposes a button role to assistive technologies. A div styled to look like a button requires role="button", tabindex="0", and manual keyboard event handling to achieve the same result.
The native approach is always preferred. ARIA's purpose is to bridge the gap only where native HTML falls short, primarily in complex interactive widgets and single-page applications.
ARIA In Practice
A Cape Town-based retail website had a mobile navigation hamburger menu that opened a full-screen drawer.
Screen reader users reported that when they pressed the hamburger button, the drawer appeared visually but the screen reader announced nothing and focus remained on the button rather than moving into the open menu.
The fix required three additions: aria-expanded toggled between "true" and "false" on the button, aria-controls linking the button to the drawer by ID, and a JavaScript focus shift to the first link inside the drawer on open.
These changes took approximately 30 minutes to implement and made the navigation fully operable for blind users on their mobile devices.
For South African businesses investing in web accessibility, understanding ARIA is particularly important for custom-built components that are common in modern web development frameworks such as React, Vue, and Angular. Component libraries such as Headless UI and Radix UI apply ARIA attributes automatically.
When building custom components from scratch, developers should reference the WAI-ARIA Authoring Practices Guide, which provides keyboard interaction patterns and ARIA attribute requirements for every common widget type.
Getting ARIA right ensures that all customers, regardless of how they navigate the web, can use your website without barriers.
How ARIA works
ARIA (Accessible Rich Internet Applications) is a set of attributes you can add to HTML to make web content and applications more accessible to people using assistive technologies such as screen readers, particularly where standard HTML alone does not convey enough information. It works by providing extra semantic information, roles, states and properties, that assistive technologies use to understand and convey what elements are and do. For example, ARIA attributes can tell a screen reader that a custom element functions as a button, that a section is a navigation region, that a control is expanded or collapsed, or provide an accessible label for an element that has no visible text. This is especially important for dynamic, interactive content and custom components built with JavaScript, where native HTML semantics may be missing or insufficient, so ARIA fills the gap, ensuring that people relying on assistive technology can perceive and operate the interface. ARIA is thus a tool for accessibility, extending the information available to assistive technologies beyond what plain HTML provides, so that rich, interactive web experiences remain usable by everyone.
ARIA and accessible design
ARIA is a valuable accessibility tool, but it comes with an important principle: prefer native HTML where it does the job, and use ARIA to fill gaps rather than to replace proper semantics. A widely-cited rule is that no ARIA is better than bad ARIA, meaning incorrect or unnecessary ARIA can make accessibility worse than none, so ARIA should be used correctly and only where needed. Native HTML elements (a real button, a proper heading, a labelled form field) come with built-in accessibility that assistive technologies understand, so using them is usually better and simpler than recreating their behaviour with ARIA on generic elements. ARIA's proper role is where native HTML falls short, custom interactive components, dynamic content whose state changes, elements needing an accessible label they do not otherwise have, where attributes like aria-label, roles, and state properties convey what assistive technology needs. Beyond ARIA specifically, accessible design means the whole experience works for people with different abilities and technologies, of which correct semantic markup and ARIA where appropriate are part, alongside things like sufficient colour contrast, keyboard operability and alt text. Used correctly and sparingly to supplement good native HTML, ARIA helps ensure rich web content is accessible, which is both an ethical and, increasingly, a legal and practical expectation for websites, and part of an experience that genuinely works for all users.
FAQ
When should I use ARIA attributes?
Use ARIA only when native HTML cannot adequately describe the interface pattern. Prefer a native button element over a div with role="button".
Use ARIA for custom components that have no HTML equivalent, such as a custom dropdown menu, a live notification region, a modal dialogue, or a tab panel built entirely with divs and JavaScript. Incorrect ARIA is worse than no ARIA.
What is an aria-label and when do I use it?
aria-label provides a text alternative for an element when no visible label is present. It is most commonly used on icon-only buttons and navigation landmarks. A search button showing only a magnifying glass icon should have aria-label="Search" so screen reader users know its purpose.
When a visible label already exists, use aria-labelledby to reference it rather than duplicating text in aria-label.
When should you use ARIA attributes?
Use ARIA to fill gaps where native HTML does not convey enough accessibility information, chiefly for custom interactive components, dynamic content whose state changes, and elements needing an accessible label. Prefer native HTML elements where they do the job, since they come with built-in accessibility. The principle is that no ARIA is better than incorrect ARIA, so use it correctly and only where needed.
What is an aria-label and when do you use it?
An aria-label is an ARIA attribute that provides an accessible name for an element, read by screen readers, when the element has no visible text label of its own, such as an icon-only button. You use it to give assistive technology a clear label for elements whose purpose would otherwise be unclear without visible text, ensuring they are understandable to screen-reader users.