Update from PR #1018 for nameFrom: heading

[cookiecrook]

Part of #w3c/accname/issues/138

Adds nameFrom: heading (this overcomes PR #1018)

Will update these along the way after further discussion and review.

• Related AccName Issue/PR: Add nameFrom: heading steps to computation after spec addition ARIA PR #1860 is reviewed. accname#182
• Related APG Issue/PR:

Implementation tracking

• validator tests
• WPT tests: NameFrom: Heading... WG preferred DFS over IDS/IDDFS search web-platform-tests/wpt#50507
• Browser implementations (link to issue or when done, link to commit):
  • WebKit 257186
  • Gecko 1834463
  • Blink 1447981
  • direct link to WPT test results https://wpt.fyi/results/accname/name/comp_name_from_heading.tentative.html
• Does this need AT implementations? Unlikely. Should be an engine-specific change.

---

Preview | Diff

[cookiecrook]

Adding three reviewers that were prior contributors to #1018.

[scottaohara]

just a quick list of the roles that will get name from heading

• alertdialog
• article
• complementary
• dialog
• form
• region (with HTML caveat)

My initial review:

complementary may need a caveat added per the conditional complementary role for the aside element.

similarly, I think form would need a host language caveat mentioned as well, as while I think this update works since ARIA requires role=form have an accName, I don't think every HTML form element should automatically get an accName. That'd have the potential to add extra and unnecessary landmark verbosity to many web pages

should we consider adding group to this as well? Esp. since it's more likely for AT to even expose an element with role=group if it's named. If there's a heading there, it could be done for authors without the need to use aria-labelling. But per my comment above, maybe this would have the inverse impact of creating too much verbosity where things were already "fine" from the user's perspective?

additionally, navigation should be considered for naming by heading. many instances of people using headings (visible or not) to name navigation landmarks via aria-labelledby.

i'm quite a fan of all other aspects of this PR.

[cookiecrook]

@scottaohara wrote:

Thanks.

complementary may need a caveat added per the conditional complementary role for the aside element.

To clarify, are you suggesting nameFrom: heading be removed from both <aside> and role="complementary" or only from the contexts where aside is not complementary?

similarly, I think form would need a host language caveat mentioned as well, as while I think this update works since ARIA requires role=form have an accName, I don't think every HTML form element should automatically get an accName. That'd have the potential to add extra and unnecessary landmark verbosity to many web pages

I don't have a strong opinion either way, so I'll remove it in the PR unless there are objections. To clarify, are you suggesting nameFrom: heading be removed from both <form> and role="form" or something else?

should we consider adding group to this as well? Esp. since it's more likely for AT to even expose an element with role=group if it's named. If there's a heading there, it could be done for authors without the need to use aria-labelling. But per my comment above, maybe this would have the inverse impact of creating too much verbosity where things were already "fine" from the user's perspective?

I think group should remain explicitly named, for the verbosity risk you've outlined.... but I could be convinced if you and others have strong opinions for it.

additionally, navigation should be considered for naming by heading. many instances of people using headings (visible or not) to name navigation landmarks via aria-labelledby.

I support this.

[jnurthen]

common/script/aria.js needs moving to aria-common but otherwise looks good.

I like the scope of the other changes being limited to

• alertdialog
• article
• complementary
• dialog
• region (with caveats)
  as it is now. We can always add more later if folks think that is desired.

[scottaohara]

@cookiecrook
Re: complementary and form, yes would need to be clear that while these ARIA roles can get name from heading, the equivalent HTML elements may not (aside) or would not (form) get name from headings.

re: group, agreed. i felt icky suggesting it, and your response didn't wash the ick away. so let's forget it..

[cookiecrook]

Re: complementary and form, yes would need to be clear that while these ARIA roles can get name from heading, the equivalent HTML elements may not (aside) or would not (form) get name from headings.

Maybe we should consider taking complementary and region out of the list because of these caveats? We can always add them back in with separate issues.

Especially since we're now working on automated AccName tests...

[scottaohara]

sounds like a good idea to me.

[cookiecrook]

Recycling reviews because I think this addresses all the feedback now.

Affected roles now limited to the following for this PR.

• alertdialog
• article
• dialog

Others that are no longer in this diff, but should be taken as separate PRs due to editorial and host language caveats are:

• complementary
• region

Also @jnurthen I have filed the script changes as w3c/aria-common#89 I wasn't sure how to mark that PR as blocking this one. FYI @scottaohara

[aleventhal]

I'm no longer blocking this, so @jnurthen you're up next and then this can finally land.

[aleventhal]

Ah, this is "waiting for implementations", which means we should land the changes in Blink and not wait for it to be merged into the spec, right?

[cookiecrook]

Note for other reviewers, the only recent change is "(depth first search)" to clarify the markup test the WG discussed since I posted the original PR.

[netlify]

✅ Deploy Preview for wai-aria ready!

Name	Link
🔨 Latest commit	bf43418
🔍 Latest deploy log	https://app.netlify.com/sites/wai-aria/deploys/67a2d8a899dbd200084314d4
😎 Deploy Preview	https://deploy-preview-1860--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 site configuration.

[cookiecrook]

@aleventhal wrote:

Ah, this is "waiting for implementations", which means we should land the changes in Blink and not wait for it to be merged into the spec, right?

Sorry I missed this... I think the test was supposed to land first... but there was some discussion of DFS vs IDS which hadn't landed yet... See the last test in:

• NameFrom: Heading... WG preferred DFS over IDS/IDDFS search web-platform-tests/wpt#50507

[cookiecrook]

Oh good... looks like that Chrome change wasn't merged into shipping yet. All browsers still align...

https://wpt.fyi/results/accname/name/comp_name_from_heading.tentative.html?label=pr_head&max-count=1&pr=50507

[Update Feb 28, 2025] this is merged now so live results will be here soon:
https://wpt.fyi/results/accname/name/comp_name_from_heading.tentative.html?label=experimental&label=master&aligned

[cookiecrook]

PR has been open for over 2 years... I'm no longer sure how many times I've re-resolved git conflicts that came in later.

[cookiecrook]

@aleventhal wrote:

I'm no longer blocking this

@aleventhal @tranjocelyn See above comment on Feb 4... If you've landed this already, there is more to be done.
https://wpt.fyi/results/accname/name/comp_name_from_heading.tentative.html?label=experimental&label=master&aligned

[pkra]

@cookiecrook @aleventhal the current process requires 1 implementation and another intent-to-implement. So I think if webkit merges WebKit/WebKit#43080, we should be able to merge here (and update accname).

If that's not in the cards, then I would suggest to split this PR into two: the piece which introduces name-from-heading and the piece that allows name-from-heading on specific roles.

The first part is the lengthier one but wouldn't technically need implementations, so I think we could merge that. The second part is then just adding things to the name-from table rows.

(I would also split out the the editorial changes - they should be separate.)

[cookiecrook]

@pkra wrote:

we should be able to merge here (and update accname).

Agreed. I will wait for @rahimabdi to merge the WebKit update and then resolve the conflicts here. I don't see a reason to split the PRs into separate algo and attributes PRs. That's an academic distinction that I can't see providing any benefit.

(I would also split out the the editorial changes - they should be separate.)

Are you talking about the tabs vs space correction that was on either side of my new nameFromHeading section? Normally I'd agree with not introducing whitespace changes in a substantive to different parts of the document, but these are related adjacent sections. That's always been fair-game with ARIA editorial practices as far as I am aware. Otherwise, you're asking me to introduce a new inconsistency to the leading whitespace within my new section. Right? (Please reconsider? 🙏🏼)

PS. I called this out and the reason for it two years ago.

[cookiecrook]

Otherwise, you're asking me to introduce a new inconsistency to the leading whitespace within my new section.

For clarity, my choices are:

1. keep it the way it is, which is what we ultimately want, or…
2. Add my new section with leading chars that are inconsistent with the file conventions (will need to be changed later, reducing the usability of git blame), or…
3. Add my new section with leading chars that are inconsistent with the surrounding text (will reduce readability until the other surround whitespace errors are corrected).

[pkra]

(I would also split out the the editorial changes - they should be separate.)

Are you talking about the tabs vs space correction that was on either side of my new nameFromHeading section?

No, I meant the two removals. I primarily suggested them to simplify a merge. (FYI prettier formatting is done automatically by CI).

[cookiecrook]

Working on this again... Merge conflicts plus the monorepo change that has happened in the meantime make it impractical to fix the existing PRs in the old repos.

Working on another. Fourth times the charm. At least the implementations are no longer the bottleneck???