WebAIM’s February 2026 scan of the top 1,000,000 home pages found 82.7% of them using ARIA beyond landmark roles, up from 79.4% in 2025.
ARIA stands for Accessible Rich Internet Applications. It’s a W3C technical specification that adds roles, states, and properties to HTML elements, so assistive technology can describe custom interface components that native HTML has no element for. The specification changes what a screen reader announces and never how the element behaves.
Developers reach for it on tabs, menus, comboboxes, and live status messages. WCAG 2.2 Success Criterion 4.1.2 requires custom controls like the first three to expose a name, role, and value, and Success Criterion 4.1.3 covers status messages.
W3C’s Authoring Practices Guide treats every role as a promise that the author has scripted the matching keyboard behavior.
What Is ARIA?
HTML has no tree view element, and SVG has no button element. Anyone who builds either one from CSS and script leaves assistive technology guessing, and ARIA exists to fill that gap, as the WAI-ARIA 1.2 specification itself explains.
What it changes is what the browser tells a screen reader about an element. What the element does and how it looks stay exactly as they were.
Inside web accessibility work, ARIA is the layer for custom widgets. Plain headings, links, and buttons don’t need it.
Who Maintains ARIA and Which Version Is Current
The W3C Accessible Rich Internet Applications Working Group publishes the specification. The W3C Web Accessibility Initiative hosts the overview and the Authoring Practices Guide.
- WAI-ARIA 1.1 became a W3C Recommendation on 14 December 2017.
- WAI-ARIA 1.2 followed on 6 June 2023 and is the current Recommendation.
- WAI-ARIA 1.3 had its First Public Working Draft on 23 January 2024, and the latest Working Draft is dated 4 June 2026.
The Working Group charter lists Q3 2026 as the expected completion for ARIA as a Living Recommendation. As of 11 October 2026, W3C’s publication history for version 1.3 still ends at the 4 June 2026 Working Draft.
How ARIA Relates to WCAG
WCAG 2.2 never asks for ARIA by name, only for the outcome.
Success Criterion 4.1.2, Name, Role, Value, sits at Level A. It requires that software can determine the name and role of every interface component, and that state changes reach assistive technology (W3C, Understanding WCAG 2.2).
Controls written in plain HTML meet it when used as specified. Custom controls built from divs and script need extra markup, and ARIA supplies the missing role, name, and state.
ARIA Roles, States, and Properties
A role says what an element is. States report what condition it’s in right now, and properties cover traits and the relationships between elements.
| Part | Tells assistive technology | Examples | Changes while the page runs |
|---|---|---|---|
| Role | What the element is | button, tab, alert, navigation | No |
| State | Its current condition | aria-expanded, aria-checked, aria-pressed | Yes, with user action |
| Property | A trait or a relationship | aria-label, aria-controls, aria-haspopup | Usually not |
The line between states and properties isn’t strict. Some properties, aria-valuenow on a slider for one, update constantly, and the specification says frequency of change is a hint, not a rule.
Role Categories
WAI-ARIA 1.2 groups the roles authors can use by what they do.
- Widget roles cover interactive controls such as button, checkbox, slider, and tab.
- Document structure roles describe static content like table, figure, and list.
- Landmark roles mark page regions, including banner, main, navigation, and search.
- Live region roles are for content that updates by itself, such as alert, status, log, and timer.
- Dialog and alertdialog make up the window roles.
Abstract roles sit in a separate group that only organizes the specification, and authors must not use them.
Landmarks are already common in practice. At least one region was defined on 80.5% of home pages (WebAIM Million 2025).
Naming, Description, and Visibility Attributes
WebAIM Million 2025 counted an average of 25 aria-label, aria-labelledby, and aria-describedby attributes per home page.
The first two set the accessible name. aria-describedby only adds a description that goes along with it.
- aria-label holds a text string, which suits controls with no visible label.
- aria-labelledby points to the id of another element, and that element’s text becomes the name.
- aria-describedby points to extra explanatory text.
- aria-hidden=”true” removes an element from the accessibility tree entirely.
Interaction gets a mix of states and properties. aria-expanded reports true or false on a disclosure button, and aria-controls points to the panel it opens. aria-haspopup says a menu, listbox, tree, grid, or dialog will appear.
aria-live marks a region whose changes get announced, with values of polite, assertive, or off. The alert role is a ready-made assertive live region.
How Does ARIA Reach Screen Readers?
The browser reads ARIA from the DOM, applies it to nodes in its accessibility tree, and passes that tree to the operating system through a platform accessibility API. Most assistive technology, screen readers included, works from that API instead of the markup (W3C, WAI-ARIA 1.2).
On Windows that means JAWS and NVDA. VoiceOver covers macOS and iOS, and TalkBack covers Android.
A role that overrides a native element leaves the DOM untouched. Only the accessibility tree changes.
How Each Platform API Receives ARIA
Core Accessibility API Mappings 1.2 maps ARIA onto MSAA with IAccessible2, UI Automation, ATK with AT-SPI, the macOS accessibility protocol, and the Android accessibility API. Where an API has no slot for an ARIA role, the browser passes the role string another way.
| API | Platform | How the ARIA role string is exposed |
|---|---|---|
| IAccessible2 | Windows | Object attribute xml-roles |
| UI Automation | Windows | AriaRole and AriaProperties properties |
| ATK and AT-SPI | Linux (GNOME) | Object attribute xml-roles |
| MSAA alone | Windows | Not supported |
MSAA alone can’t carry a custom role, so the role travels through IAccessible2 or UI Automation instead. Core-AAM 1.2 is a Candidate Recommendation Draft dated 23 September 2026.
How the Browser Calculates an Accessible Name
When a screen reader lands on a control, it speaks the accessible name, and the browser picks that name from the first source that applies, in this order:
- aria-labelledby
- aria-label
- A native label, such as an alt attribute or a label element
- Text content, for roles that take their name from content
- The title attribute, as a last resort
Text hidden with CSS still counts when aria-labelledby points at it. That’s how a delete button can reference both itself and the file link beside it, and read out as “Delete” plus the file name.
The order comes from Accessible Name and Description Computation 1.2, a Working Draft dated 2 October 2026. The latest Recommendation is version 1.1, from 18 December 2018.
Browser developer tools show the computed role for any element, so you can compare what the browser calculated with what you intended.
When to Use ARIA and When to Skip It
Use ARIA only when no native HTML element carries the semantics and behavior you need. A native button already exposes the right role, name, and keyboard behavior, and a div with role=”button” adds work for the same result. That’s the whole argument for native HTML, really.
ARIA in HTML, a W3C Recommendation dated 11 August 2026, defines which roles and aria-* attributes are valid on which HTML elements. Check it before putting a role on anything native.
When Native HTML Falls Short
W3C names a few cases where the native element isn’t an option. The HTML feature might exist while browsers or assistive technology don’t support it properly. The visual design might rule the native element out because it can’t be styled as required. Or HTML just has no element for the feature yet.
Outside those cases, the native element is the cheaper and more reliable choice.
The Rules of ARIA Use
W3C’s Using ARIA sets out numbered rules. The document became a Discontinued Draft on 24 February 2026, with the rules kept for reference and the Authoring Practices Guide named as the place for further guidance. Its reference list still cites the 5 August 2025 version of ARIA in HTML.
- Use a native HTML element with the semantics and behavior you need built in, instead of repurposing an element and adding ARIA.
- Do not change native semantics unless you have to. To build a heading that acts as a tab, wrap the heading in an element with role=”tab” instead of putting the role on the heading.
- Every interactive ARIA control must work with the keyboard.
- Never put role=”presentation” or aria-hidden=”true” on a focusable element, because keyboard users land on nothing.
The fourth rule also covers a focusable element inside an aria-hidden parent.
Rule 3 puts the work on JavaScript key handlers. An element with role=”button” has to take focus and respond to both Enter (Return on macOS) and Space, and ARIA adds none of that.
Where to Find Correct Widget Patterns
The ARIA Authoring Practices Guide (APG) publishes widget patterns, with the roles, states, and keyboard interactions each one needs.
WAI-ARIA 1.2 puts focus management on the author for 8 container roles: grid, listbox, menu, menubar, radiogroup, tree, treegrid, and tablist.
Tabs, menus, and comboboxes built from scratch mean accessible interface components with names, states, and focus all written by hand. Copying an APG pattern beats inventing one.
What ARIA Does Not Do
ARIA won’t make an element focusable or operable. It won’t style anything either, and it can’t repair markup that the HTML parser rewrites.
Focus and Disabled State
Adding aria-disabled=”true” to a link changes how the link is announced. It does not stop the click, as ARIA in HTML points out.
The working pattern removes the href, which turns the anchor into a placeholder. Then role=”link” and aria-disabled=”true” go on that placeholder.
Focus works the same way. ARIA can’t put an element in the tab order, so tabindex=”0″ is what does it, and a negative tabindex makes an element focusable by script or click only (WAI-ARIA 1.2).
Styling and Visual State
ARIA ships no styles, but CSS attribute selectors can read it. The specification’s own example targets [aria-checked=”true”], so one attribute drives both the visual state and the announced state.
aria-activedescendant breaks that shortcut. It points to the item treated as focused inside a composite widget such as a listbox, DOM focus stays on the container, and :focus never matches the current item. The author has to style the active item by hand.
Support Gaps and Parser Limits
Support is uneven. The APG says its examples do not work around gaps in ARIA 1.2 support, and that some ARIA features are not supported in any mobile browser.
Markup doesn’t get repaired for you, either. A div with role=”link” inside a p still gets pulled out of the paragraph by the HTML parser, so use a span.
The APG advises testing every browser and assistive technology combination in your audience before shipping a pattern.
Why Pages With ARIA Have More Errors
Pages that use ARIA average more detected errors than pages without it, though WebAIM cautions that this does not necessarily mean ARIA introduced them.
WebAIM’s February 2026 scan of the top 1,000,000 home pages put ARIA volume at over 133 attributes per home page, up 27% in one year. Pages with ARIA averaged 59.1 detected errors against 42 without, a difference of 17 (it was 30 in the 2025 edition). On the menu side, 22% of ARIA menus introduced barriers, down from 35% in 2025.
The 2026 edition also moves two figures quoted earlier from the 2025 edition. Naming attributes now average 31.4 per home page, and 84.3% of home pages define at least one landmark region.
Two Readings of the Same Numbers
WebAIM’s own take is that pages with more ARIA were also more complex, so ARIA may mark complexity instead of causing errors. Its conclusion points to third-party frameworks and AI-assisted coding as likely drivers.
The APG takes a narrower view. Incorrect ARIA misrepresents the visual interface to people who rely on assistive technology, with potentially severe effects on their experience.
These don’t conflict. WebAIM counts every detected error on a whole page, while the APG describes what one wrong role or label does to a single component.
The editions add one more point. Pages without ARIA climbed from 27 to 42 errors, while pages with ARIA moved only from 57 to 59.1, so the gap closed because the baseline got worse.
The two groups also changed size between editions, so treat that comparison as directional.
The Mistakes Behind the Errors
- role=”select” is an abstract role authors must not use, and combobox is usually what was meant.
- Redundant roles like role=”button” on a button or role=”main” on main add nothing. A role=”list” on a ul whose markers were removed can be justified, because some browsers drop list semantics in that case.
- A menu should contain at least one menuitem, menuitemcheckbox, or menuitemradio, and required states need non-empty values.
- A checkbox with checked and aria-checked=”false” exposes the native state, and the ARIA value is ignored.
- aria-label on a link replaces the visible link text for assistive technology users.
- role=”heading” on a button isn’t allowed, because the button’s default behavior conflicts with the heading role.
Why ARIA Menus Fail
ARIA menus fail on structure and keys, not on the role itself.
WebAIM attributes the failures to missing menu markup and missing interactions. The specification requires menu items inside the menu and leaves focus management to the author.
How to Test ARIA Markup
Start with an automated checker for invalid roles and missing names. Then look at the browser’s accessibility tree for computed roles and names, and finish with a keyboard and screen reader run on every custom widget. Automation covers the first pass well and the last one not at all.
| Tool | Detects | Cannot confirm |
|---|---|---|
| axe-core (Deque) | Invalid roles, attributes, and names | Issues beyond its rules; uncertain items return as incomplete |
| WAVE (WebAIM) | Errors, alerts, and features on the rendered page, hidden elements included | Whether the page is accessible |
| Lighthouse (Chrome DevTools) | Accessibility audit built on the axe engine | Keyboard use and screen reader output |
| DevTools Accessibility tab | Accessibility tree, ARIA attributes, computed name and role | Whether the result matches your intent |
What Automated Checks Cannot Confirm
According to Deque, axe-core finds 57% of WCAG issues automatically on average, and it returns anything it can’t judge as incomplete.
The W3C ACT rules for Success Criterion 4.1.2 show what checkers verify. Role values must be valid, ARIA states and properties must be defined with valid values, roles must carry their required states, and an element with aria-hidden must hold nothing focusable.
WAVE’s own help page says the absence of errors does not mean a page is accessible or compliant. WAI-ARIA 1.2 makes the same point about interactive content: static checks alone can’t confirm it.
A broader web accessibility checklist covers the WCAG items that no ARIA check touches.
A Test Order That Works
- Run axe-core or Lighthouse, then remove invalid and redundant ARIA before adding anything.
- Add the missing accessible names and rerun the checker.
- Open the Accessibility tab in Chrome DevTools and compare each widget’s computed role and name with what you intended.
- Tab through the page, then operate each widget with the keys its APG pattern specifies.
- Repeat with a screen reader and listen for role, name, and state changes.
Which Screen Reader and Browser Pairs to Test
WebAIM’s Screen Reader User Survey #10 (December 2023 to January 2024) found that most respondents use more than one desktop screen reader. JAWS with Chrome and NVDA with Chrome were the two most common pairings.
- NVDA with Chrome or Firefox
- JAWS with Chrome or Edge
- VoiceOver with Safari, on macOS and iOS
- TalkBack on Android
The same survey ranked interactive elements such as menus, tabs, and dialogs that do not behave as expected as the second most problematic item, behind only CAPTCHA.
ARIA FAQ
Does ARIA help SEO?
No. Google said in its August 2023 SEO office hours that accessibility features carry no inherent SEO advantage.
The advice was to use ARIA labels for accessibility reasons, not to influence rankings.
Is ARIA legally required?
No law requires ARIA by name. The laws W3C lists point to WCAG instead, such as the European Accessibility Act (listed as based on WCAG 2.2) and the 2024 US rule for state and local government web content (based on WCAG 2.1). For the EAA, the technical reference is EN 301 549, whose version 4.1.1, published on 2 September 2026, moves it from WCAG 2.1 to WCAG 2.2.
ARIA is one way to meet Success Criterion 4.1.2 on custom controls.
What is new in WAI-ARIA 1.3?
The 1.3 drafts add aria-description, braille attributes such as aria-braillelabel and aria-brailleroledescription, and an ariaNotify API presented as an alternative to live regions.
It’s still a Working Draft dated 4 June 2026, so details can change.
Can ARIA be used on SVG?
Yes. WAI-ARIA 1.2 was written to complement both HTML and SVG2.
The specification’s own example is an interactive button built in SVG, which has no button element, so it needs role=”button” to expose its role. ARIA in HTML covers HTML elements only.
Fixing Existing ARIA Without Breaking Working Components
Fix existing ARIA by removing wrong markup before adding anything. Deleting an invalid or redundant attribute changes what a screen reader announces without changing how the component behaves in the browser.
The sequence with the least regression risk goes like this. Remove invalid, abstract, and redundant roles first. Then restore missing accessible names and required states, and swap custom widgets for native elements last.
Native replacement comes at the end because it changes keyboard handling, so every swap needs a fresh keyboard and screen reader pass.
It costs time, and there’s no way around that. Working but weak ARIA stays in place until its turn, and a native element sometimes costs a custom visual treatment.
This order reflects the specifications as of 11 October 2026. Once WAI-ARIA 1.3 reaches Recommendation, ariaNotify and the braille attributes widen what a rewrite can use, and the sequence should be reviewed then.
Many of his resources are available on various design marketplaces. Over the years, he's worked with a range of clients and contributed to design publications like Designmodo, WebDesignerDepot, and Speckyboy, Slider Revolution among others.
- What is Backend in Web Development? - September 13, 2026
- What is Frontend Development? - September 11, 2026
- How to Make a Button in Figma: Design Best Practices - September 10, 2026
