Category: ARIA and Semantic Structure

First Rule of ARIA Use

Also known as: First Rule of ARIA, ARIA Rule 1, Don't use ARIA, use native HTML instead

Simply put

The First Rule of ARIA Use is a guideline for web developers that says you should use a built-in HTML element or attribute whenever one already provides the meaning and behavior you need, rather than recreating that functionality with ARIA. In practice, this means reaching for a standard button, link, or form control before adding ARIA roles and properties. It reflects the idea that native HTML is generally more reliable and better supported by assistive technologies.

Formal definition

The First Rule of ARIA Use, as stated in the W3C's "Using ARIA" specification, holds that if a native HTML element or attribute already exists with the semantics and behavior required, authors should use it rather than repurposing another element and adding an ARIA role, state, or property to make it accessible. It is the first of five rules of ARIA use commonly cited in the specification and in developer guidance, and it prioritizes native HTML semantics because such elements provide built-in roles, states, keyboard behavior, and assistive technology support that ARIA only describes but does not implement. ARIA modifies the accessibility tree exposed to assistive technologies but does not add behavior; applying ARIA to non-native constructs generally obligates the author to also supply the corresponding keyboard interaction and state management. This entry describes an authoring guideline and is not legal advice; conformance obligations are governed by applicable standards and, where relevant, jurisdiction-specific requirements.

Why it matters

ARIA modifies the accessibility tree exposed to assistive technologies, but it does not add behavior. When a developer applies an ARIA role to a non-native construct, such as turning a `<div>` into a button, the browser exposes the intended role to a screen reader, but it does not supply the keyboard interaction, focus management, or state handling that a native element provides for free. That gap must then be reproduced entirely in script. The First Rule of ARIA Use exists because native HTML elements ship with built-in roles, states, keyboard behavior, and broad assistive technology support, which ARIA only describes rather than implements.

Misapplied ARIA is a common source of accessibility defects. A custom control with an ARIA role but no accompanying keyboard support can appear correct to a sighted mouse user while being unusable for someone navigating by keyboard or screen reader. Following the first rule reduces this risk by shifting responsibility for correct behavior back to the browser, which handles it more consistently than hand-written code. As the W3C's "Using ARIA" specification frames it, if a native element or attribute already provides the semantics and behavior you need, you should use it instead of recreating that functionality.

This guideline is an authoring recommendation, not a legal requirement. It supports the broader goal of building accessible interfaces, but conformance obligations are governed by applicable standards and, where relevant, jurisdiction-specific requirements. Meeting this rule does not by itself guarantee an accessible experience or legal compliance, and it should be treated as one practice within a larger accessibility and testing effort rather than as legal advice.

Who it's relevant to

Front-end and web developers

Developers are the primary audience for this rule, since it directly shapes how components are built. Choosing native HTML elements where they already provide the needed semantics and behavior reduces the amount of custom keyboard and state-management code required and lowers the risk of introducing accessibility defects through misapplied ARIA.

UX and interface designers

Designers who specify custom controls influence whether developers can rely on native elements or must recreate behavior with ARIA. Understanding the first rule helps designers favor patterns that map cleanly onto standard HTML controls, which tend to be more reliably supported by assistive technologies.

Accessibility engineers and QA testers

Those auditing interfaces can use the first rule as a diagnostic lens: where ARIA has been applied to non-native constructs, they should verify that the required keyboard interaction and state management have also been implemented. Because ARIA only describes rather than implements behavior, these constructs warrant manual and assistive technology testing beyond automated checks.

Engineering leads and technical managers

Leads setting coding standards and reviewing pull requests can adopt the first rule as a review criterion to promote native HTML by default. This guidance is an authoring recommendation, not legal advice, and teams should consult qualified counsel and current standards for conformance obligations specific to their jurisdiction and context.

Inside First Rule of ARIA Use

First Rule of ARIA Use

A principle from the W3C's ARIA Authoring Practices guidance stating that if a native HTML element or attribute exists with the semantics and behavior you need, you should use it rather than repurposing a generic element and adding an ARIA role or state.

Native semantics preference

The rule directs authors to rely on built-in HTML semantics (for example, using a button, link, or checkbox element) because native elements come with keyboard behavior, focus management, and accessibility support that browsers and assistive technologies generally provide without additional scripting.

ARIA as a supplement, not a replacement

ARIA (Accessible Rich Internet Applications) is intended to fill gaps where native HTML lacks the needed semantics, such as certain custom widgets. It does not alter element behavior on its own and does not add keyboard interaction; those must be implemented separately.

Relationship to WCAG

