-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add screen reader only text format #22332
Comments
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. |
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 afercia:flag-it: 11:57 AM nrqsnchz 11:57 AM nickthegeek 11:58 AM afercia:flag-it: 11:59 AM nrqsnchz 12:00 PM joedolson 12:01 PM nickthegeek 12:01 PM joedolson 12:01 PM alexstine 12:01 PM afercia:flag-it: 12:02 PM joedolson 12:04 PM alexstine 12:06 PM joedolson 12:08 PM nickthegeek 12:08 PM joedolson 12:09 PM afercia:flag-it: 12:09 PM nickthegeek 12:09 PM alexstine 12:11 PM 12:12 joedolson 12:13 PM nrqsnchz 12:13 PM joedolson 12:13 PM nickthegeek 12:13 PM |
There is |
@qziolo three things.
|
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?). |
@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. |
@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)? |
@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. |
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:
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! |
@LukaszJaro I ended up creating this functionality as a plugin 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. |
@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. |
It's using a prefixed method for two reasons
I fully agree it should be in core and then the classes could be revisited. |
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. |
@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. |
@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. |
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. |
Note: that app does, however, also offer an option to view the full accessible names of links; so that's not necessarily a barrier. |
@joedolson I also find it odd how Eric mentions that using 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. |
@alexstine Eric doesn't actually say that It's definitely not one of the clearest articulations of a point ever, but what he says is technically accurate. |
@joedolson I agree, it is frustrating. Even WCAG label in name though considers this valid.
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 Nice catch on the article, I must have read through too quickly. 👍 |
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.
<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. 👍
—
Reply to this email directly, view it on GitHub
<#22332 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADELJMDRMDYTNJ4JHW4XHELZRVXCJAVCNFSM6AAAAABMPNLW5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJSGY3DKNRVGE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
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. |
@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. |
@alexstine yes better design would help. |
@afercia All that becomes much easier if screen readers would adopt full support for 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. |
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 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. |
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. |
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.
The text was updated successfully, but these errors were encountered: