Hiding text for screen readers with WordPress Core

WordPress introduced the class .screen-reader-text in 2009. Since then, it’s been the canonical way that WordPress handles any HTML output that is targeted at screen readers. Introducing new HTML in the admin that uses this class has never been an issue; but adding more hidden text to output into themed content has been an ongoing problem.

Starting with WordPress 4.2, core will be making greater usage of the .screen-reader-text class in front-end code, so theme and plug-in developers need to know how to work with it.

It’s easy to hide text — but the .screen-reader-text class is not about hiding text. It’s about providing text to a targeted audience that’s using a non-visual method to access it. So the simplest methods of hiding text – display: none; and visibility: hidden; aren’t an option. These techniques really do hide the text – from all devices, and all assistive technology.

How to use screen-reader text

The purpose of screen-reader targeted text is to provide additional context for links, document structure, and form fields. Usually, that context is readily available to a sighted user because of visual cues and familiar patterns.

Screen reader text has many specific applications. One common example of this is a link that says “read more”. On its own, this link lacks context in a screen reader. While a sighted visitor can easily identify the context from the surrounding text and images, a screen reader user benefits from including the title of the target in the link:

<a href="{article.permalink}#more">read more<span class="screen-reader-text"> of the title of {article.title}</span></a>

Another use of .screen-reader-text is to hide labels in forms. Search forms are a common place where designers use placeholders and image buttons to convey the purpose of the form. Adding a label that’s available to screen readers make the form usable for screen reader users, without altering the design.

Defining the class

When you define classes for .screen-reader-text, there are two common methods: absolute positioning and clipping.

The clip method is used by WordPress core, and is the preferred method. The ‘clip’ property has been deprecated, but its replacement ‘clip-path’ has poor browser support, so providing both is necessary.
Note: this CSS is updated on October 2017

