If native HTML provides the correct semantics, use native HTML.

What Is ARIA?

ARIA is a technical specification formally known as WAI-ARIA, or Web Accessibility Initiative — Accessible Rich Internet Applications. It provides attributes that developers can add to HTML to describe interface patterns that may not be fully expressed by native HTML alone.

For example, ARIA can help communicate:

• what role an element plays in an interface, such as a tab, dialog, menu, or alert;
• whether something is expanded, selected, disabled, hidden, or checked;
• how one element relates to another;
• when dynamic content has changed on the page.

Assistive technologies use this information to help users understand and operate web interfaces. ARIA can be especially important for JavaScript-driven components, custom widgets, single-page applications, and dynamic user interfaces.

ARIA is part of a broader accessibility landscape that includes semantic HTML and keyboard accessibility.

Why ARIA Exists

The web began with documents. HTML was designed to describe headings, paragraphs, links, lists, forms, tables, and other document structures. Over time, websites became more interactive. Modern pages may include accordions, modals, autocomplete fields, dynamic alerts, drag-and-drop tools, tab panels, dashboards, and application-like interfaces.

Many of these patterns are built with JavaScript and CSS. Visually, they may appear clear to a sighted mouse user. But if the underlying HTML does not communicate the same meaning programmatically, assistive technologies may not be able to interpret the interface correctly.

ARIA exists to help close that gap.

It gives developers a way to add accessibility information when native HTML semantics are not enough. That information can help a screen reader announce what an element is, what state it is in, and how it behaves.

ARIA does not make an inaccessible interface accessible by itself. It communicates meaning. The interface still needs to be operable, understandable, and designed with accessibility in mind.

HTML Before ARIA

The first accessibility solution should usually be native HTML. Native HTML elements already carry built-in meaning, browser behavior, and accessibility support.

For example:

• Use a real <button> for an action instead of a clickable <div>.
• Use a real <a href=""> link for navigation.
• Use <label> elements for form controls.
• Use heading elements in logical order.
• Use lists when content is actually a list.
• Use native form inputs when they match the interaction needed.

Native elements often include keyboard behavior automatically. A button can be focused. It can be activated with the keyboard. It exposes itself to assistive technology as a button. Recreating all of that behavior on a generic element is possible, but it is easy to get wrong.

ARIA can change how an element is announced, but it does not automatically provide all native browser behavior. Adding role="button" to a <div> does not automatically make it behave exactly like a real button.

This is why the phrase “HTML before ARIA” is so important. The more a page uses the right HTML elements from the beginning, the less ARIA it usually needs.

Native HTML vs ARIA

Native HTML and ARIA are not competing systems. They serve different purposes.

A simple example is a button:

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

This is usually better than:

<div role="button" tabindex="0">Save changes</div>

The second example may be made accessible with additional work, but the first example starts with the correct semantics and expected behavior. It is simpler, more durable, and less likely to break across browsers or assistive technologies.

Roles, States, and Properties

ARIA is commonly understood through three main categories: roles, states, and properties.

ARIA Roles

A role tells assistive technology what an element is or what function it serves.

Examples include:

• role="button"
• role="dialog"
• role="tab"
• role="tabpanel"
• role="alert"
• role="navigation"
• role="search"

Some roles duplicate native HTML landmarks. For example, <nav> already communicates navigation, so role="navigation" is often unnecessary when using the native element correctly.

ARIA States

A state describes a condition that may change as the user interacts with the interface.

Common examples include:

• aria-expanded="true" or aria-expanded="false"
• aria-selected="true" or aria-selected="false"
• aria-checked="true", false, or mixed
• aria-disabled="true"
• aria-hidden="true"

States need to stay synchronized with the visible interface. If a menu is visually open but still marked as aria-expanded="false", assistive technology users may receive incorrect information.

ARIA Properties

A property describes an element or defines a relationship between elements.

Common examples include:

• aria-label
• aria-labelledby
• aria-describedby
• aria-controls
• aria-live
• aria-required
• aria-invalid

For instance, aria-describedby can connect an input field to explanatory text, while aria-labelledby can connect a dialog to its visible heading.

Common ARIA Attributes

ARIA includes many attributes, but a few appear frequently in everyday accessibility work.

aria-label

aria-label provides an accessible name when no visible text label is available.

<button aria-label="Close dialog">×</button>

