brechtDR commented 2 years ago

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.

davydepauw commented 2 years ago

I like the idea 👏 To keep it uniform I would use focus-only instead of only-focus:

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

thany commented 2 years ago

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).

bskibinski commented 2 years ago

TLDR: why not just expand the display property: display: invisible and display: sr-none

I also like the idea of adapting aria for CSS. But lets KISS, instead of display: none; aria-hidden: false (it also reads terribly, double/tripple-ish negative)

display could be expanded with display: invisible (not hidden, it's a visual thing). Removing it from the flow/visual rendering like display: none, but keeping the accessibility tree. And perhaps the same for assistance: sr-hidden;: display: sr-none (to keep in line with "display: none") and you could still do display: flex sr-none for instance.

Agree about the focus-only not being needed, that role would come to the new display: invisible/assistence: sr-hidden, it's contents are tabbable (because it's visible to the accessibility tree), so you can do anything you want with the default :focus/:focus-within.

brechtDR commented 2 years ago

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 only-focus or focus-only can be interesting as shown in the example. Or at least a property that hides something from screen-readers but keeps it visible for others.

w3c / csswg-drafts