One of my first exposures to accessibility in WordPress is the screen reader text class. When I was learning by tinkering around existing themes – it became a familiar sight. Now, the screen reader text class is an effortless addition to my daily development, and it makes a huge difference.
First we’ll go over briefly what this class is and how it can help make sites more accessible. Then I’ll review 5 real life applications of the screen reader text class in the wild. I hope that by reviewing these cases, it can become part of your every day workflow as well.
What is the screen reader text class?
To be clear, this class can be called anything. This class is almost always named “screen-reader-text” in WordPress themes. In Bootstrap, as another example, it’s equivalent class is called “sr-only”. Regardless of what the class is named, it is a set of styles that can be applied anywhere.
This class hides things that you don’t want to display visually, while keeping them “visible” for screen readers. It does so without resorting to using the “display: none” syntax in CSS. The problem with setting the display to none, is that it also removes content for sighted users. There are cases where we don’t want that.
What are those cases? That’s what we’re going to go over next, but first, here is what the CSS looks like for the class in WordPress, copied from the accessibility handbook:
.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;
width: 1px;
word-wrap: normal !important;
}
//if you need focus for skip links
.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. */
}
The A11y Project also has a quick “how to” on visually hiding content we still want accessible if you’d like to reference another source.
What cases require us to use this class?
In most cases, we use this class to provide more context to screen readers that sighted users wouldn’t need. Like a shopping cart icon. For someone who can see the icon, it’s an obvious indicator of how to reach their shopping cart on an e-commerce site. For a screen reader however, we need to provide a text alternative.
We can also use the screen reader text class to add new features that would improve site navigation for screen reader users specifically. Lastly, this class can be used to provide warnings to screen reader users when an action will trigger behaviors.
First case: icons
This is usually applicable to icons in interactive elements like buttons and links. In general, it’s better UI practice to have text with any element that’s interactive. It’s straightforward and accessible right off the bat. However, mobile designs for example, with less real estate, end up simplifying interactive elements to icons only. So, like the shopping cart example I mentioned earlier, we need to provide text alternatives so that non-sighted users know what these buttons or links are.
<a href="/cart" class="cart-link"> <span class="screen-reader-text">Go to shopping cart</span> <span class="glyphicon glyphicon-shopping-cart" aria-hidden="true"></span> </a>
I like to use Chris Coyier’s method for icon fonts, where the icon is an inner element I can apply separately from the interactive element. This allows me to apply an aria attribute that prevents the screen reader from reading out the gobbly gook that icon fonts usually spit out.
In my example, I’m using classes from a glyphicons component, available in an older version of Bootstrap. If I’m using Bootstrap, I would use it’s native class “sr-only”, but to make my example, and the class clear, I named it like the WordPress equivalent “screen-reader-text”.
This method will display a cart icon for sighted users while pushing the text alternative off-screen via CSS. The screen reader text class on the icon span, provides context to the link, and as a result, non-sighted users will “see” the icon as “Go to shopping cart”.
As a reminder, whenever you’re writing these text alternatives, you want to be as clear as possible. You want text that is clear what pages they re-direct to or what actions they trigger when pulled out of context. In other words, “Close login modal” instead of “Close”. “Download cupcake recipe pdf” instead of “Download”. “Go to Rachel’s Twitter” instead of “Twitter”.
It’s important that you keep context in mind when writing text alternatives because screen readers have a feature that group all the links available on a web page. This makes it easier for users to scroll through the links available all at once rather than having to navigate through the content of the page. If you implement the screen reader class correctly, but the text provided doesn’t have enough context, it defeats the purpose of providing a text alternative in the first place.
Second case: skip links
I learned about skip links from WordPress themes, but they are a universal practice. I also wrote about them in an older article of mine, “Accessible Links by the Handbook“.
Skip links are anchor links that “skip to” content. They usually link to whatever container wraps the main content of the site. Sometimes they’ll link to sidebar and footer content as well. Having these convenient links allow those using them to navigate your site content faster. Not sure what I mean?
Here’s what skip links would look like in your WordPress theme, copied from the WordPress handbook again:
<body>
<header>
<a class=”screen-reader-text skip-link” href="#content">Skip to content</a>
<h1>Site title</h1>
</header>
<nav>
<ul>
<li><a href="/">Home</a></li>
<li><a href="/accessibility">Accessibility</a></li>
<li><a href="/blog">Blog</a></li>
</ul>
</nav>
<main id="content">
<!-- Content of the page -->
</main>
</body>
Once again, because the A11y Handbook is known to change every now and then, here’s another reference about Skip Links from the A11y Project.
Now that you see what the code is like, let me explain exactly what Skip Links are for. This is one of those cases I mentioned earlier about new features that specifically benefit those using assistive technologies. Except in this case, it also benefits non-screen reader users. That’s right, I’ll write it again – it benefits non-screen reader users as well!
How? Skip links are just ordinary anchor links, placed before the main navigation that are hidden with the screen reader text class. However when focused on, they appear visually too. So say you’ve got a broken arm from skate boarding too hardcore, and using a mouse is painful, you can navigate sites using your keyboard’s tab key. Skip links would be the best way to “teleport” you to the content you want without having to tab through everything on a website. Or whatever assistive technology that serves as an alternative to a mouse, even if the user has vision, will benefit from this practice.
Third case: read more
This is one you’ve probably seen before. It’s one of the requirements to submit accessible themes to the WordPress repository (forgot to mention that so are skip links). Here’s the handy example of read more text from the handbook. That sentence was a handful to write… Okay, no more puns.
These “read more” links are just links to the full versions of content where only an excerpt is being shown. Since screen readers benefit from context, we need to provide what exactly the user is reading more of. Inserting the post title and hiding it with the screen reader text class makes the most sense. See the example from the handbook below:
<?php the_content( sprintf( __( 'Continue reading%s', 'textdomain' ), '<span class="screen-reader-text"> '.get_the_title().'</span>' ) ); ?>
Keep in mind that the “read more” link might not necessarily look exactly like the example – it depends on how you’re developing your WordPress theme. Another example might look something like this:
<a class="read-more" href="<?php echo get_the_permalink(); ?>"> <?php echo esc_html( 'Read more', 'textdomain' ); ?> <span class="screen-reader-text"> <?php the_title(); ?></span> <span class="glyphicon glyphicon-arrow-right" aria-hidden="true"></span> </a>
Above, I am using a combination of the icon font and the “read more” techniques for the screen reader text class. I apply the font as an inner element that I can hide from screen readers with the aria attribute “aria-hidden”. Then I include the post title that gets read after the “Read more” for screen reader use only. So sighted users will just see the “Read more” with an arrow being displayed from the icon font. Screen reader users will read, “Read more whatever the post title is,” instead.
Fourth case: new windows and downloads
The fourth case is very similar to the “read more” case – in fact, they’re pretty much the same. This is just another example of how we can provide context for screen readers aside from the “read more” links. Whenever a new window or tab opens, it can be confusing and disorient screen reader users. Same with buttons or links that trigger files to be downloaded. Why? Because screen reader users cannot see that the browser is doing something unexpected, unless announced in some way.
This is why we can use the screen reader text class to provide context for whenever the browser is going to do something beforehand. Below there are three examples.
<!-- Warn of new windows when using target="_blank" on links --> <a href="www.google.com" target="_blank"> Google <span class="screen-reader-text"> will trigger a new window or tab to open.</span> </a> <!-- A browser friendly file will usually open in the browser (pdfs) --> <a href="/some-pdf.pdf"> <span class="glyphicon glyphicon-download" aria-hidden="true"></span> <span class="screen-reader-text">View cupcake recipe PDF in a new window or tab</span> </a> <!-- A non-browser friendly file will usually trigger a download instead (csv, word doc) --> <a href="/some-csv.csv"> Download CSV<span class="screen-reader-text">some-csv.csv</span> </a>
The first example handles a link that triggers a new window to open due to the “target” attribute set to “_blank”. Adding the screen reader text class with some additional text will allow you to warn the user that a new window or tab will open once clicked.
The second example handles a browser friendly file, like a pdf. If the pdf link has a target attribute like the first example, it will open in a new window. If not, it will open in the same window. These types of files don’t auto-download. Therefore, this example uses the screen reader text class to provide not only the name of the file, but also warns of new windows/tabs opening.
The third example handles a non-browser friendly file, like a CSV. Non-browser friendly files will download to the user’s computer once clicked. This example only has the text, “Download”, displaying visually, but it includes the title of the file with the screen reader text class. Screen reader users will read the link as “Download some-csv.csv”.
Last case: form labels
The last case applies to labels in forms. Now, ideally, we always want to have a visible label and an associated field for each label. Here’s a nice article called Labeled with Love that explains the difference between explicit and implicit association. The example I’m using for the screen reader text class is for explicit association. This is where you have two separate elements: a label and an associated field. The two elements become associated with the “for” and “id” attributes. See the example below.
<label for="fave-color-input">What's your favorite color?</label> <input type="text" id="fave-color-input" name="favorite-color"/>
The above is beautiful, accessible, and you can release it into the world like a baby bird ready to fly from the nest.
However, over the course of my career, most designs that I’ve received contained forms without labels. The designs also implemented placeholders as a replacement for labels. Before I go too far off topic, here’s a link on how to use placeholder attributes properly.
Long story short – don’t use placeholders as replacements for labels, and if possible, always go for visible labels.
If you can convince your designer/client to go for visible labels, then all is right with the world. If not, the good news is we can still make the form accessible with the screen reader text class. We can keep the explicit association between label and field, while “removing” the label for sighted users. See the example below.
<label for="fave-color-input" class="screen-reader-text">What's your favorite color?</label> <input type="text" id="fave-color-input" name="favorite-color" placeholder="green, blue, red etc."/>
Review
Let’s sum up all that we’ve gone over. We learned about a set of styles that can be named anything and applied anywhere. These styles, called the “screen-reader-text” class in WordPress, are a simple addition to our every day workflow and increases our site’s accessibility.
Generally this class is used to provide context for screen reader users, provide warnings, or introduce new features to benefit them. We went over 5 real life applications of using the screen reader text class.
- Make icons accessible.
- Create “skip links” to skip to site content.
- Provide content for “read more” links.
- Warn users about new windows/tabs opening or downloads.
- Hide labels in forms when designs call for hidden labels.
I hope that by reviewing all of these cases, this class will become a part of your every day development. If you have any questions about the cases I mentioned, or know of some other cases, I’m all ears. Until next time, happy coding!
Be First to Comment