This can be useful for icon-only buttons. However, visible labels are often better when possible because they help more users, including people who do not use assistive technology.

aria-labelledby

aria-labelledby points to another element that labels the current element.

<h2 id="dialog-title">Account settings</h2>

<div role="dialog" aria-labelledby="dialog-title">
  ...
</div>

This is often preferred over aria-label when a visible label already exists.

aria-describedby

aria-describedby connects an element to additional descriptive information.

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

This can help users understand requirements, error messages, or supporting instructions.

aria-expanded

aria-expanded communicates whether a collapsible area is open or closed.

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

<div id="faq-answer-1" hidden>
  ARIA helps communicate interface meaning to assistive technologies.
</div>

If JavaScript opens the content, the value should change to aria-expanded="true". The accessibility state should match the visual state.

aria-hidden

aria-hidden="true" hides content from assistive technologies.

This can be useful for decorative icons or duplicated visual content, but it should be used carefully. If meaningful content is hidden with aria-hidden="true", some users may never receive that information.

ARIA and Keyboard Accessibility

ARIA communicates meaning, but it does not automatically make an interface keyboard accessible.

Keyboard accessibility means users can navigate and operate an interface without a mouse. This matters for screen reader users, people with motor disabilities, power users, and anyone using alternative input devices.

Important keyboard considerations include:

• interactive elements should be reachable with the keyboard;
• focus order should be logical;
• visible focus indicators should be clear;
• custom widgets should support expected keyboard patterns;
• focus should be managed carefully in dialogs, menus, and dynamic interfaces;
• keyboard users should not become trapped unless the pattern intentionally requires temporary focus containment, such as in a modal dialog.

A custom component may have accurate ARIA attributes and still be difficult or impossible to use if keyboard behavior is missing. Accessibility depends on both semantics and interaction.

Forms and Interactive Components

Forms are one of the most common places where accessibility problems appear. Many form issues can be solved with native HTML before ARIA is needed.

Accessible forms generally need:

• clear labels;
• properly associated <label> elements;
• help text when requirements are not obvious;
• clear error messages;
• programmatic error relationships when needed;
• keyboard-accessible controls;
• logical grouping for related fields.

For example, a required email field may be written using native HTML:

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

If the field has an error message, ARIA may help connect that message to the field:

<label for="email">Email address</label>
<input
  id="email"
  name="email"
  type="email"
  required
  aria-invalid="true"
  aria-describedby="email-error">

<p id="email-error">Enter a valid email address.</p>

Here, ARIA supplements the HTML. It does not replace the label, input type, or visible error message.

Live Regions and Dynamic Content

Modern interfaces often update without reloading the page, that can be called dynamic content. A cart total may change. A form error may appear. A search result count may update. A notification may be displayed after an action.

For sighted users, these changes may be visually obvious. For screen reader users, they may not be announced unless the page communicates the update.

ARIA live regions can help.

<div aria-live="polite" id="status-message">
  Your changes have been saved.
</div>

The aria-live attribute tells assistive technologies that content in that region may change and should be announced.

Common values include:

• aria-live="polite": announces updates when the assistive technology is ready;
• aria-live="assertive": announces updates more urgently and may interrupt current speech;
• aria-live="off": does not announce updates unless the region receives focus.

Live regions should be used thoughtfully. If too many updates are announced, the experience can become noisy and difficult to understand. Most routine updates should use polite. Reserve assertive announcements for truly important messages, such as critical errors or time-sensitive warnings.

Common ARIA Mistakes

ARIA can improve accessibility when used correctly, but poor implementation can make an interface less accessible. A common accessibility saying is:

No ARIA is often better than bad ARIA.

This does not mean ARIA should be avoided entirely. It means ARIA should be used with understanding, testing, and respect for native HTML.

Using ARIA When Native HTML Would Work

If a native element already provides the right semantics and behavior, use it. A real button is usually better than a generic element with role="button".

Changing Semantics Incorrectly

ARIA can override or alter how an element is exposed to assistive technologies. Applying the wrong role can confuse users and create inaccurate expectations.

Forgetting to Update States

If an accordion opens, aria-expanded should update. If a tab is selected, aria-selected should reflect that selection. ARIA states must stay aligned with the visible interface.

Hiding Meaningful Content

aria-hidden="true" removes content from the accessibility tree. It should not be used on content that users need in order to understand or operate the page.

Adding Labels That Conflict With Visible Text

