search

mozilla / wg-decisions

A place for Gecko developers to track CSSWG decisions
10 stars 2 forks source link

For the Accessibility API visibility:visible within visibility:hidden is problematic #618

Open mozilla-apprentice opened 3 years ago

mozilla-apprentice commented 3 years ago

A resolution was made for csswg-drafts/#6123.

For the Accessibility API visibility:visible within visibility:hidden is problematic

Discussion.

To file a bug automatically for these resolutions, add the bug label to the issue.

If no bug is needed, the issue can be closed.

dholbert commented 3 years ago

CC @MReschenberg - do you know if the accepted-proposal here matches our existing behavior, or do we need a bug?

the implementation-affecting part of the proposal is:

"Define impact of visibility: hidden similar to display: contents (shouldn't strip necessary a11y information from the tree)."

New text at https://drafts.csswg.org/css-display-3/#visibility (though the "drafts" server is having reliability issues). Relevant snippet of the commit is here: https://github.com/w3c/csswg-drafts/commit/7be289b94ff79ca434d9fec0a107027f38088380#diff-121b43a1fc112b6bdb941630b37e35dba8c25b511fd8a6e9a2e22f5b889d1f20R1185-R1196

My paraphrase/rewording of the new requirement (if I'm understanding it correctly): If a visibility:hidden element (or several such nested elements) have some visibility:visible descendant, then the spec now requires that the hidden element(s) must exist in the accessibility tree, to serve as the container for the visible thing (for proper nesting etc.)

I can imagine that maybe we already do this, but I don't know our a11y code well enough to be sure.

MReschenberg commented 3 years ago

I'm investigating this, I know we do something similar for display:contents right now, but not sure if we're covering this case too. Will let ya know!