Proposal: Responsive screen-reader utility classes

[Josh68]

What

Propose the DS adds responsive variations of the screen-reader utility class
This may add a little bloat to the CSS output - it cannot use a placeholder or @extends syntax, but can work with a mixin and @include
The declaration block could be defined as a mixin and used inside this breakpoint loop

Why

Explain why you think this should be added to the Design System.

• In MCT, we have scenarios where we want to hide content, usually at lower breakpoints, but keep exposed to screen readers

[pwolfert]

This brings up an interesting design and accessibility topic that @ericwbailey brought up recently. It's a question about whether we should be encouraging designers to hide information at all when that contextual information is actually really helpful to users who aren't even blind. I just wanted to tag that here to start a discussion. I don't want to stand in the way of alleviating a real development need if there is one.

[Josh68]

Been quite a while since I originally wrote this request, but as I re-read it, I would just say that these are scenarios where we already have client-approved visual content at different breakpoints, but it's clear from our analysis that there are areas where screen readers will still benefit from the extra context, and layout constraints are not an issue to a screen-reader. I do understand the other opinion, however.

[ericwbailey]

Yeah, one thing I would be cautious with is zooming/scaling conditionally triggering the presence, or lack of presence of something.

I'm curious: was the responsive screen-reader only use case for more aesthetic information or content?

[Josh68]

In my recollection, this was a case where the design called for more verbose content at wider viewport widths. I don't think I would call it "aesthetic information," but I honestly can't remember the case(s) that prompted me to write this request. AFAIK, zooming/scaling would affect this output, as it does anything we show and hide or change within a pixel-width media query, I believe.

[ericwbailey]

Cool, thanks for the additional context!

Personally, I strive for content parity across all breakpoints for exactly these kinds of concerns. I've seen more decorative content be hidden at smaller breakpoints due to limited screen real estate, but I think that's more an art-direction concern where everyone won't see the image.

The other thing I'm thinking of is braille displays and other non-screen reader assistive technology that utilizes an Accessibility Tree, and what that experience would be like for the user. I think we'd most likely want to do some research there, as it's an area I'm not too experienced with.

[Josh68]

OK, so I've located the case where I applied my own SR-only declaration for mobile, and it was a search filter with an icon and the text "Filter by" on desktop. The spec was to hide the text on mobile. This could have been managed instead with an appropriate aria-label on the icon. So, given the opinions offered here, let's close this discussion. I will instead make a ticket to change the way I implemented that update.