Accessible names should usually align with visible labels. If the visible button says “Submit” but the ARIA label says “Continue application,” users may receive inconsistent information depending on how they interact with the page.

Assuming ARIA Solves Keyboard Problems

ARIA does not automatically add keyboard behavior. Custom controls need keyboard support, focus management, and expected interaction patterns.

Testing ARIA

ARIA should be tested because accessibility is experienced through real interaction, not only through code inspection.

Useful testing approaches include:

• navigating the page with only a keyboard;
• checking whether focus order is logical;
• confirming that visible focus indicators are present;
• using browser accessibility inspection tools;
• testing with screen readers when possible;
• running automated accessibility tools to catch common issues;
• reviewing components against established accessibility patterns.

Automated tools can be helpful, but they cannot fully determine whether an experience is understandable. They may detect missing labels, invalid ARIA attributes, or contrast issues, but they cannot reliably judge whether a custom interaction makes sense to a real user.

Manual testing remains important, especially for complex components. Accessibility quality depends on meaning, behavior, and context.

When ARIA Is Necessary

ARIA becomes useful when native HTML cannot fully communicate the structure or behavior of an interface.

Common situations include:

• custom tabs;
• modal dialogs;
• accordions where expanded or collapsed state needs to be communicated;
• autocomplete widgets;
• custom dropdowns or comboboxes;
• dynamic status messages;
• live search results;
• complex application-style interfaces;
• custom controls that cannot be represented accurately with native HTML alone.

Even then, ARIA should be applied according to the intended pattern. The WAI-ARIA Authoring Practices Guide is a useful reference for common interactive patterns and expected keyboard behavior.

When ARIA Should Be Avoided

ARIA should usually be avoided when it duplicates, conflicts with, or weakens native HTML semantics.

Avoid ARIA when:

• a native HTML element already does the job correctly;
• the ARIA role does not match the actual behavior of the element;
• states and properties will not be kept synchronized;
• the team cannot test the interaction adequately;
• the attribute is being added only because it appears in a checklist;
• the interface can be simplified instead.

Simplicity is often one of the strongest accessibility tools. A simpler interface may require less ARIA, fewer custom behaviors, and less explanation for users.

Building Accessible Interfaces from the Start

Accessibility is easier and more reliable when it is considered during planning and design, rather than added after an interface is already built.

Strong accessibility foundations include:

• clear information architecture;
• logical heading structure;
• semantic HTML;
• descriptive link text;
• usable forms;
• keyboard-friendly interaction;
• adequate color contrast;
• responsive layouts that preserve usability;
• clear error handling;
• consistent navigation patterns.

ARIA fits into this larger structure. It is not separate from accessibility, but it is also not the whole of accessibility. It works best when the underlying page is already organized, meaningful, and usable.

ARIA Is Not Structured Data

ARIA and structured data are sometimes confused because both add machine-readable information to a page. They serve different audiences and purposes.

ARIA helps assistive technologies interpret interface meaning and behavior. Structured data helps search engines and other systems understand content entities, relationships, and page meaning in a retrieval context.

For example, ARIA may tell a screen reader that a component is an expanded accordion. Structured data may help describe an article, product, event, organization, or FAQ to search systems.

Both can support clarity, but they operate in different layers of the web.

Practical ARIA Principles

For most teams, ARIA becomes easier to use when guided by a few practical principles:

• Start with native HTML. Use the correct element before adding ARIA.
• Use ARIA only when it adds needed meaning. Do not add attributes by habit.
• Keep states synchronized. ARIA should match what users can see and do.
• Test with keyboard interaction. Semantics and operability both matter.
• Prefer visible clarity. If users need information, make it visible when possible.
• Follow established patterns. Complex widgets should not invent unexpected behavior without reason.
• Keep interfaces simple when possible. Simpler components are often easier to make accessible.

FAQ About ARIA

Closing Thoughts

ARIA is an important part of modern web accessibility, but it is not a shortcut around good structure. Its purpose is to communicate interface meaning when native HTML alone cannot fully express what is happening.

Accessible websites are built on clear HTML, meaningful semantics, thoughtful interaction design, and careful testing. ARIA extends those foundations. Used well, it helps people understand and operate complex web interfaces. Used carelessly, it can make the experience harder.

The steady path is simple: build with native HTML first, add ARIA where it genuinely improves communication, and test the experience with real interaction in mind.