/* Text meant only for screen readers. */
.screen-reader-text {
  border: 0;
  clip: rect(1px, 1px, 1px, 1px);
  clip-path: inset(50%);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute !important;
  width: 1px;
  word-wrap: normal !important;

The absolute positioning method is simpler, but requires you to provide alternate styles for right-to-left and left-to-right languages:

.screen-reader-text {
    position: absolute !important;
    left: -999em;

It’s common to see the absolute positioning method also using negative positioning on the top margin — this is not recommended. While the arbitrary measurement of -999em is effective almost 100% of the time off the left margin, almost no value will be universally usable off the top margin. Additionally, if any object that can receive focus (such as a link, button, or form input) is positioned off the top of the screen, it will cause the browser to automatically scroll to the top of the window if that element receives focus. This can be disorienting for anybody using a keyboard to navigate the page. It’s also worth noting that the off-left positioning method can have a negative impact on web site performance.

Bring Hidden Text into Focus

In some cases, it’ll be necessary to bring your hidden text into view when it receives keyboard focus. This is relatively rare, and primarily effects Skip links, which need to be made visible for keyboard users. You shouldn’t apply a focus state on most screen reader text; if that text doesn’t need to be seen in order for the context to be understood by a sighted user, don’t make it visible on focus.

If you do need to bring screen reader text into focus, you can use these base styles to move the text into view when using the clip method:

.screen-reader-text:focus {
  background-color: #eee;
  clip: auto !important;
  clip-path: none;
  color: #444;
  display: block;
  font-size: 1em;
  height: auto;
  left: 5px;
  line-height: normal;
  padding: 15px 23px 14px;
  text-decoration: none;
  top: 5px;
  width: auto;
  z-index: 100000; /* Above WP toolbar. */

Using the absolute positioning method, it’s simply a matter of changing the value of the left positioning so that the text is on screen.

#classes, #plugins-2, #screen-reader, #themes-2

Digital Accessibility Centre Visit – Part 3: The Blind Perspective

This is the third post documenting a recent visit to Digital Accessibility Centre in Neath, South Wales organised by fellow team member Siobhan BamberThe first post can be found here, and the second post here.

Three of the staff from DAC gave us feedback on using the WordPress admin screens. Each of the three have a particular impairment, and the visit was a valuable opportunity to learn about ways we could improve WordPress for everyone.

In this post we take feedback from Carly who is totally blind. She showed us how she used a screen reader and gave us some great feedback on using the WordPress admin screens with a screen reader.

Continue reading

#accessibility, #assistive-technology, #feedback, #jaws-admin, #screen-reader, #testing, #trac-2

Site Feedback Request

We have been approached by the folks over at translate.wordpress.org. They are keen to ensure that it is accessible as possible and would like our help to identify any problems with the current site.

So please take a little time, between May 17 & May 31, to have a look at translate.wordpress.org and give us your feedback via comments on this post. In order to support you and provide some structure to the feedback, we’ve prepared a Site Feedback Guide that should help.

We look forward to your contributions.

#feedback, #screen-reader, #testing

Accessibility IRC Chat – 3rd April 2013

A few of us took part in the IRC chat yesterday (see transcript here). Not surprisingly the main subject was the Add Media Panel accessibility, and the format of the chat turned into a live screen reader test on the functionality performed by @_Redd and @arush (and myself).

@lessbloat had kindly had a go at implementing my quick and dirty pragmatic ARIA solution – for which we are truly grateful. Once we’d got access to an environment where the changes were in effect we could see that vast improvements had been made to the accessibility.

I’ll save the detail to the blog post about Add Media Panel but to summarise:

  • Keyboard-only users can now tab through the items in the media list and select/deselect using Enter key
  • Screen reader users were getting some useful information but possibly only the newest versions can fully use this functionality.
  • Voice recognition users can at least use the tab commands to move around the list and select them.

The key decision now is whether the functionality is useful and solid enough to include in 3.6. A couple of extra enhancements would make the solution better for screen reader users – once again see previous post.

My vote would be to run with it if we can get the small further enhancements. We can hopefully address the rest of the accessibility issues within 3.7.  But what do you think?

#accessibility, #add-media, #irc, #keyboard, #media-manager, #screen-reader, #testing

Add Media Panel and WordPress 3.6 – A Simple Solution?

The beta version of WordPress 3.6 is very close now and the chances of significant extra functionality being included must be slim. But, the Add Media Panel introduced in 3.5 is still inaccessible and the trac tickets raised on this are still untouched.

This is a real problem as the Add Media Panel is such a key piece of functionality.

However, from our IRC chat yesterday the germs of a simple solution may have emerged – a solution that could maybe make the functionality accessible to keyboard and screen reader users. We just need someone to give it a try.

Continue reading

#accessibility, #add-media, #images, #irc, #keyboard, #markup, #media-manager, #screen-reader, #ui

Add Media Accessibility Summary

Following up on the original post about the Add Media panel, here’s a quick rundown of the functionality issues with screen readers:

  • Cannot select images from Media Library.
  • Media Library images display in list either without description/title (IE) or only the first image is seen within the list (Firefox).
  • A newly uploaded image can be deselected, but no other images can be selected in addition.
  • Cannot activate the Select Files link to upload image in Internet Explorer. (Works in Firefox.)
  • Form fields lack description; show as “unlabeled” in Internet Explorer.
  • Moving through the media panel can take the user (unknowingly) back into the edit screen.
  • Upon “re-entering” the media panel (see previous bullet point), form fields and links no longer seem to work.

I’m sure there are other things that can be added to this list that I’ve missed. (Feel free to edit this as necessary, @grahamarmfield.) Unfortunately, while compiling this list my JAWS went berserk, giving me a bunch of installation errors and then my computer crashed.

#add-media, #screen-reader

Add Media Panel – Accessibility Issues

I’ve raised this post as I feel that the issue of the Add Media panel accessibility needs some debate amongst the accessibility community.

Last week I raised three WP trac tickets covering my take on the problems from the keyboard access, screen reader and VR aspects. They are: #23560 and #23561.

The main problem as I see it is that it is not possible to select/deselect any of the media without using a mouse.

The functionality primarily acts like a group of checkboxes – selecting one or multiple elements, with feedback that they have been selected. However, that is not how the functionality has actually been implemented – it’s a series of divs contained within an unordered list. There appears to be nothing to receive focus. There are links for each file, but the links appear empty although they are used to show the selected icon. These links are also initially invisible using CSS techniques that hide them from screen readers – hence the no tabbing into the images issue.

Is the use of ARIA going to really be able to help here?

When mouse users select an image they can update the attribute values for that image using the panel to the right – which updates its content automatically. Allowing keyboard users to quickly reach the attributes boxes would obviously be desirable – the alternative being tabbing through all the previously uploaded files.

The media selector panel has been implemented with infinite scrolling, so on mature and/or larger sites with many images/files (I have one) the list of images gets bigger and bigger. From an accessibility perspective I’d favour paging over infinite scrolling, but what’s your take on that?

Is this another area where bending the new functionality to include accessibility might be too much? Is this another place where an accessibility mode is going to be required?

What do you think?

#accessibility, #add-media, #images, #keyboard, #screen-reader