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]

New tests to a file tracked in the current Interop project would only be accepted if they didn't introduce new failures mid-year. In this case, the 3 new tests are all passing in Chromium, Gecko, and WebKit.... (Edge unknown but likely passing?) so I think it's okay to include this in the PR... With the caveat that we could roll it back in the unlikely chance it causes a failure for Edge.

In the future, it may be easier to include Interop-tracked changes as a separate PR from ones that do not affect the current Interop project.

[adampage]

Ah, understood, thanks. I’ll make that distinction for future PRs and check in with you if I have doubts.

[cookiecrook]

In cases where you need to add a new valid-but-failing tests, add a new file that uses the same file name +".tentative" and have it only include the new failing tests... e.g. comp_hidden_not_referenced.tentative.html

[adampage]

Got it. 👍🏻 I did just manually confirm that latest Edge is passing all 3 new tests, so... no harm no foul? But I’ll stay ready to roll it back regardless.

[cookiecrook]

In cases where you need to add a new valid-but-failing tests, add a new file that uses the same file name +".tentative" and have it only include the new failing tests... e.g. comp_hidden_not_referenced.tentative.html

[cookiecrook]

I'm not certain these tests would be valid w/o the relevant descendants, would they? IIRC, engines invalidate some containers if other required context is missing or invalid, so a table that contained no cell children would not be a table, and therefore your downstream thead expectations may be invalid.

Note: I'm reading this first one as testing <table><thead></thead></table> so if I'm missing some cell additions later, please correct.

[adampage]

Oof, I didn’t even consider that. I’ve filled out the table structures for all the table-related subtests.

I did a quick once-over for the other similarly non-trivial markup structures — area, ruby, summary, etc. — and I believe those are all sufficiently complete.

[adampage]

Now that’s interesting. After implementing your suggestion here, Chrome has 2 new failures and Firefox has 1.

With the previous (incomplete) subtests, everything passed in flying colors.

With the table elements now fully fleshed out, Chrome is happy to let both th and td get their names from their contents, which the HTML-AAM spec doesn’t seem to permit. This is also true for Firefox, but only for th.

[cookiecrook]

I would then recommend marking this file (or just those tests in a new file) as tentative. Then spawn a new ARIA issue for the WG to determine what the "correct" behavior should be.

[adampage]

Thanks, @cookiecrook. I’ve marked that file as tentative.

I also found that issue appears to exist already in w3c/html-aam#543, so I left a comment to mention this test.

[cookiecrook]

After a shorter example source (e.g. "from title" only), it may be good to show the rendered DOM element(s) that will be generated from that source. E.g. img with parent a href using 'from title`

PS. can you use a href in the parent params, or would it need to be an unlinked anchor? Same question on img with an input type=button parent.

[adampage]

If I’m understanding correctly, this might be pushing my scope even further beyond the original intent? 😅

It’s my own damn fault, really, but — at least for polishing off this PR — I’ve mainly been focused on generating “simple” subtests for the relatively straightforward conditions specified in HTML-AAM 4.1, particularly in terms of the absence of potential naming sources. Just fleshing out those alone created 500+ subtests. 🤯 And I’m quite certain I’ve even missed some HTML elements as it is.

PS. can you use a href in the parent params, or would it need to be an unlinked anchor? Same question on img with an input type=button parent.

I’m afraid not, currently — same answer as above. But I’d like to add that! I’d like to go even more deeply into interesting subtree-sensitive permutations like a[href][title] > img, but maybe that could be a 2.0?

[cookiecrook]

Fair enough. This suggestion is still reasonable though, right?

After a shorter example source (e.g. "from title" only), it may be good to show the rendered DOM element(s) that will be generated from that source. E.g. img with parent a href using 'from title`

[adampage]

Yes, certainly! I’ve added an unnamed image to have something visible to render in tests that would otherwise be completely invisible. Here’s a screen cap of how that appears locally in Safari:

[cookiecrook]

follow-up comments interspersed

prior requested changes have been made

[scottaohara]

re-reading the PR, i'm worried that one of the intended updates was not clear, as i don't see it represented in these tests (unless i missed it - i'm just reviewing the tests via github diff right now)

but for the hidden caption/legend examples, i would have liked there to be another instance where there was a hidden instance, and then a second instance that should then name the table/fieldset.

e.g.,

<table>
  <caption hidden>not the name</caption>
  <caption>is the name</caption>  <!-- this SHOULD be the name now -->
  <!-- rest of the table stuff goes here -->
</table>

right now, i wouldn't be surprised if this fails in some/all browsers, so per @cookiecrook's prior comment, maybe this needs to just be a second PR.

[adampage]

Thanks, @scottohara. I’ve added two new subtests for that case in the static hidden-names.html test file. As you suspected, the browser results are interesting.

In my auto-generated subtests for table/caption and fieldset/legend, I also test HTML-AAM’s clause about using “the subtree of the first such element”. All 3 browsers do pass for both the fieldset and the table.

[cookiecrook]

Maybe just rename the hidden-names file to hidden-names-tentative?