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.

[LukaszJaro]

I ran into accessibility issues with generic link text(WCAG 2.0 - 2.4.4 Link Purpose) but WP had no solution for this so here's what I came up with with the help of a accessibility expert.

I created a custom screen reader format and applied the WP recommended screen-reader-text class https://make.wordpress.org/accessibility/handbook/markup/the-css-class-screen-reader-text/#practical-examples

The link shows an code example:

<a href="your-url">Read more<span class="screen-reader-text"> about cute kittens</span></a>

Visually in the editor I used smaller font-size with clipped border to distinguish the screen reader text, I tried to limit the visual impact in the editor since it's technically hidden text:

This Australia link explains six options for adding screen reader text for reference:

https://www.visionaustralia.org/services/digital-access/blog/how-to-make-read-more-links-accessible

Maybe if WP implemented something like this they could also scan the page and check for common generic text like read more, view all, see all, etc.,

Gutenberg is too powerful to let something like this slide!

[NicktheGeek]

@LukaszJaro I ended up creating this functionality as a plugin http://wordpress.org/plugins/screen-reader-text-format/

Though I still feel it should be part of core if strikethrough and other text formats that may be relevant to screen reader users are part of core.

[LukaszJaro]

@NicktheGeek I like it! The way it doesn't impact the visual layout unless you click on the block is smart.

I would also suggest using default WordPress class for screen reader text to not clutter the CSS or maybe a option to disable the style and use theme instead.

I think the reason it should be part of the core is it will reach a wider audience where they can be educated on this issue.

[NicktheGeek]

It's using a prefixed method for two reasons

1. I've been burned by other plugins and themes overriding core WP classes to do it "their way" and breaking my usage in other plugins previously.
2. In the editor I need to be able to reveal this formatting and don't want to reveal other screen reader only content that isn't editable such as controls or icons that might be in the content.

I fully agree it should be in core and then the classes could be revisited.

[stephensabatini]

Thank you everyone for putting this together. Seconding this idea or at the very least a solution to this in core. There are so many scenarios where it makes sense to have this. Learn more [about subject], Read more [about subject], Buy [product name for $X], whatever the context. If we're worried about non-tech-savvy people getting the hang of this or abusing this - maybe it is an option that is enabled in the theme.json by the theme developers? It would give us the ability to deliver more accessible information to our end users in a controlled fashion. Just thinking out loud here. I'd personally love the opportunity to explain this feature to the businesses I work with. In the meantime, I've started using the plugin you put together @NicktheGeek. Thank you for your contributions. This saves me for now.

[amberhinds]

@NicktheGeek - have you thought about opening a PR to submit this to core? I spoke with @ndiego about this at WordCamp Canada and he seemed to think that it might get approved.

[alexstine]

@NicktheGeek If you do try to PR this, you'll have my vote. Just as long as we figure out a super clear way to tell sighted people how this should be used. My only other concern would be this.

https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html

At this level, the recommendation is to place the visible text at the beginning. Not sure if hidden text would throw off voice commands like accessible name computation, haven't looked into that.

[joedolson]

Hidden text can throw off voice command, but as long as the visible text is first, it's generally an OK compromise. But voice command tools work in a wide variety of ways, and they don't all work with hidden text. Voice Control on MacOS and iOS, for example, does not support visually hidden text; they only activate if you speak the full accessible name of the link.

Eric Bailey has a good article on voice control usability with partially hidden links.

[joedolson]

Note: that app does, however, also offer an option to view the full accessible names of links; so that's not necessarily a barrier.

[alexstine]

@joedolson I also find it odd how Eric mentions that using aria-label is a failure of WCAG 2.1 label in name. I don't believe that is correct. WCAG does not prevent you from doing this, it is simply the right thing to do.

https://www.w3.org/WAI/WCAG22/Techniques/general/G208.html

It also further recommends to have the visual text in the beginning of the accessible name but does not require it.

In the future, the beginning requirement may go into effect but as of today, it appears not.

[joedolson]

@alexstine Eric doesn't actually say that aria-label is a failure of WCAG 2.1 Label in Name; what he says is that it may be a failure. It's rather unclear, because the example he uses actually is not a failure, and he doesn't provide an accessible where it is a failure. The risk is that unseen text may become out of sync with the visible text, resulting in a label in name failure - that's happened in Gutenberg on many occasions, in fact, and it's definitely been a frustration with just how much aria-label is used when it isn't really needed.

It's definitely not one of the clearest articulations of a point ever, but what he says is technically accurate.

[alexstine]

@joedolson I agree, it is frustrating. Even WCAG label in name though considers this valid.

<button type="button" aria-label="Open Google">Google</button>

Label in name states that the visual label must appear in the accessible name, it is only a recommendation, not a must, to put it at the start. WCAG is a flaky minimum standard.

I always encourage the visual text at the beginning of the accessible name if one chooses to use aria-label.

Nice catch on the article, I must have read through too quickly. 👍

[amberhinds]

