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

<p>
  The event starts at
  <span role="suggestion" aria-details="suggestion-comment-1">
    <span role="deletion">9:00 AM</span>
    <span role="insertion">10:00 AM</span>
  </span>.
</p>

<div id="suggestion-comment-1" role="comment">
  Suggested by Jane because the keynote was moved later.
</div>

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

<p>
    We test our website annually against WCAG 2.2 AA.
    <button
      type="button"
      aria-label="Comment on annual testing claim"
      aria-details="comment-annual-testing"
    >
      Comment
    </button>
  </p>

  <aside id="comment-annual-testing" role="comment">
    <p>
      Reviewer comment from Alex: This should say whether testing is performed
      internally, by a third party, or both. We should also link to the latest
      conformance report if one is available.
    </p>
  </aside>

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 <mark> element.

Example

<p>
  The venue must provide
  <span role="mark">step-free access to the main entrance</span>
  before the event contract is finalized.
</p>

In ordinary HTML, this would usually be better:

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

How, when, and why you would use it

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

Examples include search results where matching text is highlighted, document review tools, excerpts where key passages are marked, legal or policy documents where important text is highlighted, and educational tools that mark important concepts.

Highlighting is often visual-only. If the highlight means “this matched your search,” “this is important,” or “this passage was selected for review,” that meaning should not be available only to sighted users. However, do not use role="mark" just because something has a yellow background. If the styling is purely decorative, it does not need semantic exposure.

New feature: aria-description

aria-description provides a direct string-based accessible description. It is similar in purpose to aria-describedby, but instead of referencing another element by ID, the description is supplied directly on the element.

Example

<button
  type="button"
  aria-label="Export"
  aria-description="Exports the current report as a CSV file."
>
  <svg aria-hidden="true" focusable="false">
    <!-- icon -->
  </svg>
</button>

How, when, and why you would use it

Use aria-description when an element needs an accessible description, but there is no appropriate visible text in the DOM to reference.

Possible use cases include icon-only controls that need supplemental explanation, compact interfaces where visible helper text would be redundant, generated controls where descriptive text exists in data but not as visible DOM content, and custom widgets where a short name is not enough.

Accessible names and accessible descriptions solve different problems. A name tells the user what something is. A description gives additional context.

<button
  aria-label="Delete"
  aria-description="Deletes this saved payment method. You will be asked to confirm."
>
  Delete
</button>

The name is “Delete.” The description explains the consequence.

Important caution

If the descriptive text is visible on the page, prefer aria-describedby.

<label for="api-key">API key</label>
<input id="api-key" aria-describedby="api-key-help">

<p id="api-key-help">
  Use a restricted key with read-only permissions.
</p>

This is less ideal:

<input
  id="api-key"
  aria-description="Use a restricted key with read-only permissions."
>

The second example hides useful instructional content from sighted users and duplicates something that could simply exist in the page.

New feature: aria-braillelabel

aria-braillelabel provides a braille-specific label.

Example

<button
  aria-label="Previous page"
  aria-braillelabel="Prev"
>
  Previous
</button>

How, when, and why you would use it

Use aria-braillelabel only when the normal accessible name is not ideal for braille output.

Possible examples include reducing overly verbose labels for braille displays, using conventional braille abbreviations, improving compactness where braille display space is limited, and avoiding repeated words in a dense interface.

Braille displays have limited cells. A label that works well as speech output may be too verbose for efficient braille reading. aria-braillelabel gives authors a way to provide a different label specifically for braille users.

Important caution

This is not a general shortcut label. The visible label, accessible name, and braille label should not conflict. If the braille label changes the meaning or removes necessary context, it can make the interface worse.

Bad:

<button
  aria-label="Delete project permanently"
  aria-braillelabel="OK"
>
  Delete project
</button>

Better:

<button
  aria-label="Delete project permanently"
  aria-braillelabel="Del project"
>
  Delete project
</button>

The second version is shorter, but still preserves the essential meaning.

New feature: aria-brailleroledescription

aria-brailleroledescription provides a braille-specific role description. It is related to aria-roledescription, but intended for braille output.

Example

<div
  role="region"
  aria-label="Conference schedule"
  aria-roledescription="interactive schedule"
  aria-brailleroledescription="sched"
>
  <!-- schedule UI -->
</div>

How, when, and why you would use it

Use aria-brailleroledescription when a custom role description is useful, but the spoken role description would be too long or awkward in braille.

Possible use cases include custom document regions, complex application panes, specialized data viewers, dense enterprise applications, and custom components where the role description is helpful but verbose.

Like aria-braillelabel, this is about optimizing for braille output. Braille users may benefit from shorter role descriptions when navigating dense interfaces.

Important caution

This should be rare. Also, it should not be used to invent misleading roles. If something is a button, let it be a button. Do not use role descriptions to disguise standard controls.

Bad:

<div
  role="button"
  aria-roledescription="magic action launcher"
  aria-brailleroledescription="magic"
>
  Submit
</div>

Better:

<button type="submit">
  Submit
</button>

Change: aria-details can reference multiple elements

ARIA 1.3 proposes allowing aria-details to take multiple ID references.

Example

<p>
  The annual plan includes advanced reporting.
  <button
    type="button"
    aria-details="pricing-detail compliance-detail cancellation-detail"
  >
    More details
  </button>
</p>

<section id="pricing-detail">
  <h2>Pricing detail</h2>
  <p>The annual plan is billed once per year.</p>
</section>

<section id="compliance-detail">
  <h2>Compliance detail</h2>
  <p>The plan includes access to compliance reporting exports.</p>
</section>

<section id="cancellation-detail">
  <h2>Cancellation detail</h2>
  <p>Cancellation takes effect at the end of the billing period.</p>
</section>

Logic of the change

Real interfaces often have more than one piece of extended detail associated with the same control or content node. ARIA 1.2’s single-reference model was limiting for complex content.

A single chart might have a data table, a long explanation, a methodology note, and a source note. A document passage might have a reviewer comment, a suggested edit, a citation, and a compliance note.

Why it is necessary

One ID reference assumes a simpler relationship than many real-world interfaces have. Allowing multiple references gives authors a cleaner way to associate several pieces of extended information with one element.

Practical caution

aria-details is for extended, structured details. Do not use it as a replacement for aria-describedby when the description is short.

Use aria-describedby for this:

<input id="email" aria-describedby="email-help">

<p id="email-help">
  Use the email address where you want to receive the receipt.
</p>

Use aria-details for this:

<figure>
  <img
    src="chart.png"
    alt="Revenue increased from Q1 to Q4."
    aria-details="chart-data chart-methodology"
  >

  <figcaption>Quarterly revenue by region</figcaption>
</figure>

<section id="chart-data">
  <h2>Chart data</h2>
  <table>
    <!-- data table -->
  </table>
</section>

<section id="chart-methodology">
  <h2>Methodology</h2>
  <p>Revenue is calculated using recognized subscription revenue only.</p>
</section>

Change: aria-errormessage supports multiple ID references

ARIA 1.3’s changelog includes a change to make aria-errormessage an ID reference list, rather than a single ID reference.

Example

<label for="password">Password</label>
<input
  id="password"
  type="password"
  aria-invalid="true"
  aria-errormessage="password-length-error password-character-error"
>

<p id="password-length-error">
  Password must be at least 12 characters.
</p>

<p id="password-character-error">
  Password must include at least one number.
</p>

Logic of the change

A field can fail validation in more than one way. A password field might be too short, missing a number, missing a symbol, and too similar to the user’s email address. A shipping address might have an invalid postal code and a missing region.

The old single-reference model forced authors to either combine all errors into one message container or choose one message to expose.

Why it is necessary

Multiple error references better reflect how validation actually works in modern forms. It also lets developers keep separate error messages separate in the DOM, while still associating all relevant errors with the invalid field.

Practical caution

Do not point to every possible error. Point to the currently applicable errors.

Bad:

<input
  id="password"
  aria-invalid="true"
  aria-errormessage="too-short missing-number missing-symbol reused-password"
>

If only too-short currently applies, only reference that one.

Better:

<input
  id="password"
  aria-invalid="true"
  aria-errormessage="too-short"
>

<p id="too-short">Password must be at least 12 characters.</p>

Then update the ID reference list as validation state changes.

Change: aria-haspopup="false" should not be exposed

ARIA 1.3 includes a clarification that aria-haspopup="false" should not be exposed by user agents.

Example

Unnecessary:

<button type="button" aria-haspopup="false">
  Save
</button>

Better:

<button type="button">
  Save
</button>

Useful:

<button
  type="button"
  aria-haspopup="menu"
  aria-expanded="false"
  aria-controls="account-menu"
>
  Account
</button>

<ul id="account-menu" role="menu" hidden>
  <li role="none"><a role="menuitem" href="/profile">Profile</a></li>
  <li role="none"><a role="menuitem" href="/billing">Billing</a></li>
</ul>

Logic of the change

The absence of aria-haspopup already communicates that there is no popup. Explicitly exposing false adds noise without adding meaning.

Why it is necessary

Assistive technologies need meaningful state and property information, not redundant negative declarations. Exposing aria-haspopup="false" risks cluttering the accessibility tree with information that does not help the user.

Practical takeaway

Only use aria-haspopup when the control actually opens a popup, and use the most specific value that matches the popup type, such as menu, listbox, tree, grid, or dialog. Do not add aria-haspopup="false" as a default.

Change: aria-level is clarified around levels 1–6

ARIA 1.3 includes a clarification around aria-level, aligning it more tightly with familiar heading-level expectations.

Example

<div role="heading" aria-level="2">
  Billing settings
</div>

Better when possible:

<h2>Billing settings</h2>

Logic of the change

Heading levels are meant to communicate document structure. On the web, authors and users generally understand headings as levels 1 through 6 because HTML provides <h1> through <h6>.

Why it is necessary

Unbounded or unusual heading levels can create confusing document outlines.

<div role="heading" aria-level="17">
  Account settings
</div>

A level 17 heading is technically expressive, but it is not practically useful for most users. It suggests a deeply nested structure that probably should be simplified.

Practical takeaway

Prefer real headings:

<h1>Account</h1>
<h2>Billing</h2>
<h3>Payment methods</h3>

Use role="heading" and aria-level only when you cannot use native heading elements.

Acceptable in a custom component:

<div class="card-title" role="heading" aria-level="3">
  Payment methods
</div>

Not ideal in normal HTML:

<div role="heading" aria-level="3">
  Payment methods
</div>

Better:

<h3>Payment methods</h3>

Other document-semantics roles worth watching

The current ARIA 1.3 editor’s draft also includes several document-oriented roles that may be useful in rich editors and structured content systems, including roles such as code, deletion, emphasis, insertion, paragraph, strong, subscript, superscript, and time. These are particularly relevant where native HTML semantics are unavailable, stripped, virtualized, or represented in a custom editing surface.

<span role="code">npm install</span>

<span role="deletion">old pricing model</span>
<span role="insertion">new pricing model</span>

<span role="time">2026-09-30</span>

But again: when writing normal HTML, use normal HTML.

<code>npm install</code>

<del>old pricing model</del>
<ins>new pricing model</ins>

<time datetime="2026-09-30">September 30, 2026</time>

These roles are most interesting for applications that generate accessibility semantics from an internal document model rather than from hand-authored HTML.