-
Notifications
You must be signed in to change notification settings - Fork 659
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[A11Y proposal] assistance property #7504
Comments
I like the idea 👏
|
Assuming 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
|
TLDR: I also like the idea of adapting aria for CSS.
Agree about the focus-only not being needed, that role would come to the new |
Although I like these proposed ideas, I'm not a big fan on expanding the display property for this as well as the term "invisible". It doesn't really seem that simple in combination with the "visibility" and the "display" properties. I actually thought about expanding the display property before submitting this, but it just felt too confusing using the display property. For that matter, i'd rather see aria themed naming instead of this. But I don't believe that CSS should be able to do everything aria attributes can provide. The things i'm suggesting are pure based on the visual context, and for who the visual context is important or can be discarded completely. I do think the |
A11Y proposal: assistance property
This is the first time I submit a proposal, and I hope it can help grow CSS a bit further.
Let me start with the idea, following up with the "why"
Naming things is hard, but if I think about a property name that's scaleable in the future for other assistive technologies, I thought of the name "assistance"
This could look like the following:
The first options that come to mind are the following:
Why this could be interesting
A lot of times, we keep repeating ourselves when it comes to accessibility for assistive technologies. A lot of times we add a
.sr-only
class to our CSS which does the following:This would then become possible with
assistance: sr-only;
This could help provide additional context to screen readers. To take things further, there are times that we don't want something visible on the page, but do want it focusable. This is mainly used with anchor links that can skip the navigation to enter the main content, also known as "skip-links". So we do the following:
This would then become possible with
assistance: only-focus;
So, both of these are already possible with CSS, but with accessibility in mind, I think it's time we made this easy for beginners and give them a dedicated property to handle these kinds of situations. Easy solutions create more implementations and a better web for all.
But there is a third, lesser known problem...
There are times that we don't want assistive technology such as screen readers to read something, but we do want the focus on it.
For example: line-clamping text is used a lot to make text take up less space for design reasons, however, a screen reader does not take this in mind and reads the full text, which in itself is a good thing. Mostly this is followed by a "read more" button, which makes sense for users navigating by keyboard, but doesn't make sense at all for users completely relying on a screen reader.
To further illustrate, this is the moment that it would come in handy: https://codepen.io/utilitybend/pen/GROrzOB
This would then become possible with
assistance: sr-hidden;
Note: I know there are people using screen readers that are not fully blind, which could make this confusing as well, I'm not sure if we can differentiate this. Also, how to handle this with the accessibility tree, should it be kept in it, or not, but still have a focus? Sounds strange, but something to think about.
I don't know much about what is possible in the future of css and what's not, and I'm happy to learn and hear your thoughts on the matter. And once again, naming things is hard, so I'm also happy to hear some thoughts on that.
Thank you for your time in reading this.
The text was updated successfully, but these errors were encountered: