CSS in Action: Invisible Content Just for Screen Reader Users

Graphics used as headers

Designers have always sought to make web content as visually pleasing as possible. The markup language of HTML produces rather bland-looking content without the addition of graphics or other media elements. A favorite technique of visual designers is to use graphics as document headings. This technique allows designers to have more control over the look and feel of the headings than simple text does. Unfortunately, this produces documents that do not provide good semantic structure on the level of the markup. Screen readers cannot recognize these elements as headings without the proper markup (i.e. <h1>, <h2>, etc.). Surrounding a graphic with heading tags does not quite solve the problem either. In a semantic sense, headings should be text.

Several techniques have been presented to allow developers to use graphics as headers within semantically-correct documents. The first, and most widely-known technique is Todd Fahrner’s image replacement technique [1]. Soon after its introduction, accessibility experts noticed that the technique made the content unavailable to screen readers [2]. Not long thereafter, several people introduced alternative techniques, such as Bob Easton’s off-to-left-technique [3], Mike Rundle’s text-indent method [4], and others. All of these techniques succeed in hiding HTML content, some of them succeed in making the content accessible to screen readers, and some of them work across all major browsers and operating systems. However, none of them succeed in all three of these areas, though some are better than others.

Sample Code 2

The following code should appear in the style sheet:

The CSS class should then be referenced from within the tag of the element being hidden, as shown:

"Skip navigation" links

Designers often balk at the idea of providing a text link on their page just for screen reader users to allow them to skip past repetitive navigational links as required by Section 508 of the Rehabilitation Act in the United States [5], and as recommended by the international Web Content Accessibility Guidelines (WCAG), version 1.0 [6]. Adding a "skip navigation" link on a web page intrudes on the original design, and often forces the designer to alter the layout.

Some designers have responded by hiding the text inside of image alt text, or using some other method that completely hides the link from visual users. The biggest drawback to making this link invisible is that this makes the link unavailable to sighted users who might find such a link useful, such as people with mobility impairments who cannot use a mouse. Some users with mobility impairments become fatigued easily, and would rather use a "skip navigation" link than tab through all of the menu items and other content that precedes the page’s main content.

One way to reconcile the desires of visual designers with those of screen reader uses and users with mobility impairments is to use a technique that hides the "skip navigation" link until the user tabs to it, at which time the link is made visible to sighted users. This would allow both blind and visual users to take advantage of the link’s functionality.

In order to accomplish this goal, the link is hidden its default state—using the technique described in this paper—but is moved down to the visible area when the link receives keyboard focus. In other words, two styles are created. One for the <a> tag and one for the a:focus pseudo-element. The style for the a:focus pseudo-element will only be active when the user tabs to the link, and the link will revert back to its default style (i.e. it will disappear again) when the user tabs away from the link.

Sample Code 3

The following code should appear in the style sheet:

The CSS class should then be referenced from within the tag of the element.

The one drawback to this idea, on a conceptual level, is that the sudden appearance of a link that was previously invisible will be unexpected, and could confuse the sighted keyboard user. This will not be a problem for screen reader users, because they cannot see the screen to realize that the link suddenly appears visually. From their perspective, the link was always there, because, in fact, it was. It was just not visible to the eyes. Mouse users will never see the link at all, so this is not an issue for them.

Forms within data tables

To a visual user, table header cells can perform the dual function of organizing table content and also providing labels for the form elements within that table, as seen in the screenshot of a form within a data table below.

Figure 1. Data table used to provide "labels" for form elements

To a screen reader user, the table row and column headers are somewhat useful in terms of understanding the layout of the table, but the headers do not act as form labels. When screen reader users tab from one form element to another, they will not hear the table headers read to them. In fact, they will not hear any label at all. Screen readers require text labels. Ideally, these labels should be wrapped in the <label> tag, as recommended by WCAG 1.0. Additional labeling and grouping can be accomplished by using the <fieldset> and <legend> tags.

In this particular instance, however, visual users will not receive any added benefit from the visual text labels. To them, such text labels would be redundant with the table headers, since, in a visual sense, these headers already provide adequate labels for the form elements. Here is how the same table would look to visual users if standard text labels were added, with the <label> tag, <fieldset> tag, and <legend> tag:

Figure 2. Form with labels within a data table.

Though screen reader users will be happy with this version of the table, most sighted users will find the additional text to be a distraction. To visual users, the table has just become more crowded, wordy, and harder to understand at a glance. This is a situation in which the addition of markup intended to benefit screen reader users interferes with the accessibility, or at least the user-friendliness of the content to visual users.

Sample Code 4

The following code should appear in the style sheet:

The CSS class should then be referenced from within the tag of the element being hidden, as shown:

Multiple form elements that "share" a single label

Another example of apparent incompatibility between the needs of screen readers users and visual users occurs when developers create multiple form elements that seem as though they ought to belong to the same label. A common example of this is when two, or more text input elements are used for phone numbers.

Figure 3. Form labels that apply to more than one form element.

In the screenshot above, most visual users in North America will understand that the individual text input areas correspond to the different sections of standard phone numbers. Screen reader users may attempt to enter the entire phone number in the first box. When they discover that the box limits them to only 3 characters, this will likely lead to some confusion. Some users will be able to figure out the entire context after experimenting with it, but this kind of experimentation takes time, and is unnecessary.

The most obvious workaround for this particular problem would be to combine all of the text input boxes into a single text input box, and then provide the appropriate label. This may be the best solution in most circumstances in almost every way. Nevertheless, the CSS technique can be applied to this situation also.

Sample Code 5

The CSS class should then be referenced from within the tag of the element being hidden, as shown:

Providing contextual cues just for screen reader users

The same CSS technique can be used to provide contextual cues especially for screen reader users that visual users would not need to see. As long as this technique is not over-used, screen reader users can benefit from text messages that explain the context of the web content to them. For example, sites with complex menu systems are often designed with graphical interfaces that organize the menu hierarchies into visual spaces. Visual "tabs" are frequently used for this purpose. Oftentimes, the menu system is designed so that it highlights the user's position within the menu hierarchy. Most of this information is lost on screen reader users because it is all conveyed visually. It may be appropriate to provide hidden phrases that allow screen reader users to orient themselves within such structures. Phrases that may be useful and appropriate to insert within the content include:

• Begin main menu.
• End main menu.
• Begin [and End] the Products and Services submenu
• You are here [followed by the text of the current menu item within the hierarchy]
• Advertisement [place this before a banner ad, for example]

A word of caution: all of these phrases should be brief, and should be used sparingly, if at all. Many sites do not need to resort to this kind of contextual help. The simpler and cleaner the design, the less of a need there is for this technique. Designers should not overburden screen reader users with text that provides little or no benefit to them. This technique can provide important contextual cues that are otherwise only visual in nature, but since screen reader users have to listen to whatever text is in the page, these cues should be kept to a minimum.

Sample Code 6

The following code should appear in the style sheet:

The CSS class should then be referenced from the <label> tag, as shown: