#1234: WG Revision: wai-aria-1.3 20260604

Visit on Github

Opened Jun 5, 2026

Specification

https://www.w3.org/TR/2026/WD-wai-aria-1.3-20260604/

Explainer

none

Links

<!-- Make a copy of the below items for each distinct feature that has changed since our previous review, and fill in links to describe that feature. For small changes, these may all be included in the issue that motivated the change, but please double-check that all the answers are actually there. -->

Feature 1:

  • Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/####
  • An introduction to the feature, aimed at unfamiliar audiences: https:// <!-- Can be the specification's or explainer's introduction, or another section. -->
  • A description of the problems that end-users were facing before this proposal: https:// <!-- See https://w3ctag.github.io/explainer-explainer/#end-user-need -->
  • Alternatives considered: https:// <!-- See https://w3ctag.github.io/explainer-explainer/#alternatives -->
  • Examples of how to use the proposal to solve the end-users' problems: https:// <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
  • What do the end-users experience with this proposal: https:// <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
  • User research you did to validate the problem and/or design, if any: https://
  • Web Platform Tests: <!-- Or other tests if this is not a web platform feature. -->

The specification

Where and by whom is the work is being done?

  • GitHub repo: https://github.com/w3c/aria/
  • Primary contacts:
    • Daniel (@daniel-montalvo), W3C, Staff Contact/Editor
    • James Nurthen (@jnurthen), Evinced, Chair/Editor
    • Valerie Young (@spectranaut), Igalia, Chair
  • Organization/project driving the specification: Google, Apple, Microsoft, Mozilla, UsableNet, and others
  • This work is being funded by:
  • Primary standards group developing this feature: ARIA
  • Incubation and standards groups that have discussed the design:
    • {{ABC CG}} <!-- Include a link to minutes or issues in this group if possible. -->
    • {{DEF WG}}

Feedback so far

  • Active horizontal reviews: https://github.com/w3c/aria/issues/2812
  • Multi-stakeholder feedback: comments of this nature happen on the relevant ARIA PRs
  • Major unresolved issues with or opposition to this specification: none
  • Status/issue trackers for implementations: <!-- Include links to [Chrome Status](https://chromestatus.com/), [Mozilla's](https://bugzilla.mozilla.org/), [WebKit's Bugzilla](https://bugs.webkit.org/), and trackers for other implementations if those are known to you. -->

You should also know that...

No response

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1234

Discussions

Log in to see TAG-private discussions.

Discussed Jun 22, 2026 (See Github)

Matthew: APA is currently reviewing this. It seems good. APA has some questions in relation to some new roles.. .added new "sectionheader" and "sectionfooter" roles. I was concerned about them being new landmarks. But they are not, so I'm still waiting to hear about how these new roles will be used. There's a new ARIA notify API. It is an alternative to the existing live regions, which are regions that get announced to the AT if something changes (e.g., think like an auditory status bar). The declaritive way to do it is live regioins but doesn't work for some cases. Here is where an imperative API is simpler and very privacy preserving. It's a good example of a "author proposes, user disposes" principle.

Christian: how do we move forward here? Wait for Lola to return?

Matthew: they changes are not exactly architectural. I could draft it and maybe get someone else on the TAG to reivew it. The are on a deadline so maybe we can just post it this week. The deadline might be this week or early next week.

Discussed Jun 29, 2026 (See Github)

Matthew: Is ARIA Notify architectural or not? My understanding is: This is not controversial. Checked browser positions, and didn’t notice any controversies. Luke, any background on browser positions?

Luke: Haven’t looked into this, no pushback whatsoever. Work needs to be done on the screenreader side, but that’s for the next iteration. Same as live regions. Recollection is that it is well supported by everyone.

Matthew: MDN says it’s not implemented yet.

Christian: So do you want to close it as "satisfied" now?

Matthew: Not controversial, think it’s good, but lacking support as per MDN. Don’t want to special-case this.

Luke: MDN is not super clear. Implemented in Chromium (Win, Linux), and is in Firefox. Believe it is in Safari as well. There is a WebKit standards position that is supportive.

Christian: Which would support "satisfied"?

Luke: Doesn’t have anything for Braille though. There is an ARIA Braille label, where you can provide a different version. Does it need that? Don’t think it blocks V1, but maybe should be added?

Matthew: Think that was covered in the explainer, and think it was postponed to the next iteration. Will check that, and if it’s missing, add it to the comment. Will be satisfied.

Luke: Agree.

Discussed Jul 6, 2026 (See Github)

Matthew: Need to check Braille and ARIA Notify. It’ll be satisfied anyway.