- From: fantasai via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 Sep 2021 18:50:18 +0000
- To: public-css-archive@w3.org
OK, we clarified the note. It now reads: > Note: Currently, many user agents and/or accessibility tools don't correctly implement the accessibility implications of visible elements with semantic relationships to invisible elements, so, for example, making parent elements with special roles (such as table rows) invisible while leaving child elements with special roles (such as table cells) visible can be problematic for users of those tools. Authors should avoid creating these situations until the tooling situation improves. @jcsteh For case 1, no, neither “hello” nor its containing button should be exposed, because they are hidden. For case 2, the presence of the image should imply the presence of its containing button, allowing it to be focused and activated. For case 3, CSS is stateless, so the entire tree is hidden just as if it were originally that way. For case 4, I think this gets even deeper into undefined territory: afaik there isn't a clear mapping spec for the implications of CSS on the accessibility tree (and it's out of scope for css-display), but effects of visibility and aria-hidden should probably combine to hide the entire tree there. And again, the document is stateless so scripting the addition or removal of the attribute should be no different than loading a fresh document in that state. (It may be trickier to implement, though.) Note: All of these should be identical to the same situations with `display: contents`, so the answers should be the same as for that (or are equally undefined currently...) -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6123#issuecomment-912741046 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 3 September 2021 18:50:20 UTC