ARIA Basics

Understanding ARIA Basics

ARIA provides additional information about webpage elements so browsers and assistive technologies can better understand certain interfaces and controls.

ARIA stands for Accessible Rich Internet Applications. It provides roles, states, and properties that can supplement HTML when native elements do not communicate everything an interface requires, but ARIA should not replace appropriate semantic HTML when HTML already provides the necessary meaning and behavior.

What Is ARIA?

ARIA is a set of attributes that can communicate additional information about elements to assistive technologies. This information becomes part of the accessibility information exposed by the browser.

ARIA is particularly useful for dynamic interfaces and custom components whose purpose, state, or relationships cannot be communicated completely with native HTML alone.

ARIA does not change how an element looks. It primarily changes or supplements how the element is represented to assistive technologies.

Use Native HTML First

The first rule when working with ARIA is simple: if a native HTML element already provides the required semantics and behavior, use the native element.

For example, HTML already provides a button:

<button type="button">Save Changes</button>

Creating a generic element and assigning it a button role is usually unnecessary:

<div role="button">Save Changes</div>

The native <button> includes button semantics, keyboard focus, and expected keyboard behavior. Adding role="button" to a <div> supplies a role but does not automatically provide those behaviors.

ARIA Roles

A role communicates what an element represents or how it functions. Some HTML elements already have an implicit role, while ARIA can provide explicit roles when they are necessary.

Do not add an explicit ARIA role when the native HTML element already supplies the same role unless there is a specific reason to do so.

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

In this example, <nav> already supplies the navigation landmark. The ARIA attribute provides the landmark with an accessible name rather than replacing its native role.

ARIA Properties and States

ARIA properties provide additional information about an element or its relationships, while ARIA states communicate information that may change as the visitor interacts with the page.

ARIA states must remain synchronized with the actual state of the interface. An attribute that says a component is collapsed when it is visibly expanded provides incorrect information rather than improving accessibility.

Accessible Names

An accessible name identifies an element to assistive technology. For example, a screen reader needs a meaningful name for a button so the user knows what action the button performs.

Native HTML often supplies an accessible name without ARIA:

<button type="button">Search</button>

The visible text Search provides the button's accessible name. Form controls can receive their names from properly associated <label> elements.

<label for="email">Email Address</label>
<input type="email" id="email" name="email">

ARIA naming attributes are useful when the required accessible name cannot be supplied appropriately through the native HTML content or labeling mechanism.

Using aria-label

The aria-label attribute supplies an accessible name directly as an attribute value. It is useful when a control has no suitable visible text label.

<button type="button" aria-label="Close">
  <span aria-hidden="true">&times;</span>
</button>

In this example, the button can be announced as Close while the multiplication symbol is hidden from assistive technology because it is only being used as a visual icon.

Do not use aria-label simply to replace useful visible text. Visible labels benefit people who use assistive technology as well as people who do not.

Using aria-labelledby

The aria-labelledby attribute identifies one or more elements whose text should provide the accessible name for another element.

<h2 id="newsletter-title">Garden Newsletter</h2>

<section aria-labelledby="newsletter-title">
  <p>Monthly gardening tips and seasonal advice.</p>
</section>

The section receives the accessible name Garden Newsletter from the heading. This creates a programmatic relationship without duplicating the heading text in an ARIA attribute.

The value of aria-labelledby contains element IDs rather than the label text itself.

Using aria-describedby

The aria-describedby attribute associates an element with additional information that describes it. This is useful for form instructions, requirements, hints, and certain error messages.

<label for="password">Password</label>
<input type="password"
       id="password"
       name="password"
       aria-describedby="password-help">
<p id="password-help">Use at least 12 characters.</p>

The visible label identifies the field, while the associated paragraph provides additional information about the password requirement.

An accessible name and an accessible description serve different purposes. The name identifies the control; the description provides supporting information.

Using aria-expanded

