- From: Martijn Saly via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Aug 2022 15:21:08 +0000
- To: public-css-archive@w3.org
Assuming `sr` is an abbreviation of `screen reader`, it's important to remember that screen reader is not the only kind of software that needs to be able to "read" a website to a user, and to skip certain elements. I'm sure there are more, but the one thing I can come up with right now, is a braille bar, most likely used by deafblind people and people with similar/related conditions. But before that, don't we remember aria-attributes? I think it's much nicer if we replicate them into CSS. This would also make it easier to calculate precedence between, say `aria-hidden` or `role=presentation`, and a CSS rule like `assistance: sr-hidden` or as I would propose it, `aria-hidden: true; role: presentation` (whichever is most applicable). `sr-only` could be replaced by something like `display: none; aria-hidden: false` where false` would explicitly un-hide it from the accessibility tree. `focus-only` - not sure what to make of this one. It seems it has little to do with assistive tech. You want to be able to focus an element within a hidden parent. I'm sure there's a more generic CSS solution we can think of, to solve this problem more elegantly, without it being about assistive tech. For example, we could reason that elements within a `visibility: hidden` element are always focusable. That leaves us with no extra properties, just some slightly different behaviour (and might I add, this seems more logical). -- GitHub Notification of comment by thany Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7504#issuecomment-1204099866 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 August 2022 15:21:10 UTC