Add nameFrom: heading steps to computation after spec addition ARIA PR #1860 is reviewed.

[cookiecrook]

Add nameFrom: heading steps to computation after spec addition #w3c/aria/pull/1860 is reviewed.

[cookiecrook]

Note: Please don't add this one until #186 is merged.

• Add better permalinks for AccName computation. #186

[cookiecrook]

The ARIA spec change is approved, so we should prioritize this AccName PR now.

[accdc]

What are the next steps for moving this forward?

[cookiecrook]

What are the next steps for moving this forward?

• AccName PR Add nameFrom: heading to AccName text alt algorithm #229
• Add nameFrom: heading tests once the AccName change is reviewed web-platform-tests/interop-accessibility#47
• At least 2 implementations out of these 3:
  • WebKit 257186
  • Gecko 1834463
  • Blink 1447981
• Keeping it all out of conflict with other incoming diffs
• Then finally merging it all.

Citing my understanding of the outcome of:

• Requesting changes to new implementation-blocked merging process aria#2055

[cookiecrook]

@jcsteh @aleventhal @dtsengchromium @twilco @jnurthen @spectranaut @scottaohara what do you think of the IDDFS proposal for namefrom: heading in this AccName diff? Also in the tentative WPT diff.

[scottaohara]

hmm... i'm not sure on this.

so per the added test case

<div role="article" ....>
  <div role="group">
    <h3>Not this one</h3>
  </div>
  <h2>article role simple IDS</h2>
  <p>More article content.</p>
</div>

... I am assuming that a generic container would be traversed, and if that div didn't have the role=group, then the h3 would be the name for the article?

<article>
  <div>
    <h2>i'm the name, right?</h2>
  </div>
  ....
  <h3>or am i the name?</h3>
  ...
</article>

If my assumption is correct and it would be traversed since the generic is ignored, what about a div with tabindex=-1? That was left out of the minimum role proposal to become a group, but a focusable generic shouldn't necessarily be ignored... so does the h3 become the name, or is it (still?) the h2?

<article>
  <div tabindex=-1>
    <h2>i'm the name, right?</h2>
  </div>
  ....
  <h3>or am i the name?</h3>
  ...
</article>

But, more importantly, this proposal says to me that the following markup would result in undesired names for the article per valid use of the HTML elements:

<article>
  <header ...>  <!-- role=sectionheader  (role=group w/roledescription of sectionheader)-->
     <h2>this should be the name</h2>
  </header>
   ....
  <h3>this would be the name instead</h3>
  ...
</article>

<!-- and -->

<article>
  <hgroup ...>  <!-- role=group -->
    <h2>this should be the name</h2>
    <p>subtitle text</p>
  </hgroup>
   ...
  <h3>this would be the name instead</h3>
  ...
</article>

[spectranaut]

agenda+ to discuss web-platform-tests/wpt#44490

as briefly discussed in today's meeting: https://www.w3.org/2024/02/15-aria-minutes#t03

[cookiecrook]

hmm... i'm not sure on this.

So in summary, you want the standard "Depth First Search (DFS)" versus the more performant "Iterative Deepening Depth First Search (IDDFS)" I mentioned above? If so, that will result in slower performance of the implementations for any of these roles that support name from heading... I would want unanimity from @aleventhal, @jcsteh, and other WebKit folks that a DFS implementation of name-from-heading would be acceptable.

I do acknowledge that standard DFS is what many authors would expect, but I think it would potentially penalize screen reader users (slower name comp across the board) for the benefit of those authors who should ideally be using aria-labelledby…

[scottaohara]

So in summary, you want the standard "Depth First Search (DFS)" versus the more performant "Iterative Deepening Depth First Search (IDDFS)" I mentioned above?

well, i'm unclear on a couple of points about it still. Again, does <div tabindex=-1> get or not get traversed under IDDFS?

with the header/hgroup example - i suppose that use case i brought up could be mitigated so long as headings within them can be used if header/hgroup elements aren't themselves named. But even that could then be weird if those elements are named, but some rando heading within the article is used, rather than the first one.

i understand the fact that we want things to be as performant as possible, but just looking at a few sites right now, I can see where unwanted headings would become the names of articles - under the assumption that headings within hgroup/header with or without names wouldn't be used to name the article.

here are just a few that i know the article > header > h# pattern is used

• HTML.com - actual heading "HTML Article Element: Learn When (And Where) To Use It Now" would be ignored in favor of "Independent Unit of Content"
• developer.mozilla.org - actual heading "<article>: The Article Contents element" - would be ignored in favor of "Specifications" - all the preceding headings are within region landmarks :( - but if that wasn't the case, then "try it" would be the name of every article on MDN.
• MSNBC article - actual heading "How the Jan. 6 Committee’s playbook could help Biden fix the State of the Union address" would be ignored in favor of "More from MSNBC Daily"

[spectranaut]

Discussed in today's working group meeting: https://www.w3.org/2024/03/07-aria-minutes.html#t06

Decision was to move forward with DFS implementation with performance costs in mind/monitored.

[scottaohara]

from the wg call today, concerning the topic of performance by having to search down the DOM tree to get the correct heading

I recalled a conversation I was having with @aleventhal about how it would potentially be more performant to calculate the contextual roles of header/footer/aside based on their relationship (scope) in the a11y tree to the role that would cause the contextual change - rather than specific HTML elements/parsing the DOM tree.

i mention this if it would be another way to think about trying to calculate name from heading - look for the heading based on the a11y tree (where elements that aren't important might be ignored - e.g., generics) rather than the DOM tree, which is how i was undertandign where the performance hit would be.

[accdc]

I was thinking about performance since the call, and wished to ask. (This may be a naive question since I don't know how the parsing occurs on the backend.)

Is it necessary to traverse the entire tree at all if you already know the container element that is meant to be named from a child heading?

Would it be possible then to simply do this instead:

containerElement.querySelector('h1, h2, h3, h4, h5, h6, *[role="heading"]')

This would be much faster if so.