The aria-expanded attribute communicates whether a collapsible or expandable interface controlled by an element is currently open or closed.

<button type="button"
        aria-expanded="false"
        aria-controls="garden-tips">
  Garden Tips
</button>

<div id="garden-tips" hidden>
  <p>Water plants early in the morning.</p>
</div>

When the controlled content is opened, the button's value should change to aria-expanded="true". When the content is closed again, it should return to false.

ARIA describes the state; JavaScript or native HTML behavior must actually perform the interaction and keep the ARIA value synchronized with what is displayed.

Using aria-hidden

The aria-hidden="true" attribute removes an element and its descendants from the accessibility tree without necessarily removing it visually from the page.

One common use is hiding a decorative icon when nearby text already communicates its meaning:

<button type="button">
  <i class="fa-solid fa-magnifying-glass" aria-hidden="true"></i>
  Search
</button>

The word Search already gives the button a meaningful accessible name, so announcing the decorative icon separately would add unnecessary information.

Do not apply aria-hidden="true" to focusable elements or to content that users of assistive technology need in order to understand or operate the page.

ARIA Does Not Add Behavior

ARIA can communicate what a component is and what state it is in, but it does not automatically make the component behave like the role it represents.

<div role="button">Show Details</div>

Adding role="button" does not automatically make the <div> keyboard focusable or make the Enter and Space keys activate it. Those behaviors would need to be implemented separately.

Compare that with native HTML:

<button type="button">Show Details</button>

The native button already provides the expected semantics and keyboard behavior. This is why native HTML should usually be the first choice.

Testing ARIA

ARIA should be tested rather than assumed to work because the markup appears correct. Incorrect ARIA can provide misleading information to assistive technology even when the page looks perfectly normal.

Use the keyboard to verify that interactive components can be reached and operated. When ARIA states such as aria-expanded are used, confirm that their values change when the visible interface changes.

Browser accessibility inspection tools can help reveal computed roles, names, descriptions, and states. Testing with a screen reader can then help determine how that information is communicated during actual navigation and interaction.

ARIA Example

The following example uses native HTML wherever possible and adds ARIA only where it provides useful additional information.

<nav aria-label="Garden resources">
  <a href="/gardening-guide.html">Gardening Guide</a>
  <a href="/plant-care.html">Plant Care</a>
</nav>

<label for="email">Email Address</label>
<input type="email"
       id="email"
       name="email"
       aria-describedby="email-help">
<p id="email-help">We will send gardening tips once a month.</p>

<button type="button" aria-label="Close">
  <span aria-hidden="true">&times;</span>
</button>

Experiment with the visible labels and ARIA attributes in the editor. The page may look nearly identical after some changes, which demonstrates why ARIA must be evaluated through the accessibility information it provides rather than appearance alone.

Best Practices

• Use semantic native HTML whenever it provides the required meaning and behavior.
• Do not add redundant ARIA roles to elements that already have the appropriate native semantics.
• Provide meaningful accessible names for interactive controls.
• Prefer visible labels when they can clearly identify controls.
• Use aria-labelledby when existing visible content should provide an accessible name.
• Use aria-describedby for useful supporting descriptions and instructions.
• Keep dynamic ARIA states synchronized with the actual interface.
• Use aria-hidden carefully and never hide information that assistive technology users need.
• Remember that ARIA roles and states do not automatically provide keyboard interaction or other behavior.
• Test ARIA with browser accessibility tools, keyboard navigation, and assistive technology when appropriate.
• Do not add ARIA merely because an element can accept an ARIA attribute.

Summary

ARIA supplements HTML by providing roles, states, properties, names, descriptions, and relationships that can help assistive technologies understand interfaces that native HTML cannot completely describe on its own.

The most important ARIA principle is to begin with appropriate HTML. Native elements already provide much of the accessibility information and behavior a webpage needs, while carefully chosen ARIA can supply additional information when it has a specific purpose.