- From: Brad Kemper via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Sep 2021 05:56:06 +0000
- To: public-css-archive@w3.org
> Authors (at least those who care about semantics) don't often use CSS only to mark parts of content "semantically not relevant". I mostly agree, except for `display: none`, which is used to completely remove something that is not currently relevant, but may be later, when it is shown by giving it some other display type. For instance an empty dialogue structure that exists as hidden scaffolding, but not part of the layout until it is filled in with content and then shown. On the other hand, there can also be cases like tool tips where they start out as `display: none` until hovered, but could have meaning for AT even when not hovered (`aria-describedby` would work well with those, if that worked when referencing `display: none` elements). > In my opinion, the true message behind `display: contents` is usually "this particular thing may be not visually relevant, but _its children definitely_ are"; Or it's text or picture data content. I guess those are children nodes but not children elements. But yes. > 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". Yes, sometimes, but not always. > 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. I think you meant `display: none`. I would agree. > 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 😀). Yes, that seems like very reasonable behavior, from my perspective. (Disclosure: I am sighted and don't use AT myself except to test my pages for a11y.) > 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). Agreed. That is what I was alluding to earlier when talking about visibility, that some sort of fix up could happen for a11y like it does for CSS. The same sort of fix up should happen if the table row was given some other role, like `role="dialog"`, but the cells still had their cell role. This gets beyond just CSS, but seems like what WCAG and AT and UAs should be working towards, rather than just saying we have to keep it a certain way because it's been that way for decades. -- GitHub Notification of comment by bradkemper Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6123#issuecomment-919722393 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 September 2021 05:56:08 UTC