WordPress Admin Menu Accessibility Plugin Version 0.1 - Apr 26th, 2012
This post focusses on a WordPress plugin that I've created that takes some small steps to help with the accessibility of the WordPress admin screens.
Text for Screen Readers Only (Updated)
Published: | 13 Comments
Reading Time: 3 minutes
Update note
** Please Note ** This blog post was originally published in December 2009, and the stylesheet (CSS) technique I recommended at the time moved the screen reader text off the page to the left by setting position:absolute; and left:-9999px;
That original definition still works for sites using left-to-right (LTR) languages, but is not compatible with right-to-left (RTL) languages – e.g. Hebrew, Arabic, etc. Recent testing on mobile Android devices using the Talkback screen reader has also shown that the original technique can lead to certain screen reader text elements in pages not being interpreted correctly, or not functioning correctly.
A better definition presented here is compatible with languages in both directions – LTR and RTL, and works better for screen readers on mobile devices.
Why screen reader text?
Blind visitors to your site may well be using a screen reader, or a braille reader. If your site is constructed well and follows the published accessibility guidelines, your site should not present too many problems for these users.
However, there are a number of places on a web page where extra text could be useful for blind users to ensure that the full meaning of the content is apparent. Some examples include:
- Providing more context for link text, or letting people know that links open in a new window.
- Headings for navigation areas or search boxes.
- Special instructions for form input fields – radio buttons maybe.
- Abbreviated words in calendars – eg M T W Th F
Site designers or owners may not like all this extra helpful text being visible on the page, so step forward a technique for effectively hiding the text from sighted users, but at the same time allowing it to be accessed by screen reader users.
A stylesheet technique
This technique uses stylesheet declarations to hide the text from sighted users, but keep it accessible to screen reader users.
Firstly set up a class in your CSS file with the following declaration. You don’t have to call it ‘screen-reader-text’ – use whatever you like.
.screen-reader-text {
border:0;
clip: rect(1px, 1px, 1px, 1px);
clip-path: inset(50%);
height: 1px;
margin: -1px;
width: 1px;
overflow: hidden;
position: absolute !important;
word-wrap:normal !important;
}
Don’t be tempted to use the display:none or visibility:hidden declarations in your stylesheet for this sort of text as screen readers will ignore it, thus defeating your attempt to be helpful to your users.
In your HTML you can then attach this class to whatever text you want to hide. Here are some examples:
Adding context for a ‘Read more’ link in a list of blog posts:
<a href="/my-latest-blog-post/"> <span class="screen-reader-text">My Latest Blog Post: </span> Read more...</a>
Informing screen reader users that a link opens a new window:
<a href="destination.html" target="_blank"> Link destination <span class="screen-reader-text"> opens new window</span></a>
Adding a hidden heading just before the main site navigation:
<h2 class="screen-reader-text">Main Navigation</h2><ul>...
Clarifying abbreviations (original technique):
...<th>Mon<span class="screen-reader-text">day</span></th>...
Note that in the last example which might be found in a calendar or date picker, I’ve split the day names to make some of each word visible and the rest invisible.
Update April 2017: Having tried this in mobile screen readers (such as Voiceover and Talkback) this technique is no longer recommended as the span element will be treated as a separate focusable element by the screen readers. This results in an obscured meaning for the word in mobile screen readers.
A better technique for amplifying abbtreviations:
... <th><span aria-hidden="true">Mon</span> <span class="screen-reader-text">Monday</span></th> ...
This technique uses a span with aria-hidden set to true to present the abbreviated day name, and a full day name contained within a span that is screen reader text. Anything with aria-hidden set to true will be hidden from assistive technologies but will still be visible.
The end result is that sighted users see the abbreviated form, but users of assistive technologies can access the full form.
Used by WordPress
This screen reader text CSS definition is the one currently used within WordPress default themes and many of the accessibility-ready themes in the WordPress theme repository.
If you are using WordPress on your site, and your current theme does not support screen-reader-text, you could try using the screen-reader-text theme support plugin to add it in.
If you are building your own WordPress theme you can include the definition yourself in your theme’s stylesheet.
What happens if CSS is not available?
Obviously, if the pages of your site are ever seen without the stylesheet being available, all the extra screen reader text will become visible. However, if that happens, it’s likely that your pages are going to look quite different anyway, and the extra text shouldn’t detract from the meaning of the page.
Built in HTML accessibility
Some HTML page elements feature help for screen reader users ‘out of the box’. For example, HTML tables have a <caption> element in which you can place an explanation of what the table shows. Also, foreground images in a page have an alt attribute (commonly known as alt text) which should be used to describe what the image shows if it relevant. See Alternate Text for Images for some hints and tips on how to add meaning to your images and photos.
Other posts take a look at these oft-overlooked accessibility features in more detail.
Ready for more accessibility? Try this
Share this page (Links open new windows/tabs)
13 Responses to “Text for Screen Readers Only (Updated)”
Like to leave a comment?
Please note: All comments are moderated before they will appear on this site.
Previous post: How to Find an Accessible WordPress Theme
Next post: Instagram Accessibility Reduced by New Design
Very useful – many thanks!
You’re welcome.
I got here from watching your YouTube video on WordPress accessibility. Very useful tips. Thanks!
I want screen readers to ignore the below text written after p tag.
E.g:
Monday 16th February, Available
Monday
16
February
Which types or brands of screen readers are compatible with the use of “screen-reader-text” class? I tried some as the narrator of Windows 10, the JAWS and NVDA and do not read the texts associated with the “screen-reader-text” class.
Thank you very much
Thanks for the comment Alberto.
As far as I’m aware, all screen readers should be able to interpret screen-reader-text class. It’s a widely used technique for that reason. I’ve certainly tested it with JAWS and NVDA.
Currently this site still uses the old CSS definition for screen reader text (it will be changed soon), and there is a hidden heading level 2 of “Main Navigation” just above the site navigation in the sidebar. Can your screen readers access that?
Will this also be hidden from bots trying to fill out a form?
Hi Jim, thanks for your question.
The screen reader text is hidden from sighted users only by making it appear in a very small space using CSS. I would therefore imagine that the screen reader text will be readily accessible to most bots when they are filling out a form.
It’s possible that if the text was hidden using
display:none;some bots would not be able to access it – if they took the site’s CSS into account.Has anyone else got a view on that?
This approach has a problem, the text will be seen thus indexed by search engines.
Hi Andrea, thanks for your comment.
In most cases the ‘screen reader text’ will be providing context for a link or some other element, or maybe a hidden heading indicating where some navigation is, or a collection of widgets in a sidebar. I don’t see why it would be a problem that search engines could ‘see’ that. I would have thought that providing extra context would be beneficial to the search engine indexing of a page.
But maybe there’s something I’m missing, so please could you explain your concerns further. Thanks.
Do you have a solution that does not rely on absolute positioning?
My site is getting dinged by the ADA checker SortSite (by Powermapper) for using absolute positioning.
“Absolute CSS positioning can make pages unreadable when style sheets are turned off.”
I’m afraid not. The technique I’ve outlined here is (I believe) the de facto standard. Obviously the absolute positioning is used to avoid the ‘hidden’ content interfering with the visible content. I haven’t tried using it without the
position:absolute, but it’d be interesting to see what happened.The situation with SortSite is a product of all automated testing tools – the fact that it’s impossible for any tools to accurately cover of everything. The irony here is that if CSS was disabled, the screen reader text would become visible and give perhaps a more complete picture for everyone.
Whilst trying to create an accessible questionnaire the radio buttons and star options do not permit you to arrow up and down to make selection without jumping to next question how do I make it stay on the question that needs answered