Updates to WordPress theme accessibility guidelines

The accessibility-ready guidelines for WordPress themes were updated today. There are no explicit changes to the requirements, but the order of the guidelines has been changed so that it corresponds more effectively to how it makes sense to run tests on the guidelines.

Additionally, I’ve added some information on how to run tests for each guideline into the guidelines, so that theme developers are more easily able to find information on how to self-test when they’re creating an accessibility-ready theme.

Review the guidelines.

#accessibility-ready, #themes-2

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

Taking Steps for More Accessible Themes

We’ve been working with the Theme Review team to coordinate sharing more information about making themes accessible, with an eye towards the goals in our Accessible Themes Roadmap. The first step in that roadmap has been published today, Three Easy tips for Accessible Theming, published at the Make/Themes blog.

Read it, share it, and most of all, build accessible themes for WordPress!

#themes-2

Draft guide for accessibility-ready reviewers

To go along with the accessibility-ready guidelines, I’ve been working on a document to help people who want to help perform accessibility reviews on themes. This document is targeted at members of the accessibility team who want to help support the review process by checking themes for accessibility.

Please provide comments, so I can edit them into the most helpful guide they can be!

Theme Accessibility Guide for Reviewers

#accessibility-ready, #themes-2

Update on accessibility-ready theme tag

We’re gradually working the kinks out of the process. There was an oversight in the automated process that added the accessibility-ready keyword to themes, so that only new themes were automatically getting the keyword, and not updated themes that added it. That’s been fixed, which will improve our ability to note themes that need to go through the review process.

There’s a lot of support for the process, and the theme review team is invested in making this work, but I could use some backup in actually doing the reviews. Even if you don’t have the accessibility background, let me know if you’re interested: I’m happy to provide training to make sure you’ve got the knowledge it takes to do this review.

#accessibility-ready, #themes-2

Want to participate in reviewing WordPress themes for…

Want to participate in reviewing WordPress themes for the accessibility-ready tag? There’s a trac keyword for that! Themes awaiting an accessibility-ready review.

#accessibility-ready, #themes-2

Post titles in attributes

In pretty much every theme, there is something that looks like this:

<a href="<?php the_permalink(); ?>" title="<?php echo esc_attr( sprintf( __( 'Permalink to %s', 'twentythirteen' ), the_title_attribute( 'echo=0' ) ) ); ?>" rel="bookmark"><?php the_title(); ?></a>

My question: Is “Permalink to (title of post)” a WordPress anachronism that, by being a redundant title attribute, actually harms accessibility?

#attributes, #themes-2