Proper application of the rule supports meeting WCAG success criteria related to name, role, and value, but following the rule alone does not by itself constitute WCAG conformance or guarantee an accessible experience.

Common questions

Answers to the questions practitioners most commonly ask about First Rule of ARIA Use.

Does using ARIA make my page more accessible than using plain HTML?

Not necessarily. The First Rule of ARIA Use, published by the W3C as part of the ARIA Authoring Practices guidance, states that if a native HTML element or attribute already provides the semantics and behavior you need, you should use it rather than repurposing a generic element with ARIA. Native elements come with built-in accessibility semantics, keyboard behavior, and browser support, whereas ARIA only conveys semantic information to assistive technology and does not add behavior on its own. Adding ARIA where native HTML would suffice can introduce redundancy or errors and generally does not improve the experience.

If I add an ARIA role like role="button" to a div, does that make it function as a button?

No. ARIA changes only the semantics exposed to assistive technology; it does not add functionality. A div with role="button" is announced as a button, but it will not be keyboard focusable, will not respond to Enter or Space, and will not carry the other behaviors a native button element provides unless you implement all of that yourself with additional scripting and attributes. The First Rule of ARIA Use encourages choosing the native button element in this situation, because it supplies that behavior automatically and is generally more reliable across browsers and assistive technologies.

How do I decide whether to use a native HTML element or ARIA?

Start by checking whether a native HTML element or attribute already provides the role, state, or property you need. If it does, use it. Reach for ARIA when no native element offers the required semantics, when you cannot use the native element for a legitimate technical reason, or when you are building a custom widget for which HTML has no direct equivalent. Because requirements and browser support evolve, it is worth re-evaluating older ARIA-heavy patterns to see whether a native element now covers the need.

What are common situations where native HTML is preferable to ARIA?

Frequently cited examples include using the button element instead of a div with role="button", using anchor elements for links rather than scripted click handlers on generic elements, using native form controls and labels instead of recreating them, and using headings and landmark elements such as nav or main rather than applying corresponding ARIA roles to generic containers. In these cases the native element provides semantics and expected keyboard behavior without additional code.

When is it appropriate to use ARIA instead of native HTML?

ARIA is generally appropriate when you are creating a component or interaction that native HTML does not represent, such as certain composite widgets, or when you need to convey dynamic states and relationships that native markup cannot express on its own. It is also used to communicate updates to assistive technology, for example through live regions. Even in these cases, ARIA should be paired with the keyboard interaction and focus management the pattern requires, since ARIA alone does not supply behavior.

Does following the First Rule of ARIA Use guarantee accessibility or legal compliance?

No. Following this rule helps you avoid a common category of ARIA misuse and encourages robust, well-supported markup, but it is one authoring principle among many. Accessible outcomes also depend on correct implementation, keyboard operability, meaningful content, and testing with assistive technologies, since automated checks detect only a portion of issues. It does not on its own ensure conformance with WCAG or immunity from legal claims. For questions about legal obligations, consult qualified legal counsel and current agency guidance.

Common misconceptions

Adding ARIA roles and attributes makes a page more accessible.

Adding ARIA does not inherently improve accessibility and can degrade it when it overrides or conflicts with native semantics. The First Rule of ARIA Use advises against adding ARIA when a suitable native HTML element already provides the needed semantics and behavior.

ARIA provides keyboard functionality and interactive behavior.

ARIA generally conveys semantics (role, state, and properties) to assistive technologies but does not add keyboard support or interactive behavior. Those must be implemented by the author, whereas many native HTML elements provide them automatically.

Using native HTML with correct semantics guarantees compliance and an accessible experience.

Preferring native elements reduces common errors, but it does not by itself guarantee WCAG conformance, an accessible experience for all users, or legal compliance. Manual and assistive technology testing remain necessary, and automated checks catch only a portion of issues.

Best practices

Before reaching for an ARIA role, check whether a native HTML element (such as button, a, input, or select) already provides the required semantics and behavior, and use it when it does.

Reserve ARIA for cases where no native element offers the needed semantics, such as certain custom widgets not expressible in plain HTML.

When a native element is not feasible and ARIA is used, implement the associated keyboard interaction and focus management yourself, since ARIA does not supply behavior.

Avoid overriding the native role of an element with a conflicting ARIA role, as this can confuse assistive technologies.

Validate implementations with manual testing and assistive technology testing in addition to automated checks, since automated tools detect only a portion of issues.

Consult current W3C ARIA Authoring Practices guidance as it evolves, and treat this rule as a design principle rather than a substitute for legal advice or a guarantee of compliance.