I think the potential for issues with the aria-label is a really good argument for having Nick's screen reader text format in core. When I have seen aria-label settings fields in plugins it is frequently buried in an advanced tab that users can miss updating when they change the link. The screen reader text format makes it impossible for users to miss that when they edit links because it surfaces the text very clearly in the editor.

Links are not the only place where this is useful however. It's especially useful in tables where you only want visible icons, for example.

On Thu, Aug 15, 2024, 10:31 PM Alex Stine @.***> wrote:

@joedolson https://github.com/joedolson I agree, it is frustrating. Even WCAG label in name though considers this valid.

Google

Label in name states that the visual label must appear in the accessible name, it is only a recommendation, not a must, to put it at the start. WCAG is a flaky minimum standard.

I always encourage the visual text at the beginning of the accessible name if one chooses to use aria-label.

Nice catch on the article, I must have read through too quickly. 👍

— Reply to this email directly, view it on GitHub https://github.com/WordPress/gutenberg/issues/22332#issuecomment-2292665651, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADELJMDRMDYTNJ4JHW4XHELZRVXCJAVCNFSM6AAAAABMPNLW5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJSGY3DKNRVGE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[afercia]

Hidden text can throw off voice command, but as long as the visible text is first, it's generally an OK compromise. But voice command tools work in a wide variety of ways, and they don't all work with hidden text. Voice Control on MacOS and iOS, for example, does not support visually hidden text; they only activate if you speak the full accessible name of the link.

This is my experience as well when testing with speech recognition. Theoretically, speech recognition software should understand an accessible name when issuing a voice command with only the initial words of the accessible name. Actually, they don't work and only work when issuing the full accessible name.

As such, providing an accessible name that mismatches the visible text, either via screen-reader-text or aria-label/labelledby is dangerous for authors and developers that don't know very well what they are doing. The actual risk is to introduce barriers for speech recognition users. They do have workarounds e.g. by using the overlay grid or the control numbers most speech recognition software provide but still a direct voice command won't work.

Personally, I changed my mint on many things we as Accessibility team we did in the past to expand the accessible names via aria-label or screen-reader-text to provide more context to screen reader users. That works for screen readers. It doesn't work well for speech recognition. As accessibility specialists, we shouldn't optimize for one specific assistive technology. My current take on this is to just avoid to make the visible text mismatch the accessible name.

Given the above, I still think providing this feature to final users is dangerous and can be easily misused, thus making more harm than good.

[alexstine]

@afercia I think the overarching problem is WCAG in any version does not have a solid way to handle these cases. Sometimes visible text is simply not enough for screen readers but giving it detail will break voice control. Where do we find the happy medium? I would love to see this get addressed in WCAG 3.0 or else the pattern everyone knows likely won't change. The real solution is for better design but I just don't ever see it happening. Many like to talk about accessibility, few like to make the compromises to implement accessibility for all.

[afercia]

@alexstine yes better design would help. Given the current state of speech recognition / voice control software, the WCAG Label in Name is de facto failing. I would love to see assistive technology software support voice comamnds with partial accessible names but I'm not sure that will ever happen. So far, the only solution I can think of it to not alter the accessible name ever and make it always match the visible text. Further context can be provided via the accessible description, with all the limitations we are aware of.

[alexstine]

@afercia All that becomes much easier if screen readers would adopt full support for aria-description. I don't understand why assistive tech takes ages to implement new ARIA attributes, same for browsers.

Label in name for sure needs to be tightened up. Right now, it supports the current thinking in the accessibility industry. I might go see if I can find the WCAG 3.0 work and check for conversations around this.

[joedolson]

I think this needs some assessment of actual voice command tools, how they work, and how available features like tagged, gridded, or enumerated commands are; as well as some comments from full time voice command users.

While it's true that many tools don't accept partial strings as commands, it's also true that many tools provide alternate paths to uniquely identify controls, either by exposing their full accessible names or by tagging each control with a unique string/number that can be spotted.

For example:

LipSurf has a tag command that marks all controls on the page with a unique letter combination, so that any control can be accessed in a single command.

Dragon has a 'Show links' command and a 'Click [field type]' command that triggers numbers to display by items of that type, providing the same option.

iOS Voice Command has 'Show numbers' to label actionable items with numbers and 'Show grid' to target specific areas.

Android Voice Access has 'Show numbers' and 'Show labels' that can be used to uniquely identify a control

So even though it's true that hidden text can pose problems, this doesn't seem like it's that dangerous to me given the current state of voice command tools. Yes, there are a lot of low-quality voice command tools that don't offer this support; but that's true in every area of software.

[afercia]

it is certainly true voice control users can workaround by using features like Show numbers and Show grid, which I mentioned in a previous comment. However, we're discussing whether providing the ability to add screen reader text to final users, who may be non-accessibility savvy, is wise or not. To e, that would be extremely dangerous as some users would inevitably end up using the screen reader text for extraneous content like descriptions or help text. As such, the accessible name would likely end up being totally confusing.