Re: [csswg-drafts] For the Accessibility API visibility:visible within visibility:hidden is problematic (#6123)

I don't feel like it is conceptually all that complicated. The real problem, in my mind, is that AT apparently treats `visibility: hidden` and `display: none` as though they mean the same thing, when they were never meant to be in CSS. 

With `display: none`, it effectively removes the element from the tree (the render tree and a11y tree), thereby also removing all its descendent branches with it. 

But `visibility: hidden` isn't supposed to do that. It is only making that one element or pseudo-element (including its text nodes) completely transparent, without affecting descendant elements except through inheritance. It still abides in the render tree, and should also still abide in the a11y tree. So, in my mind, the equivalent for screen readers is that it shouldn't be read aloud, but it should still maintain its meaning and structure and place in the tree. It should still directly traversable. And, because it is still tree-abiding, it should also be available for giving meaning to related table structures, or to providing labels through `for` and `aria-lablelledby`, or to providing description via `aria-describedby`. If the element had no visible descendants and no descendants that acted as labels or table headers, etc., then it could be treated the same as `display: none` or `aria-hidden="true"`, because only then is the element and its descendants both empty and meaningless.

Is that not a reasonable way to look at it?

-- 
GitHub Notification of comment by bradkemper
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6123#issuecomment-917869098 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 13 September 2021 06:05:49 UTC