Providing Alternate Content for Screen Reader Users

Sometimes, components of your user interface will communicate information in a visual manner for which a programmatic or text equivalent may not be available. In these situations, you have to come up with a way to provide the same information to users of screen readers in order to provide an equivalent experience. This article will explore various techniques for making alternate content available to screen readers. It will examine the tradeoffs of each solution so that you know which technique to employ for your particular circumstance.

If It Benefits Everybody, Put It On-Screen

This seems like a point that is too obvious to mention, but sometimes we might be led to think that our alternate content would only benefit those who aren’t reviewing the page visually. An alternative that you provide, however, can benefit more users than you may realize. For example, a text description of a complex image or diagram might benefit users with low vision or users with cognitive disabilities. Therefore, if it has the potential to benefit a larger group of users, make the alternate content perceivable on-screen. You could provide a link to the alternate description hosted on a separate page if it won’t fit visually on the primary page.

Use Programmatic Methods When Supported

Programmatic methods are continually being developed to allow states and properties to be communicated in a way that can be understood by machines. This is of course advantageous because it allows for adaptability by leaving the responsibility of exposing these states and properties to the user’s technology stack. A great example of this is the W3C WAI-ARIA specification. Using WAI-ARIA, you can programmatically indicate that particular item is selected among a group of items using the aria-selected state, or that an element is the current item in a step, page, date, time, location or set using the aria-current state. This information might be indicated visually in your UI using color, underlining, font size or weight, a visible border or other styling techniques that are not perceivable non-visually. In implementing a programmatic solution for a supplied alternative, one must ensure that the solution will be supported by the element used in the host language and by the user’s technology stack. For example, the aria-selected state can only be used with the gridcell, row, tab and option roles. The aria-current state was introduced in the WAI-ARIA 1.1 specification and, while it has received quick adoption among Windows screen readers, may not be as robustly implemented on other platforms. See the aria-current page on SSB Labs by Level Access to track assistive technology support for aria-current.

Hide the Alternative Off-Screen

When the language or element being used doesn’t support the ability to provide an alternative programmatically, you may have to hide the alternate off-screen. This means that you include the alternate content on the page, but you outdent it to the left using CSS so that it can’t be visually scrolled into view. Assistive technologies will not recognize that the content is being visually hidden off-screen and so will still expose it to the user. A great use for visually hidden text equivalents is providing descriptions for CSS background images and icon fonts. Since native elements do not exist for these components, there isn’t a way to supply a programmatic alternative. We must resort to WAI-ARIA solutions or visually hidden text to furnish the alternate content to the screen reader user. There are a number of WAI-ARIA solutions that are discussed in other articles on the web such as Alternate Text for Background Images by David MacDonald. Visually hidden text can be combined with the Content CSS property in conjunction with the :before or :after pseudo-elements to provide both visual and non-visual text equivalents for CSS background images. This technique is discussed in the article Style over Substance: the Content CSS Property. Keep in mind that for icon fonts and CSS background images, we must have text equivalents that are available both visually and non-visually. For icon fonts, we additionally must hide the visual representation of the icon from screen readers, as the Unicode character representing the font will be pronounced by some screen readers. To do this, place the icon font within a span element and apply aria-hidden="true" to the span. Supply the non-visual equivalent using visually hidden text or the aria-label property and supply a visual text equivalent that will be shown if the user doesn’t have the used font installed or if the user is using screen magnification software that disables icon fonts such as ZoomText. Another use for visually hidden text is to provide instructions or supplemental information that is apparent visually. This could be information about the layout of the page, or it could be information about how the user should interact with the page using their screen reader. This could include keystrokes or gestures to be used with the page or website, but if this information could also benefit users who are not using a screen reader then it should be made available visually as well.

The following technique is recommended for visually hiding text using CSS across all browsers and platforms:

<style type="text/css">
/* clip technique */
.sr-only-clip {
  position: absolute !important;
  height: 1px; 
  width: 1px; 
  overflow: hidden;
  padding: 0 !important;
  border: 0 !important;
  white-space: nowrap !important;
  clip: rect(1px 1px 1px 1px) !important; /* IE6, IE7 */
  clip: rect(1px, 1px, 1px, 1px) !important;
  clip-path: inset(50%) !important;
}

Another way to visually hide text off-screen is to hide it off the left edge of the screen, as such:

 .hiddentext {
  position: absolute;
  left:-10000px;
  top: auto;
  width: 1px;
  height: 1px;
  overflow: hidden;
}

This “off-the-left-edge” technique of visually hiding text has the disadvantage of not being accessible on touchscreen devices as the content cannot be accessed directly using any provided explore-by-touch features of the screen reader. Moreover, it can cause scrolling on some platforms such as iOS when attempting to focus content using VoiceOver.

Conclusion

We have examined various techniques for providing visually communicated information when a method is not directly supported to supply an alternative. Generally, we want to make this alternative available to as many users as can benefit from having it. For this reason, supplied alternatives should be made available visually and non-visually whenever feasible. To provide non-visual equivalents for visual information, we can supply this content textually or programmatically depending on the host language and element in use, and the level of support across the technology stacks we are supporting. Non-visual equivalents should always be provided programmatically whenever possible as this places the burden of exposing the equivalent on the user’s technology stack in a rendering that can be perceived and understood by the user using a familiar and consistent representation. When the language, element or technology stack does not support a programmatic alternative, this can be supplied using a text alternative. One technique for non-visually providing a text alternative is to hide the content off the screen. This technique can have some disadvantages to users of touchscreen devices as it can cause inadvertent scrolling and will not be available using the explore-by-touch features of the user’s screen reader. If we are supplying both programmatic and text equivalents in order to provide progressive enhancement for older assistive technologies, then we must hide the text equivalents from supporting assistive technologies to prevent double speaking of the alternative. This can be accomplished by placing the text alternative in a span element and applying aria-hidden to it, thus only exposing the programmatic alternative to ARIA-supported screen readers.

I hope this article helped to shed some light on when and why we need alternatives for screen reader users. You should also have acquired some basic knowledge of how to provide these alternatives, and when a technique is appropriate for a particular circumstance. With this knowledge, you can become more empowered to provide equivalent experiences across a diverse array of users.