Skip to content

Conversation

@cookiecrook
Copy link
Contributor

@cookiecrook cookiecrook commented Oct 9, 2025

Closes w3c/accname#138
Closes #1018
Closes #1860
Closes #2209
Closes w3c/accname#182
Closes w3c/accname#229

Related to #2215

Add namefrom: heading again; Will year 6 be the year?

Roles that are affected: now namefrom: author, heading:

  • alertdialog
  • article
  • dialog

History and Readiness:

I was worried this might never make it into the spec, but we now have:

  • approval from ARIA WG (including prior PR approval from @accdc, @scottaohara, and @aleventhal)
  • a no-conflict, single-monorepo pull request
  • live WPT tests
  • a shipping implementation (WebKit)
  • support from a second implementation (Chromium)
  • support (IIRC @keithamus?) from a third implementation (Gecko)

Please re-review and merge this ASAP before this layered PR stagnates again... Thanks!

Implementation tracking


Preview | Diff

@netlify
Copy link

netlify bot commented Oct 9, 2025

Deploy Preview for wai-aria ready!

Name Link
🔨 Latest commit 30a7f56
🔍 Latest deploy log https://app.netlify.com/projects/wai-aria/deploys/68f8331232ce8500082351b3
😎 Deploy Preview https://deploy-preview-2650--wai-aria.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

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

@cookiecrook cookiecrook added the F2FCandidate Candidate topics for F2F (or Virtual F2F) meeting label Oct 9, 2025
@cookiecrook
Copy link
Contributor Author

cookiecrook commented Oct 9, 2025

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.

@scottaohara
Copy link
Member

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

@cookiecrook
Copy link
Contributor Author

cookiecrook commented Oct 9, 2025

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.

@spectranaut
Copy link
Contributor

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.

@cookiecrook
Copy link
Contributor Author

cookiecrook commented Oct 11, 2025

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

@cookiecrook
Copy link
Contributor Author

cookiecrook commented Oct 11, 2025

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.

Copy link
Contributor Author

@cookiecrook cookiecrook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding comments to make review easier.

</tr>
<tr>
<th class="role-namefrom-head" scope="row">Name From:</th>
<td class="role-namefrom">author</td>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewer context: this is on the dialog role

</tr>
<tr>
<th class="role-namefrom-head" scope="row">Name From:</th>
<td class="role-namefrom">author</td>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewer context: this is on the article role

</tr>
<tr>
<th class="role-namefrom-head" scope="row">Name From:</th>
<td class="role-namefrom">author</td>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewer context: this is on the alertdialog role

modal dialog design patterns.
</p>
<p>Authors SHOULD provide an accessible name for a dialog, which can be done with the <pref>aria-label</pref> or <pref>aria-labelledby</pref> attribute.</p>
<p>Authors SHOULD provide an accessible name for a dialog, using either <a href="#namecalculation">namefrom</a>: author or <a href="#namecalculation">namefrom</a>: heading.</p>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given a dialog that contains an <h2> for example, would it be preferable for authors to use aria-labelledby or rely on nameFrom: heading? Should nameFrom: author be preferred over nameFrom: heading?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the AccName computation prioritizes namefrom:author first... namefrom:heading is only used as a fallback.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The direct author reference is probably slightly more performant, but I don't think a change is needed here unless you have one to suggest.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a personal clarification to make sure I'm using this new nameFrom technique properly 😄

@rahimabdi
Copy link
Contributor

rahimabdi commented Oct 15, 2025

@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.")?

@cookiecrook
Copy link
Contributor Author

cookiecrook commented Oct 20, 2025

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

Co-authored-by: Rahim Abdi <abdi.abdirahim@gmail.com>
Co-authored-by: Rahim Abdi <abdi.abdirahim@gmail.com>
@cookiecrook
Copy link
Contributor Author

cookiecrook commented Oct 20, 2025

@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?

@cookiecrook cookiecrook requested a review from rahimabdi October 21, 2025 17:57
Copy link
Contributor

@rahimabdi rahimabdi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🚀

@jcsteh
Copy link

jcsteh commented Oct 21, 2025

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!

</li>
<li>
If the <a data-cite="accname-1.2/#dfn-accessible-name">accessible name</a> is still empty, then: if the `dialog` element has a
<a href="https://dom.spec.whatwg.org/#concept-tree-descendant">descendant</a> element with a role of `heading`, then use the
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This refers explicitly to a DOM descendant. Does this mean aria-owns content should explicitly be excluded from this check? For example, should we skip NameFrom: heading in this case?

data:text/html,<article aria-owns="content"></article><div id="content"><h1>Some heading</h1>

Does that also mean we shouldn't consider aria-owns content when doing name computation for a dialog? For example, in this case, do we take first or second as the label of the dialog?

data:text/html,<article aria-owns="first second"><h1 id="second">second</h1></article><h1 id="first">first</h1>

I think we should respect aria-owns for consistency. That means we should be using accessibility descendants.

Co-authored-by: James Teh <jamie@jantrid.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Agenda F2FCandidate Candidate topics for F2F (or Virtual F2F) meeting spec:accname spec:aria spec:html-aam

Projects

Status: Needs Review

7 participants