Handle content-visibility and hidden="until-found"

[Jym77]

Parking as draft for now.
Both content-visibility and hidden="until-found" have poor browser support. This means at least that any test case using them would hit an Accessibility Support problem…

---

• Add content-visibility: hidden to the reasons for being Programmatically Hidden.
• Add a not that hidden: until-found is recommended to be handled via content-visibility: hidden.
• Add inapplicable examples to rules that directly use "Programmatically Hidden".

There are many more rules that indirectly use "Programmatically hidden", because it is mentioned in "Included in the Accessibility tree". And indeed, programmatically hidden elements meet the conditions for being excluded from the Accessibility Tree.

I'm however not sure we need to add examples with these new properties or value on half the ruleset 🤔
OTOH, it may be worth doing it like here with one single Inapplicable Example grouping many cases of exclusion. This does not clutter rules with a lot of extra examples, but still allow to exercice the definition (and it becomes the task of the tool vendors to understand why they fail a given test cases)

Closes issue(s):

• closes Programmatically hidden doesn't handle CSS content-visibility: and hidden=until-found #1860

Need for Call for Review:
This will require a 2 weeks Call for Review (updating a definition with impact in many rules)

---

Pull Request Etiquette

When creating PR:

• Make sure you're requesting to pull a branch (right side) to the develop branch (left side).
• Make sure you do not remove the "How to Review and Approve" section in your pull request description

After creating PR:

• Add yourself (and co-authors) as "Assignees" for PR.
• Add label to indicate if it's a Rule, Definition or Chore.
• Link the PR to any issue it solves. This will be done automatically by referencing the issue at the top of this comment in the indicated place.
• Optionally request feedback from anyone in particular by assigning them as "Reviewers".

When merging a PR:

• Close any issue that the PR resolves. This will happen automatically upon merging if the PR was correctly linked to the issue, e.g. by referencing the issue at the top of this comment.

How to Review And Approve

• Go to the “Files changed” tab
• Here you will have the option to leave comments on different lines.
• Once the review is completed, find the “Review changes” button in the top right, select “Approve” (if you are really confident in the rule) or "Request changes" and click “Submit review”.
• Make sure to also review the proposed Call for Review period. In case of disagreement, the longer period wins.
  f

Change accepted

[WilcoFiers]

This is wrong, an element with content-visibility:hidden is not hidden from the accessibility tree. Its content is, but the element itself isn't. To make this more complicated. Even with content-visibility:hidden, child nodes can (in Chrome) still be used in the accessible name. For example, not only is the following still a button in the accessibility tree, its accessible name is still "Hello world", even though the text isn't visible.

<button style="content-visibility:hidden">
  Hello world
</button>

[dd8]

There are various caveats on implementing content-visibility: to avoid screen reader detection:
https://drafts.csswg.org/css-contain/#cv-a11y

And there is an outstanding issue on this:
w3c/csswg-drafts#5857

It may be worth holding off on this until there's consensus on how AT should implement this.

Edit: The spec seems to suggest that what gets exposed to AT depends on timings of CSS layout. They want to avoid AT detection due to slow layout with AT vs. fast layout without AT. There are definitely big timing differences between Firefox (multi-thread, breadth-first CSS layout written in Rust) and Chrome/WebKit (single thread, depth-first layout written in C++)

[Jym77]

@dd8 Tried to sum up the discussion about auto in an assumption + note in the definition.

changes done

[WilcoFiers]

I think I'd prefer these test cases in different rules. This rule is has been somewhat contested. How about adding the hidden example to Form field has non-empty accessible name, and have the image rule above use hidden="until-found"?

[WilcoFiers]

Until this is better supported I don't think we should add this. This example fails in Firefox and Safari. I think its better to use hidden=until-found here. If you wanted to pass in Chromium you'd still need to support content-visibility, but the example wouldn't be a failure in browsers that don't support it yet. What's also neat specifically about using it in this rule is that there's nothing to be found here, so this couldn't become a visible image through some user action.

Suggested change

	<div style="content-visibility: hidden">
	<img src="/test-assets/shared/w3c-logo.png" />
	</div>
	<div hidden="until-found">
	<img src="/test-assets/shared/w3c-logo.png" />
	</div>

[Jym77]

hidden="until-fonud" also seems to have poor support: MDN browser compatibility.
I guess it's best to just park this until there is better support…

[WilcoFiers]

Not new to the PR, we could open a separate issue, but this is incorrect I think. If you use aria-owns to grab a node that has an ancestor with aria-hidden, that node itself isn't hidden.

[Jym77]

Yes, that's also the conclusion that was reach in this ARIA PR.

I'm recording that in #1991 .

[Jym77]

Looks like both content-visibility and hidden="until-found" have poor browser support for now.
Parking these to revisit later.