search

w3c / accname

Accessible Name and Description Computation
https://w3c.github.io/accname/
61 stars 23 forks source link

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

Open cookiecrook opened 1 year ago

cookiecrook commented 1 year ago

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

cookiecrook commented 1 year ago

Note: Please don't add this one until https://github.com/w3c/accname/pull/186 is merged.

cookiecrook commented 7 months ago

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

accdc commented 7 months ago

What are the next steps for moving this forward?

cookiecrook commented 7 months ago

What are the next steps for moving this forward?

Citing my understanding of the outcome of:

cookiecrook commented 7 months ago

@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 commented 7 months ago

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 commented 6 months ago

agenda+ to discuss https://github.com/web-platform-tests/wpt/pull/44490

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

cookiecrook commented 6 months ago

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 commented 6 months ago

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

spectranaut commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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.