[csswg-drafts] [A11Y proposal]: assistance property (#7504)

brechtDR has just created a new issue for https://github.com/w3c/csswg-drafts:

== [A11Y proposal]: assistance property ==
# 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:

```
.sr-only {
    assistance: sr-only; //or fully screen-reader-only ?
}
```

The first options that come to mind are the following:

```
assistance: sr-only;
assistance: sr-hidden;
assistance: only-focus;
```

## 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:

```
.sr-only:not(:focus):not(:active) {
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  width: 1px;
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
}
```

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:

```
.skip-link {
  position: absolute;
  left: 50%;
  background: #000;
  color: #fff;
  transform: translateY(-100%);
}

.skip-link:focus-within {
  transform: translateY(0%);
}
```

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.


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7504 using your GitHub account


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

Received on Friday, 15 July 2022 09:56:52 UTC