ARIA: Accessible Rich Internet Applications Working Group
The roles, states and properties that tell assistive technology what a custom control is and what it is doing.
1.2Current WAI-ARIA Recommendation (June 2023)
1.3Working Draft (June 2026)
4Companion specs also in draft (all updated Sep to Oct 2026)
Reviewed 8 October 2026. Publication dates are checked against the W3C
documents themselves every week.
Every fact links to a source at the bottom of the page.
In plain English
WAI-ARIA is a W3C standard, not a guideline. It defines attributes such as role, aria-expanded and aria-describedby that let a page describe custom widgets to assistive technology. The ARIA Working Group also writes the mapping specs (Core-AAM, HTML-AAM, Accname) that tell browsers how to pass HTML and ARIA through to each operating system's accessibility API.
WCAG does not require ARIA, but much of WCAG 2.2 success criterion 4.1.2 Name, Role, Value is met in practice through it, and the ARIA techniques in Understanding WCAG are sufficient techniques for several criteria. When ARIA changes what a role means or how a name is calculated, the way those criteria are tested changes with it.
What is published today
Published documents for ARIA, with status and date
First public draft January 2024. The editor's draft was updated 2 October 2026. At the ACT Task Force on 25 June 2026 this was described as the last review before Candidate Recommendation.
New roles: mark, suggestion and comment (for highlighted, inserted, deleted and annotated content), and sectionheader and sectionfooter (a header or footer for one section rather than the whole site).
role=image added as a synonym for role=img.
New properties: aria-description (a description as a string, not an ID reference), aria-braillelabel and aria-brailleroledescription (braille-only labels).
aria-details can point to more than one element, and aria-errormessage becomes an ID reference list.
ariaNotify, a script API for asking assistive technology to announce something without a live region.
aria-hidden=true is no longer allowed on the document root, and aria-hidden=false now means the same as leaving it off.
An accessible name is no longer required on alertdialog, dialog, form, grid and radiogroup. A combobox may now open a menu, and aria-expanded is removed from listbox.
Joint work with the SVG Working Group. The draft warns that it is early, contains outdated information, and should not be implemented from.
How it connects to WCAG
WCAG 2.2
No change to WCAG 2.2 itself. ARIA 1.3 changes what correct markup looks like, so it changes how 4.1.2 Name, Role, Value and 1.3.1 Info and Relationships are tested: for example, a dialog without a name stops being an ARIA authoring error, though WCAG may still expect one.
WCAG 3 draft
The WCAG 3 draft has provisions written around the same ideas, and in early October 2026 a set of upstream PRs (#883 to #897) was moving several of them onto the defined term programmatically determinable. These are the provisions to read alongside ARIA:
Each item says how firm it is: something that has happened, a plan the group has stated,
a proposal not yet agreed, or this site's own reading of where things are heading.
Q3 2026
The current charter targeted ARIA 1.3 completion in Q3 2026. As of October 2026 it is still a Working Draft, so that date has slipped.
Happened
Late 2026
WAI lists an updated ARIA 1.3 draft for September to November 2026, ahead of Candidate Recommendation.
Planned by the group
1 Jan 2027
The current charter ends. A draft charter runs 1 January 2027 to 31 December 2028.
Proposed, not yet agreed
2027 to 2028
The draft charter makes ARIA a Living Recommendation: new features chosen in March 2027, a call for review of amendments in March 2028, and an amended Recommendation in December 2028. It names no ARIA 1.4 or 2.0. The ACT Task Force heard in June 2026 that ARIA will become evergreen, with numbering possibly revisited later.
Proposed, not yet agreed
2027 to 2028
New deliverables in the draft charter: AT-Driver (a standard way for test tools to drive screen readers), CSS Accessibility API Mappings, and PDF Accessibility API Mappings. MathML-AAM is listed as tentative.
Proposed, not yet agreed
After 1.3
Expect version numbers to matter less. Teams will need to track which features browsers and screen readers support rather than which ARIA version they target.
This site's reading
What this means for your team
✅
Start now
Useful whatever happens next
Keep building and testing against ARIA 1.2 and ARIA in HTML.
Both are Recommendations, and they are what browsers, linters and audit tools implement today.
Use native HTML first.
ARIA in HTML lists where a role is redundant or not allowed. Fewer ARIA attributes means less to retest as 1.3 lands.
🔜
Cheap hedges
Low cost, likely to pay off
Try aria-description and the new roles only where support is confirmed.
They are in a draft. Check current browser and screen reader support before relying on them for a WCAG pass.
Review any aria-hidden on html or body.
1.3 disallows aria-hidden=true on the document root. It was always a bad idea, and soon it will be an authoring error too.
⏸️
Wait
Too early to build for
Do not swap live regions for ariaNotify yet.
It is a new script API in a draft spec. Live regions keep working, so build a fallback first.
Hold off on braille-only labels.
At the ACT Task Force in June 2026, only one screen reader was reported to support the braille attributes.
What this site watches
ARIA 1.3 moving to Candidate Recommendation
The 2027 to 2028 charter being approved, and which features are picked in March 2027
Accname 1.2 changes that alter how accessible names are calculated