ARIA

ARIA stands for Accessible Rich Internet Applications. It is a set of attributes that helps communicate meaning, roles, states, and relationships to assistive technologies when native HTML alone is not enough. The goal is not to make a website “look accessible.” The goal is to make interactive interfaces understandable and usable for people who rely on screen readers, keyboard navigation, and other assistive tools.

ARIA should support good HTML, not replace it. When native HTML can already describe an element correctly, use native HTML first.

What ARIA Does

HTML already carries meaning. A <button> tells the browser and assistive technologies that the element is a button. A <nav> identifies navigation. A <main> identifies the main content area. A form input with a proper <label> communicates what the field is for.

ARIA becomes useful when an interface includes custom components or dynamic behavior that native HTML cannot fully describe on its own. For example, a custom accordion may need to tell assistive technologies whether a section is expanded or collapsed. A notification area may need to announce new content without forcing the user to move focus. A form field may need additional descriptive text or an error state.

ARIA can provide this missing accessibility layer through roles, properties, and states. However, it does not add visual styling, keyboard behavior, focus management, validation logic, or JavaScript functionality by itself. It only communicates semantics. The actual interaction still needs to be built correctly.

Native HTML Comes First

The first rule of ARIA is simple: do not use ARIA when native HTML already provides the correct meaning and behavior. W3C guidance is very clear that incorrect ARIA can make an interface less accessible, not more accessible. “No ARIA is better than bad ARIA” exists because ARIA changes how assistive technologies interpret an element. If that interpretation does not match the real behavior, users receive the wrong information.

For example, this is not ideal:

<div role="button">Submit</div>

A real button is better:

<button type="submit">Submit</button>

The native <button> already supports the correct role, keyboard behavior, focus handling, and expected browser behavior. Rebuilding that behavior on a <div> creates unnecessary risk.

ARIA should be used when the accessibility information cannot be expressed clearly with HTML alone. It should not be used to compensate for poor structure, missing labels, broken focus order, or inaccessible JavaScript.

How ARIA Works

ARIA usually works through three types of information: roles, properties, and states.

A role describes what an element is. For example: role="dialog" tells assistive technologies that an element represents a dialog. A property describes a relationship or characteristic, such as aria-labelledby, aria-describedby, or aria-controls. A state describes the current condition of an element, such as aria-expanded="true" or aria-invalid="true".

For example, an accordion button may look like this:

<button
  type="button"
  aria-expanded="false"
  aria-controls="faq-answer-1"
>
  What is ARIA?
</button>

<div id="faq-answer-1" hidden>
  ARIA helps communicate accessibility information when native HTML is not enough.
</div>

In this example, aria-expanded tells assistive technologies whether the controlled content is open or closed. aria-controls identifies the related content area. But the ARIA attributes alone do not open or close anything. JavaScript still needs to update the visibility and change aria-expanded when the user interacts with the button.

Common ARIA Attributes

Some ARIA attributes are used often because they solve practical accessibility problems.

aria-label provides an accessible name when visible text is not available. For example, an icon-only search button may need aria-label="Search".

<button type="button" aria-label="Search">
  <svg aria-hidden="true">...</svg>
</button>

aria-labelledby connects an element to visible text that labels it. This is often better than aria-label because it reuses text that users can already see.

<section aria-labelledby="pricing-heading">
  <h2 id="pricing-heading">Pricing</h2>
  <p>Compare available plans and features.</p>
</section>

aria-describedby connects an element to supporting explanatory text. This is useful for form guidance, helper text, or error messages.

<label for="email">Email address</label>
<input id="email" type="email" aria-describedby="email-help">
<p id="email-help">Use the email address connected to your account.</p>

aria-expanded communicates whether a collapsible control is open or closed. It is commonly used for accordions, dropdowns, and disclosure components.

aria-current identifies the current item in a set, such as the current page in navigation.

<a href="/seo" aria-current="page">SEO</a>

aria-invalid can communicate that a form field currently contains an error.

<input id="email" type="email" aria-invalid="true" aria-describedby="email-error">
<p id="email-error">Please enter a valid email address.</p>

These attributes are useful when they match the actual interface state. They become harmful when they are added without being updated, tested, or connected to real behavior.

