Gutenberg: Add screen reader only text format

[NicktheGeek]

Is your feature request related to a problem? Please describe.
There are many times where it is preferable to have some screen reader text.

Example 1:
Buttons with generic text are often used and this can be a really poor user experience for screen readers. Imagine building a product/price table for 3 product. Visually it is really clear because each column has the product name, then a list of features, and finally a "Buy Now!" button. For sighted users it is clear what the button goes with, but when using a screen reader the button/link is read without context most of the time. Getting 3 "buy now" links will cause confusion and requires a user to enter a reading mode that can be cumbersome in order to get any sense of what is being "bought."

The solution is to add screen reader text, so the result becomes "Buy {sr-only: Product Name} Now." This provides a key context on the link making it much more accessible.

Example 2:
Similarly, using text formats like "strike" have no meaning in a screen reader. This means adding a price like <strike>$100</strike>$75 will read like $100$75 in a screen reader. It makes no sense to the user. Instead the screen reader only text could be inserted <span class="screen-reader-text">Was </span><strike>$100</strike><span class="screen-reader-text"> Now </span>$75. This is much more clear for screen readers while maintaining the simple visual style. (note: strike is not semantic for HTML5 and instead a class should be used but the same applies with a class).

Describe the solution you'd like
Ideally a text format to allow adding a screen reader only text can be applied making it easy to mark up content for screen readers.

I've done this for a project and can do a PR to add this functionality. There are some things to consider like the icon I've selected and some enhancements we are working on to make it more clear where screen reader text exists for visual editors, but this is working and seems to solve the issues outlined above.

Noted in the screen shot above: this is a third use, though with the same strike approach as the second example. In this case the screen reader would read the feature in the list as if it were included with that product. The screen reader text makes it clear it is not included, reducing confusion.

Additionally, the "buy now" buttons also have screen reader text. It is not showing because the button does not have the .is-selected class. This helps show what the button will look like on page except when it is being edited.

Describe alternatives you've considered
I did consider using aria-label but as the various use cases were explored, this approach made the most sense.

[enriquesanchez]

Hi @NicktheGeek,

I'm going to add this issue to the accessibility team meeting agenda so we can discuss it this coming Friday. It'll be great if you can join us too! We meet every Friday at 15:00 UTC in the Slack #accessibility channel.

[NicktheGeek]

This was discussed in the weekly #accessibility chat on 2020-05-22.

As I perceived it, the conversation (full text to follow) was generally positive. There was a request for more use cases and need for documentation was expressed. There was also concern on potential to abuse with some examples on how things might be done wrong.

Full text:

nrqsnchz 11:56 AM
Next one is an issue by @nickthegeek: Add screen reader only text format (edited)

afercia:flag-it: 11:57 AM
My only concern is potential abuse from content authors.

nrqsnchz 11:57 AM
It proposes adding a text format option to mark text as screen-reader only (edited)
11:58
is that right, @nickthegeek?

nickthegeek 11:58 AM
@afercia that is my biggest concern as well. However, I feel the lack of ability to do this right is worse than potential for abuse
11:58
@nrqsnchz yes, that is right

afercia:flag-it: 11:59 AM
@nickthegeek yeah I read your previous comments and got your concerns. Thanks so much for your work on this :slightly_smiling_face:

nrqsnchz 12:00 PM
I’m also concerned about abuse or misuse

joedolson 12:01 PM
Can you elaborate on how you see this being abused? I think it would be good to have those concerns documented, even if we ultimately choose to incorporate the feature.

nickthegeek 12:01 PM
Same way people keyword stuff alt tags.

joedolson 12:01 PM
Got it.

alexstine 12:01 PM
I think it needs to be made clear by selecting all and using this screen reader only text button, this will not make every page of your website accessible. Would really need good documentation to explain how and when to use this feature. E.g. in links (opens in new window/tab).

afercia:flag-it: 12:02 PM
@joedolson Hiding text is always a remediation to accommodate design. We need to consider all users with accessibility needs, not just screen reader users. For example, hiding text, when done the wrong way, may be potentially impactful for speech recognition software users.

joedolson 12:04 PM
Indeed; but this is similar to alt text, in that having a systematic way for that text to be exposed to the editor is important. I do feel that the use cases where screen reader text should be manually added within content are very slight.
12:06
I saw @nickthegeek's use case, but I struggle to come up with many other viable use cases.
:+1:
1

alexstine 12:06 PM
I can certainly see the use case for it, but with anything else in accessibility, there's always the + and the - side to look at. If used correctly, I believe it could make some websites a lot more descriptive especially in links. As ALT Text is though, it's a feature that relies on end-publishers best judgement.
:+1:
1

joedolson 12:08 PM
One thing I can imagine happening with this would be editors creating a lot of link text like "click here to visit out page" and using screen reader text to explain the link, which would be...icky.
12:08
So, yes - it has positives and negatives.

nickthegeek 12:08 PM
@joedolson the main other use case is when <s> is used. Almost 100% of the time it needs accompanying screen reader text to clarify since it isn't "read"

joedolson 12:09 PM
I assume it would still depend on front-end support for the class? Or does it add screen-reader-text styles to the block editor styles? If so, it could create problems for themes that have explicitly decided not to hide screen reader text.

afercia:flag-it: 12:09 PM
More use cases would help giving a well informed feedback.
That said, we hit the hour and I need to run. I’d like to mention one thing to add to next meeting agenda though. It’s something @alexstine reminded me and it’s some important Gutenberg accessibility feature aren’t well documented, to be fair. For example Alex didn’t know the ability to switch between Navigation and Edit mode existed :slightly_smiling_face:
We should discuss this point a bit more in depth, I guess.
Bye all! (edited)
:+1:
1

nickthegeek 12:09 PM
in my current iteration it gets it's own class. I did that because I want to easily show it when it is in focus on the editor.

alexstine 12:11 PM
"One thing I can imagine happening with this would be editors creating a lot of link text like "click here to visit out page" and using screen reader text to explain the link, which would be...icky."
Sites already do this though, the flip side is this feature would at least allow screen readers to maybe have a clue. Content creators love short link text, I see it everywhere.
For sure, both sides to every feature.
:point_up::skin-tone-2:
1

12:12
@afercia Agreed, would like to discuss that further in a future meeting.

joedolson 12:13 PM
Overall, I think I see it as a positive tool - something that enables an end user to add screen reader support that they can't currently do. It has potential for abuse, but that's true of every tool, so it ends up coming back to education needs on how to use it.
:+1:
1

nrqsnchz 12:13 PM
Unfortunately, time has caught up with us and we need to end the meeting. But would anyone be able to help move all of this feedback to the issue? And for those interested in continuing the conversation, please do. This channel is open 24/7 :smile:
Thank you all for coming, please remember you can help by reviewing and providing feedback on the tickets and issues that were shared today.
We couldn’t get to the other two items suggested in the agenda comments, apologies @tellthemachines and @afercia. They are already considered for next week’s agenda. In any case, if anyone has a chance to help with those as well, please do.
:thanks:
2

joedolson 12:13 PM
I think I lean more in the direction that we should provide tools without judgement on how they will be used.

nickthegeek 12:13 PM
@alexstine I'm super on the fence with that. I'm working on training clients to do links right and I'd rather them do good link text than to use a screen reader hack. But, like you said even if it is not an ideal scenerio, having someone use screen reader text in a "click here" link is preferable (but "icky") to just "click here."
So it's an improvement, but not something I'd want to document.
12:14
@nrqsnchz I'll take ownership on the issue and move conversation over.

[gziolo]

There is VisuallyHidden component already that is used to include text that can be used by screen readers to add additional context but it isn’t visible on the display. Can you explain how would it differ from the solution proposed here?

[NicktheGeek]

@qziolo three things.
1) that component is not accessible available (changed because accessible in the current context might be confused with a11y) to end users.
2) that isn't helpful for inline text, which is where this is needed
3) that component renders visually hidden unless it is specifically in focus, which makes it unusable for sighted users setting up the content who will need to see the content that is hidden in order to edit it. With the solution I'm proposing, when the component is active any screen reader text will be visible and highlighted. For example, if working on a list that has <s> on an item, when the list is active the screen reader text explaining that item is "Not included" will be visible in the editor.

[sabernhardt]

I'd like the inline screen reader text to be viewable and editable in the post editor, for anyone who already understands the value of using the class as well as the benefits of trying to improve the visible text instead.

@samikeijonen mentioned adding support with a plugin, which would almost require users to have some knowledge of how/when/if it should be used.

If the button belongs within the standard dropdown (without installing a plugin), maybe the button could show depending on whether the user specifically selected an option to enable it. That checkbox might work in the Options menu, unchecked by default (and there could be a better place for that).

@NicktheGeek already mentioned displaying the extra text visually in the editor. It would be good to set it apart somehow (80-90% opacity? a better way?).

[NicktheGeek]

@sabernhardt We are doing an outline and adding an asterisk and hover text. I'll add a couple screen shots showing how that looks. We considered doing opacity but there were concerns on how that might affect contrast in various settings and it could potentially end up matching muted text in some settings. This approach might be a bit aggressive, but something similar is likely the best way to highlight it in all use cases so it is fully accessible.

[sabernhardt]

@NicktheGeek Yes, that styling is much better than changing the opacity. Would the asterisk work before the text instead of above (to avoid any overlap)?

[NicktheGeek]

@sabernhardt yes, it could work before the text. The nice thing with the asterisk, for a11y, is it doesn't cause this to rely on just red outline, which may not be visible in some circumstances such as on a red background, or distinguishable for color blind users on a wider variety of backgrounds, but location is less of an issue so long as it is present.