✅ Deploy Preview for wai-aria ready!

Name	Link
🔨 Latest commit	92fe150
🔍 Latest deploy log	https://app.netlify.com/projects/wai-aria/deploys/697113abafb7d5000847a465
😎 Deploy Preview	https://deploy-preview-2650--wai-aria.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Tagging F2FCandidate because if this third-attempt PR (or maybe it’s the fifth?) hasn't merged by TPAC, we should lock the doors until it is.

@cookiecrook i had done this work as well for html aam #2215

Taking a note from the WG call today to double-check the history for form and region. @rahimabdi asked for additional tests, and @mcking65 wondered if region should be left out due to a more recent spec change related to that role.

Discussed during triage today: https://www.w3.org/2025/10/09-aria-minutes.html#31d8

I believe @cookiecrook has some follow up tasks and we are primarily waiting for a second implementation or stronger implementation commitment.

Confirmed nameFrom:heading was removed from region (and complementary FWIW) in the prior PR in this commit and determined we would address it elsewhere. Will pull that role here, too, but not yet sure wondering why the related prose remained. Probably just an oversight, so thanks Matt...

Both region and form had seemingly related prose about using heading as the label. Removing it was technically an editorial change, but in the new PR, I accidentally made it substantive with the addition of namefrom: heading on those two. I will correct that error, and also NOT remove the duplicative text for the roles that should not be related to this PR, and that should resolve both Rahim and Matt's comments.

@cookiecrook One thought that came to mind during implementation was around the descendant element with role="heading", and that it could potentially be a link or image (which is common practice) rather than just a text node. I think nameFrom: heading still applies here but should this be specified in spec (e.g., "first descendant element node matching the role of heading (including headings that contain images or links.")?

Lucas, in this comment, indicated potential Q4 2025 support for Chromium/Edge.

@rahimabdi wrote:

@cookiecrook One thought that came to mind during implementation was around the descendant element with role="heading", and that it could potentially be a link or image (which is common practice) rather than just a text node. I think nameFrom: heading still applies here but should this be specified in spec (e.g., "first descendant element node matching the role of heading (including headings that contain images or links.")?

What's special about a heading containing a an image or link that would not also apply to some other type of content? The label derived for the element that supports namefrom:heading will be the heading's label. But then that element's label will be derived from running its contents through the computation... link gets its name from author or contents... image from author via alt or aria-label. Wouldn't the same be true for any included [fill in the blank] element? If so, why the need for special mention?

In general, this makes sense to me. However, I'm wondering if there has been any discussion anywhere regarding mutations, events and the performance thereof.

When the name of anything changes, the browser should ideally fire a name change event. The importance of this differs between operating systems and browser implementations, but it's still generally the right thing to do. For Firefox (and I assume Chromium), failure to fire an event could result in a stale cross-process cache, so it's particularly important there. However, clients may depend on the event as well.

There are two particular challenges here:

1. When the name of a heading changes, we need to potentially check to see if it's being used as the name of a NameFrom: heading element (<dialog>, etc.). Because the rules specify that we must search for the first descendant heading, this could get a bit expensive, especially if the heading is somewhat deep or far in the subtree. I guess we could cache the heading associated with a NameFrom: heading element, but that introduces its own complexity.
2. When a heading is moved in the tree, we need to do the same.

@rahimabdi, does WebKit fire name change events for these cases? Did you run into any issues implementing those?

I'd also be curious as to whether anyone has done any design thinking on this for Chromium and considered these issues.

Thanks!

The ARIA Working Group just discussed Add namefrom: heading. https://github.com/w3c/aria/pull/2650.

As a status update, this stalled due to a comment at W3C TPAC (Nov 2025) from @jcsteh pointing out that we haven't fully considered what happens in the case of DOM mutations.

As a status update, this stalled due to a comment at W3C TPAC (Nov 2025) from @jcsteh pointing out that we haven't fully considered what happens in the case of DOM mutations.

Just in case this isn't clear, I documented my concerns shortly prior to TPAC in #2650 (comment). My comment at TPAC was just flagging this comment.

🚀 Deployed on https://deploy-preview-2650--wai-aria.netlify.app

As a status update, this stalled due to a comment at W3C TPAC (Nov 2025) from @jcsteh pointing out that we haven't fully considered what happens in the case of DOM mutations.

Just in case this isn't clear, I documented my concerns shortly prior to TPAC in #2650 (comment). My comment at TPAC was just flagging this comment.

I feel like we already have plenty of similar issues, where we need to fire a name change event because an element uses aria-labelledby and the target ID changes its effective name, sometimes in some roundabout way like a descendant changing.

Chromium and WebKit have both fixed bugs along those lines before. They both already keep track of reverse maps for all IDREF relations to make that sort of thing more efficient.

I'm not arguing that this sort of thing is easy; some of those fixes are tricky. Rather, I'm just arguing that it's already the status quo that browsers have to keep track of a lot of complex relationships in order to implement accessible names and to keep them updated as the DOM mutates.

My feeling is that these scenarios don't actually come up that often in the real world - or rather, that most accessibility bugs we spend time fixing aren't of this variety. However, when they do they're treated as bugs and fixed.

I feel like we already have plenty of similar issues, where we need to fire a name change event because an element uses aria-labelledby and the target ID changes its effective name, sometimes in some roundabout way like a descendant changing.

That's true. However, existing "name from subtree" cases are for roles which are expected to have relatively few descendants; e.g. button, link, heading, etc. In contrast, things like dialogs will very possibly have many, many descendants. That makes the cost of calculating (and maintaining) name from subtree potentially much more expensive.

My feeling is that these scenarios don't actually come up that often in the real world - or rather, that most accessibility bugs we spend time fixing aren't of this variety. However, when they do they're treated as bugs and fixed.

Fair. On the other hand, I think we should be cautious about introducing things into the spec where the probability of hitting a performance cliff which is difficult to mitigate might be quite high.

@jcsteh wrote:

That makes the cost of calculating (and maintaining) name from subtree potentially much more expensive.

The only scenarios I anticipate where the perf would be bad would be scenarios where web authors have made multiple mistakes... e.g. a dialog, with no label, no labelled-by, no nearby included heading, with excessively long contents... so the cost would only be on sites where that dialog was already unlabeled...

maybe there's a lazy-load label compromise, where after some reasonable delay trying to find the fallback heading (500ms? 700ms?), NVDA or VO would just speak "dialog" (as if it's unlabeled) and then update that assumption for the user later when or if the label search comes back before the user moves on to another element.

Fair. On the other hand, I think we should be cautious about introducing things into the spec where the probability of hitting a performance cliff which is difficult to mitigate might be quite high.

As you mentioned, the existing "name from subtree" cases are supposed to have few descendants, but in obscure cases there might be lots, so I know some browsers already enforce a limit that's not in the spec, for performance reasons.

In this particular case, would a limit on how far to search for a heading descendant mitigate it?