ARIA and Forms

Forms are one of the most common places where ARIA is misused. In most cases, a proper <label> should come before ARIA.

This is the correct foundation:

<label for="first-name">First name</label>
<input id="first-name" name="firstName" type="text">

ARIA can then support additional context when needed:

<label for="password">Password</label>
<input
  id="password"
  name="password"
  type="password"
  aria-describedby="password-requirements"
>
<p id="password-requirements">
  Use at least 12 characters, including a number and a symbol.
</p>

If there is an error, the error message should be connected to the field:

<label for="password">Password</label>
<input
  id="password"
  name="password"
  type="password"
  aria-invalid="true"
  aria-describedby="password-error"
>
<p id="password-error">
  Password must include at least 12 characters.
</p>

This approach keeps the structure clear. The visible label tells all users what the field is for. ARIA adds extra context for assistive technologies where necessary.

ARIA and Interactive Components

ARIA becomes more important when websites use custom interactive components such as accordions, tabs, dialogs, menus, comboboxes, sliders, and live notifications. These components often require more than a role. They also require correct keyboard interaction, focus management, state updates, and expected behavior. W3C’s ARIA Authoring Practices Guide provides design patterns and examples for these types of components.

A modal dialog is a good example. Adding role="dialog" is not enough. A proper dialog also needs a clear accessible name, focus should move into the dialog when it opens, keyboard users should be able to close it, and focus should return to the triggering element when it closes.

<div
  role="dialog"
  aria-modal="true"
  aria-labelledby="dialog-title"
>
  <h2 id="dialog-title">Confirm booking</h2>
  <p>Please confirm that the booking details are correct.</p>

  <button type="button">Cancel</button>
  <button type="button">Confirm</button>
</div>

The ARIA attributes describe the dialog. They do not complete the dialog behavior. Without correct JavaScript and focus handling, the component may still be inaccessible.

ARIA Is Not a Fix for Bad Structure

ARIA cannot repair a page that has poor semantic structure. If a page has no logical heading hierarchy, missing landmarks, unlabeled controls, broken keyboard navigation, or unclear content relationships, adding ARIA will not solve the underlying issue.

A well-structured page should already use semantic HTML:

<header>
  <nav aria-label="Main navigation">
    ...
  </nav>
</header>

<main>
  <article>
    <h1>ARIA</h1>
    ...
  </article>
</main>

<footer>
  ...
</footer>

In this example, ARIA is used lightly. The aria-label helps distinguish the navigation area, but the main structure still comes from HTML. This is the right balance.

The most dangerous mistake is creating a mismatch between what users see and what assistive technologies announce. For example, if a menu is visually open but aria-expanded="false" remains unchanged, screen reader users receive incorrect information. If a required form field has an error message that is not programmatically connected to the input, some users may not know what needs to be fixed.

Good ARIA requires consistency between markup, visual state, interaction state, and assistive technology output.

How to Use ARIA Properly

The safest approach is to start with semantic HTML. Use the correct element first. Then add ARIA only when there is a specific accessibility gap that HTML cannot solve by itself.

When using ARIA, check three things:

1. First, the element must have the right role or accessible name.
2. Second, the ARIA state must match the actual visual and functional state.
3. Third, the interaction must work with keyboard and assistive technologies, not just with a mouse.

ARIA should also be tested. Automated tools can catch some issues, but they cannot fully confirm whether a custom component behaves correctly for real users. Keyboard testing and screen reader testing are important for interactive patterns.

Why ARIA Matters

ARIA matters because modern websites are no longer made only of static documents. They include dynamic menus, filters, modals, tabs, alerts, forms, dashboards, and application-like interfaces. Without proper accessibility semantics, these experiences can become confusing or unusable for people relying on assistive technologies.

But ARIA only works when it is used with discipline. It should be precise, minimal, and tied to real behavior. The best accessibility foundation is still clean HTML, logical structure, visible labels, keyboard support, and predictable interaction.

ARIA is not the foundation of accessibility. It is an enhancement layer for situations where native HTML needs help. When used properly, it makes complex interfaces clearer. When used carelessly, it creates false information.

The goal is not to add more ARIA. The goal is to make the interface honest, understandable, and usable.