Cool new stuff coming in ARIA 1.3 - AFixt AFixt, Inc. offers a full array of auditing, consulting, and remediation services for regulations and standards such as ADA, WCAG, EAA, AODA, and EN 301 549

Skip to Content

-->

Blog > Cool new stuff coming in ARIA 1.3

Cool new stuff coming in ARIA 1.3

Karl Groves. - 20/05/2026

WAI-ARIA 1.3 is shaping up to be useful for rich document editors, annotation systems, complex forms, and interfaces where visible content does not always map cleanly to what assistive technologies need.

Please note: ARIA 1.3 is still a draft. The current W3C ARIA Working Group charter lists WAI-ARIA as a Living Recommendation, with ARIA 1.3 tied to a First Public Working Draft and an expected completion of Q3 2026 . That is a target, not a promise. Standards timelines move, features can change, and implementation can lag the specification. Developers should not assume any specific browser or assistive technology support yet. Test before relying on anything new in production.

That said, the direction is interesting. ARIA 1.3 appears to focus less on inventing entirely new widget patterns and more on filling gaps around descriptions, document semantics, annotations, editorial workflows, and braille-specific output. The WAI overview calls out new roles including suggestion, comment, and mark; new attributes including aria-description, aria-braillelabel, and aria-brailleroledescription; and an update to aria-details allowing multiple ID references.

First: the usual ARIA warning still applies

ARIA is not a replacement for HTML. No ARIA is better than bad ARIA and the ARIA spec continues to frame ARIA as a supplement to native host-language semantics. When HTML already provides the semantic feature you need, use HTML first. ARIA is for cases where native markup does not communicate enough meaning to accessibility APIs.

That matters here because some of the new ARIA 1.3 features overlap with existing HTML elements such as , , , , , , , , and . In ordinary HTML content, the native element should usually be the starting point. The ARIA role becomes more interesting when you are working in a custom editor, a virtualized document surface, generated markup, canvas-like environments, or other situations where native document semantics are hard to preserve.

New feature: role="suggestion"

The proposed suggestion role is intended for proposed edits. Think of the kind of content you see in Google Docs, Word, or a CMS editorial review workflow where someone suggests replacing a phrase, deleting a sentence, or inserting new text.

Example

The event starts at

9:00 AM<br>10:00 AM

Suggested by Jane because the keynote was moved later.

How, when, and why you would use it

Use role="suggestion" when the user needs to understand that some content is not simply part of the final document, but is a proposed change to it. The suggestion may contain an insertion, a deletion, or both. This is most relevant in rich text editors, collaborative document tools, code review interfaces, CMS editorial workflows, legal redlining tools, and content approval systems.

Without a semantic role for suggestions, assistive technology users may hear the inserted or deleted text but not understand that it represents a proposed change. The visual UI may make this obvious through color, strikethrough, balloons, or side comments. The accessibility tree needs a way to communicate the same editorial meaning.

New feature: role="comment"

The proposed comment role identifies content as a comment or annotation.

Example

We test our website annually against WCAG 2.2 AA.

Comment

Reviewer comment from Alex: This should say whether testing is performed<br>internally, by a third party, or both. We should also link to the latest<br>conformance report if one is available.

How, when, and why you would use it

Use role="comment" for content that comments on, annotates, questions, or explains another piece of content.

Good candidates include editorial notes, reviewer comments, document annotations, comments attached to spreadsheet cells, design review notes, legal review notes, and side comments in collaborative writing tools.

A comment is not just generic text. It has a relationship to some other piece of content. The user may need to navigate between the original content and the comment, distinguish comments from body content, and understand whether the comment is part of the final content or part of a review layer.

New feature: role="mark"

The proposed mark role is for highlighted or marked content. It roughly corresponds to the meaning of HTML’s element.

Example

The venue must provide<br>step-free access to the main entrance<br>before the event contract is finalized.

In ordinary HTML, this would usually be better:

The venue must provide<br>step-free access to the main entrance<br>before the event contract is finalized.

How, when, and why you would use it

Use role="mark" when content is visually highlighted and that highlighting carries...