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

[spectranaut]

I added the "waiting for implementations" tag but I was wrong, this isn't ready for implementation -- I didn't look close enough. This change still needs the following before it can be implemented:

• three approving reviews
• accname changes
• tests

This new process is a work in progress, so let me know if there are questions/concerns!

[jcsteh]

My only concern here is performance. The content of container elements like these can be potentially massive, and because of potential mutations, it's not even as simple as just caching the first heading when we build the tree. Is it reasonable for UAs to impose some limit on how many nodes we check? If so, I wonder if that needs to be specified somehow?

[cookiecrook]

@jcsteh wrote:

Is it reasonable for UAs to impose some limit on how many nodes we check?

Certainly possible, but where to draw the line? Some web dev will hit an arbitrary depth limit. Do we tie it to DOM or rendering heuristics? My original issue was intended to allow some spec permissiveness so that implementations could account for this as best they could, which may eventually inform a best path forward... AS of now, some of those heuristics are explicitly disallowed by the spec.

What modification do you propose?

[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