Add tests for accnames from hidden labels, captions, and legends

[adampage]

Accname tests to support w3c/html-aam#533’s clarification that hidden labels, captions, and legends will not provide an accname to their naturally associated elements unless they are explicitly referenced using aria-labelledby.

[cookiecrook]

Looks okay to me, but not merging immediately since we only got one CI run.

[scottaohara]

would this PR be the place to also create the tests for how browsers should use other naming mechanisms if these elements are hidden?

e.g.,

<label for=d hidden>
  this should not be used, cause it'll return the empty string
</label>
<input id=d title="this should be used">

[adampage]

would this PR be the place to also create the tests for how browsers should use other naming mechanisms if these elements are hidden?

So... I took ☝🏻 this ball and ran with it... maybe in the wrong direction. 😵‍💫

I focused on HTML-AAM’s “4.1 Accname computation by element” section and wrote/copypasta’d a boatload of new tests for each specific element identified there.

Every test specimen follows the same pattern: I simultaneously throw all possible accname techniques at the element, then I assert which one should win based on the conditionals described in the spec. Next, I eliminate 1 technique at a time for subsequent test specimens, rinse and repeat until the element has no remaining accname candidates.

I took a few notes along the way for a few tweaks I might propose in the HTML-AAM spec. I also left 2 sections incomplete:

• 4.1.7 Other form elements — I just did input type="radio", input type="checkbox", and select as a start.
• 4.1.16 Section and grouping elements — I just did section, article, and nav as a start.

Anyhow, I’ll pause here. The test results are interesting. Please let me know what you think, @scottaohara / @cookiecrook.

[cookiecrook]

Updating because this PR increased in scope since my last review. I shared offline feedback with Adam: mainly that the numbered directories might be fragile (as the spec changes) and that they may complicate the browsing experience on wpt.fyi. He also plans to utilize a new JavaScript convenience method to reduce some of the markup duplication.

[adampage]

Alrightey, @cookiecrook and @scottaohara, I just committed a monster of an update. 😬

This change:

• Removes the brittle numbered directory names corresponding to the HTML-AAM computation sections.
• Replaces the static subtests with dynamic markup generation.

Now that the subtests are being built dynamically, I was able to quickly introduce a bunch more name-supporting HTML elements that I‘d neglected in my previous push (e.g., <thead>, <progress>, <hr> 🤯 , <input type="color">, etc.).

As a result, the number of subtests have almost doubled from 276 to 510.

I also scattered a few TODO notes around, such as this bit about phrasing elements which I think dovetails with ARIA issues you’ve filed recently, @scottaohara / @rahimabdi. Many of these notes will require deeper investigation on my part. I’m hoping most of them will be resolved either by:

1. Proposing updates to the HTML-AAM spec itself
2. Updating/removing specific test expectations
3. Accepting a failed test result and filing browser bugs

There are also a number of tests that are failing because of web driver errors, such as <optgroup>. I’m not sure what do with those, if anything?

At the end of all of this, I’m looking at HTML-AAM’s Accessible Name Computations By HTML Element section and thinking it could be simplified. Most of the computation steps follow a very linear path through a prioritized set of potential naming sources. My gut says we can define a very small number of “rule sets” and then make a table to pair each nameable HTML element with one of those rule sets. cc: @rahimabdi

[cookiecrook]

incomplete review, and I plan to come back to it, but wanted to share feedback as I can since my work time is limited.

[cookiecrook]

Bulk edit of stale PRs... If you're the original submitter or assignee, will you dig back through the history and determine what the next steps are? Thanks.

[scottaohara]

did a quick review of this with @rahimabdi today. some new comments for you @adampage (for when you have time to look, again)

[adampage]

Awesome, thanks very much, @scottaohara and @rahimabdi. I’m keen to land this one. I’ll make time within the next couple weeks to review and update.

[adampage]

Heya @scottaohara / @rahimabdi / @giacomo-petri / @cookiecrook, thank you for your reviews, and apologies for taking so long to get back this. I’ve reviewed the last year’s (🤯) worth of feedback and made these 3 updates:

1. Removed figcaption as a name source for figure — latest results
2. Added figcaption as a name source for an imgelement with afigure` ancestor — only Safari passes
3. Added aria-placeholder as a name source after placeholder — only Firefox fails

Here’s the latest browser results for the complete set.

[rahimabdi]

LGTM, thank you very much @adampage!

I especially like the html-aam/scripts/html-aam-accname-utils.js utils which should make future testing easier.

[giacomo-petri]

For a potential follow-up PR, since we've added specific scenarios, it might be worth considering scenarios where the element is encapsulated by its label (e.g., a button or an input type button), in which case the label and its content/value should be excluded.
e.g.
button

If the button element is encapsulated by its label element, ignore the button element's subtree from its computed accessible name.

input[type="button"]

If the control is encapsulated by its label element, and the control has an author specified value or the lack of a value has produced an implementation defined string to render, then exclude either from the control's computed accessible name.

important
In other-form-elements.html, we should probably remove the input type="hidden", since it is removed from the accessibility tree, and I don't think we should be checking its acc name

[adampage]

For a potential follow-up PR, since we've added specific scenarios, it might be worth considering scenarios where the element is encapsulated by its label (e.g., a button or an input type button), in which case the label and its content/value should be excluded. e.g. button

Oh, nice one, @giacomo-petri — I hadn’t caught this update to HTML-AAM. I’ve added it to this PR via 9953c9c.

important In other-form-elements.html, we should probably remove the input type="hidden", since it is removed from the accessibility tree, and I don't think we should be checking its acc name

Oh my goodness. 🤦🏻 Thank you for catching this. Fixed in 96fea49.