ARIA is a tagging system that tells a user where they are on a page and how they can interact with it.
ARIA has a reputation as the mark of an accessible website, and teams often sprinkle it through their templates as a kind of insurance. The evidence points the other way. A website built on semantic HTML gets its accessibility from the elements themselves, and most ARIA found in the wild is either redundant or wrong. This article explains what ARIA is actually for, why native HTML should always come first, and the small set of situations where ARIA still earns its place.
Ask us to review your ARIA usage if you are unsure.
One of the most common misconceptions is that more ARIA means more accessibility.
In reality, ARIA is a repair and extension mechanism, designed for the cases where HTML alone cannot describe an interface. When the interface is built from the right HTML in the first place, there is very little left for ARIA to repair.
The first rule of ARIA
You do not
use ARIA. *
<button> <nav> <header> <main>
Accessibility built in. No promises to keep.
What is ARIA actually for?
ARIA, formally WAI-ARIA, is a set of attributes that tell assistive technologies what a piece of an interface is and what state it is in. A screen reader cannot infer that a styled div is behaving as a tab, a menu or a dialog, so ARIA provides roles, states and properties to say so explicitly. It was created for the era when HTML had no native way to express those widgets, and it remains essential for truly custom components.
What ARIA does not do is add behaviour. Giving a div the attribute role="button" announces a button to a screen reader, but the browser adds no keyboard focus, no Enter or Space activation, and no styling. The W3C describes a role as a promise: the author is promising to supply, in script, everything the real element would have provided free. Every ARIA attribute is a claim about the interface, and unkept claims are experienced by users as broken pages.
Why does semantic HTML come first?
Native HTML elements arrive with their accessibility built in. A button is focusable, keyboard operable and announced correctly in every browser and screen reader combination, with no extra attributes and nothing to maintain. The W3C's own guidance, the first rule of ARIA use, says this plainly: if a native HTML element or attribute with the required semantics and behaviour exists, use it rather than repurposing an element and adding ARIA.
In practice, a large share of the ARIA on production websites is a hand-built copy of something HTML already provides. The pattern is easy to recognise once you look for it.
Common ARIA additions and the HTML that already does the job
| The ARIA construction |
The native equivalent |
| A div with role="button", tabindex and click scripting |
A button element |
| role="navigation", role="main", role="banner" on divs |
The nav, main and header elements |
| aria-required="true" on a form field |
The required attribute |
| role="heading" with aria-level="2" |
An h2 element |
| role="list" and role="listitem" on divs |
The ul and li elements |
| An aria-label repeating a link's visible text |
The visible link text, which is already the accessible name |
The left column is not merely wasted effort. Each entry is code that must be scripted, tested and maintained by hand to reach the standard the right column meets by default. The best practice is well established, the constraint is that page builders and old templates generate the left column freely, and the pragmatic solution is to make semantic HTML the default in your components and treat every ARIA attribute as an exception requiring a reason.
What does the evidence from real websites show?
The WebAIM Million, an annual automated evaluation of the top one million home pages, measures ARIA use each year, and the 2026 results are sobering. ARIA appeared on 82.7% of home pages, with an average of 133 ARIA attributes per page. Yet the pages using ARIA averaged 59.1 detected errors, against 42 errors on the pages without it. The report draws the relationship out plainly.
Increased ARIA usage on pages was associated with higher detected errors. The more ARIA attributes that were present, the more detected accessibility errors could be expected.
The data on ARIA
More ARIA,
more errors.
"The more ARIA attributes that were present, the more detected accessibility errors could be expected."
The WebAIM Million, 2026
82.7%
of home pages use ARIA
59.1
average errors with ARIA
42
average errors without
The report is careful about causation, noting that pages with heavy ARIA are often more complex pages to begin with. Even allowing for that, the finding is consistent year after year: the presence of ARIA predicts more accessibility failures, not fewer. The W3C's authoring guidance draws the practical conclusion in its own heading, "No ARIA is better than bad ARIA", because incorrect ARIA actively misdescribes the page to the people relying on it. An unlabelled control is a nuisance; a mislabelled one is a trap.
When is ARIA still the right tool?
ARIA remains the right tool for the interface patterns HTML still cannot express on its own. A tabbed panel, an autocomplete combobox, a tree view or a custom menu has no native element, so roles and states are how assistive technologies learn what they are. Status messages that appear without a page reload, such as "3 results found" or "item added to cart", need a live region so screen readers announce them. A disclosure control needs aria-expanded so its open or closed state is conveyed, and aria-describedby is the reliable way to associate an error message with the field it concerns.
The common thread is that each of these adds information HTML has no other way to provide. That is the test worth applying before any ARIA attribute goes in: what does this tell assistive technology that the markup does not already say? If the answer is nothing, the attribute is at best noise and at worst a defect. If the answer is something real, use the attribute, follow the relevant W3C authoring pattern, and test the result with a keyboard and a screen reader, because ARIA is only ever as correct as the behaviour behind it.
What goes wrong when ARIA is added just in case?
Precautionary ARIA fails in predictable ways, and several of them are failures against WCAG itself. An aria-label that differs from a control's visible text breaks voice control users, who say "click Submit" and find that no control by that name exists. An aria-hidden="true" left on focusable content creates keyboard stops where nothing is announced at all, which the W3C's rules of ARIA use prohibit outright. Redundant roles on semantic elements cause double or contradictory announcements, and a promised role without its keyboard behaviour produces a control that screen readers describe but keyboards cannot operate.
These faults share an uncomfortable property: the page looks completely normal. Nothing in a visual check reveals them, most survive an automated scan, and they surface only when someone uses the site the way ARIA's audience does. That is why remediation work on ARIA-heavy sites so often consists of removing attributes rather than adding them.
So are ARIA tags necessary on a well-developed site?
Mostly, no, and the amount of ARIA in a codebase is a reasonable inverse indicator of how well the HTML beneath it was chosen. A well-developed site expresses its structure through headings, landmarks, lists, tables and form elements, and reserves ARIA for the handful of custom widgets and live announcements that need it. The result is a small quantity of ARIA doing precise work, rather than a large quantity doing decoration.
A practical rule of thumb is to treat ARIA the way a careful writer treats footnotes: necessary occasionally, valuable when accurate, and a warning sign when they outnumber the text. When we audit a website as part of our accessibility service, ARIA use is one of the first things we read, because it reveals how the site was built. The repair work that follows is as likely to involve deleting attributes as writing them, and the sites that test best are usually the ones that needed the least. The same principle runs through the faults we see most often, covered in the most common website accessibility faults and how long they take to fix.
Frequently asked questions
No. WCAG requires that every interface component exposes its name, role and value to assistive technologies, but it does not care how that is achieved. Native HTML elements meet the requirement by themselves in most cases. ARIA becomes relevant only where you build custom components that HTML cannot describe, which is exactly the situation it was designed for.
Yes, and the phrase is the W3C's own. ARIA overrides what assistive technologies would otherwise report, so an incorrect role or label replaces workable information with wrong information. A user can often puzzle out an unlabelled control from context. A control that announces itself as something it is not gives them nothing true to work with.
Because your platform probably wrote it for you. Page builders, sliders, chat widgets, cookie banners and JavaScript component libraries all inject ARIA, and the quality varies widely. This is worth checking during procurement as well as testing: asking a vendor how their components handle keyboard and screen reader use is cheaper than remediating their markup later.
No. ARIA attributes are written for assistive technologies, and search ranking does not reward their presence. Stuffing keywords into aria-label attributes is actively harmful, because those labels are read aloud verbatim to screen reader users. The overlap between accessibility and SEO is real, but it lives in semantic structure, headings and meaningful link text rather than in ARIA.
Not by itself. ARIA changes what assistive technologies announce, and nothing else. Focus management, keyboard operation and visible state all have to be built separately in script, which native elements would have supplied automatically. A custom widget is accessible when its ARIA and its behaviour agree, and testing with a keyboard and a screen reader is how you find out whether they do.
Audit before you delete. Some of it will be redundant and safe to remove, some will be wrong and worth removing carefully, and some will be load-bearing for a custom component that stops working without it. The sensible sequence is to test the affected journeys, map each attribute to the behaviour it claims, and remove or repair with retesting at each step.
Work with us to audit how your website uses ARIA, or start with what changed in WCAG 2.2 to see the standard the testing measures against.