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

> they are very different semantically. display: contents is a very clear message: this is semantically relevant but not visually relevant. In contrast, visibility: hidden is often used to hide entire parts of a page visually, so it is not necessarily saying "this is semantically relevant".

I would say that there can still be probably more similarity than fundamental difference between these situations. Authors (at least those who care about semantics) don't often use CSS only to mark parts of content "semantically not relevant". In my opinion, the true message behind `display: contents` is usually "this particular thing may be not visually relevant, but its children _definitely_ are"; the message behind making a thing not visible while _still being part of layout_ and probably having visible descendants sounds more like "this particular thing may be not visually relevant (now), but some of its descendants _probably_ are". If an educated author's intent is to mark the entire piece of the page as both visually and semantic not relevant, they would likely use `display:hidden` or the HTML `hidden` attribute instead.

That said, I agree that accurate repesentation of this implied message is difficult. Moreover, difficuilties can be different in these cases related to different layout limitation. For example, a table with `visibility: hidden` that has several `visibility: visible` cells still looks much like a table (though some its cells are missing), so, as an AT user, _ideally_ I would like it to be presented like "Table, N rows, M columns, only X cells are visible. Row A, column B: ..." and so on, and also would like to be able to navigate between visible cells using table navigation keys the same way as it happens in the table with some cells merged (I don't really expect it to be ever implemented that way, it's just my dream behavior 😀). In contrast, if the rows of the table have `display: contens` and their cells are displayed as a single row, it would likely be better to present them as a single row in the A11Y tree (and I'm not sure if it's possible without "fixing" the A11Y tree with "virtual" `role="row"` wrappers similarly to how CSS "fixes" the layout tree with anonymous boxes).

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


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

Received on Tuesday, 14 September 2021 22:40:22 UTC