Information Equivalence – References

For example, the first guideline explains how content developers can make images accessible. Some users may not be able to see images, others may use text-based browsers that do not support images, while others may have turned off support for images (e.g., due to a slow Internet connection). The guidelines do not suggest avoiding images as a way to improve accessibility. Instead, they explain that providing a text equivalent of the image will make it accessible.

How does a text equivalent make the image accessible? Both words in "text equivalent" are important:

• Text content can be presented to the user as synthesized speech, braille, and visually-displayed text. Each of these three mechanisms uses a different sense -- ears for synthesized speech, tactile for braille, and eyes for visually-displayed text -- making the information accessible to groups representing a variety of sensory and other disabilities.
• In order to be useful, the text must convey the same function or purpose as the image. For example, consider a text equivalent for a photographic image of the Earth as seen from outer space. If the purpose of the image is mostly that of decoration, then the text "Photograph of the Earth as seen from outer space" might fulfill the necessary function. If the purpose of the photograph is to illustrate specific information about world geography, then the text equivalent should convey that information. If the photograph has been designed to tell the user to select the image (e.g., by clicking on it) for information about the earth, equivalent text would be "Information about the Earth". Thus, if the text conveys the same function or purpose for the user with a disability as the image does for other users, then it can be considered a text equivalent.

Note that, in addition to benefitting users with disabilities, text equivalents can help all users find pages more quickly, since search robots can use the text when indexing the pages.

While Web content developers must provide text equivalents for images and other multimedia content, it is the responsibility of user agents (e.g., browsers and assistive technologies such as screen readers, braille displays, etc.) to present the information to the user.

Non-text equivalents of text (e.g., icons, pre-recorded speech, or a video of a person translating the text into sign language) can make documents accessible to people who may have difficulty accessing written text, including many individuals with cognitive disabilities, learning disabilities, and deafness. Non-text equivalents of text can also be helpful to non-readers. An auditory description is an example of a non-text equivalent of visual information. An auditory description of a multimedia presentation's visual track benefits people who cannot see the visual information.

Excerpt from the WCAG 1.0

Guideline 1. Provide equivalent alternatives to auditory and visual content.

Provide content that, when presented to the user, conveys essentially the same function or purpose as auditory or visual content.

Although some people cannot use images, movies, sounds, applets, etc. directly, they may still use pages that include equivalent information to the visual or auditory content. The equivalent information must serve the same purpose as the visual or auditory content. Thus, a text equivalent for an image of an upward arrow that links to a table of contents could be "Go to table of contents". In some cases, an equivalent should also describe the appearance of visual content (e.g., for complex charts, billboards, or diagrams) or the sound of auditory content (e.g., for audio samples used in education).

This guideline emphasizes the importance of providing text equivalents of non-text content (images, pre-recorded audio, video). The power of text equivalents lies in their capacity to be rendered in ways that are accessible to people from various disability groups using a variety of technologies. Text can be readily output to speech synthesizers and braille displays, and can be presented visually (in a variety of sizes) on computer displays and paper. Synthesized speech is critical for individuals who are blind and for many people with the reading difficulties that often accompany cognitive disabilities, learning disabilities, and deafness. Braille is essential for individuals who are both deaf and blind, as well as many individuals whose only sensory disability is blindness. Text displayed visually benefits users who are deaf as well as the majority of Web users.

Providing non-text equivalents (e.g., pictures, videos, and pre-recorded audio) of text is also beneficial to some users, especially nonreaders or people who have difficulty reading. In movies or visual presentations, visual action such as body language or other visual cues may not be accompanied by enough audio information to convey the same information. Unless verbal descriptions of this visual information are provided, people who cannot see (or look at) the visual content will not be able to perceive it.

Checkpoints:

1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. [Priority 1]

For example, in HTML:

• Use "alt" for the IMG, INPUT, and APPLET elements, or provide a text equivalent in the content of the OBJECT and APPLET elements.
• For complex content (e.g., a chart) where the "alt" text does not provide a complete text equivalent, provide an additional description using, for example, "longdesc" with IMG or FRAME, a link inside an OBJECT element, or a description link.
• For image maps, either use the "alt" attribute with AREA, or use the MAP element with A elements (and other text) as content.

Refer also to checkpoint 9.1 and checkpoint 13.10.

Techniques for checkpoint 1.1

1.2 Provide redundant text links for each active region of a server-side image map. [Priority 1]

Refer also to checkpoint 1.5 and checkpoint 9.1.

Techniques for checkpoint 1.2

1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation. [Priority 1]

Synchronize the auditory description with the audio track as per checkpoint 1.4. Refer to checkpoint 1.1 for information about textual equivalents for visual information.

Techniques for checkpoint 1.3

1.4 For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation. [Priority 1]

Techniques for checkpoint 1.4

1.5 Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map. [Priority 3]

Refer also to checkpoint 1.2 and checkpoint 9.1.

Techniques for checkpoint 1.5

Excerpt from the WCAG 1.0

• 1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ASCII art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. [Priority 1]
• 1.2 Provide redundant text links for each active region of a server-side image map. [Priority 1]
• 1.5 Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map. [Priority 3]
• 12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone. [Priority 2]

Text is considered accessible to almost all users since it may be handled by screen readers, non-visual browsers, and braille readers. It may be displayed visually, magnified, synchronized with a video to create a caption, etc. As you design a document containing non-textual information (images, applets, sounds, multimedia presentations, etc.), supplement that information with textual equivalents wherever possible.

When a text equivalent is presented to the user, it fulfills essentially the same function (to the extent possible) as the original content. For simple content, a text equivalent may need only describe the function or purpose of content. For complex content (charts, graphs, etc.), the text equivalent may be longer and include descriptive information.

Text equivalents must be provided for logos, photos, submit buttons, applets, bullets in lists, ASCII art, and all of the links within an image map as well as invisible images used to lay out a page.

Quicktest! A good test to determine if a text equivalent is useful is to imagine reading the document aloud over the telephone. What would you say upon encountering this image to make the page comprehensible to the listener?

2.1 Overview of Technologies

How one specifies a text equivalent depends on the document language.

For example, depending on the element, HTML allows content developers to specify text equivalents through attributes (" alt" or "longdesc" ) or in element content (the OBJECT element).

Video formats, such as QuickTime, will allow developers to include a variety of alternative audio and video tracks. SMIL ([SMIL]) allows developers to synchronize alternative audio and video clips, and text files with each other.

In creating XML DTDs, ensure that elements that might need a description have some way of associating themselves with the description.

Some image formats allow internal text in the data file along with the image information. If an image format supports such text (e.g., Portable Network Graphics, see [PNG]) content developers may also supply information there as well.

2.2 Backward Compatibility

Content developers must consider backward compatibility when designing Web pages or sites since:

• Some user agents do not support some HTML features,
• People may use older browsers or video players,
• Compatibility problems may arise between software

Therefore, when designing for older technologies, consider these techniques:

• Provide inline text equivalents. For example, include a description of the image immediately after the image.
• Provide links to long text equivalents either in a different file or on the same page. These are called description links or "d-links". The link text should explain that the link designates a description. Where possible, it should also explain the nature of the description. However, content developers concerned about how the description link will affect the visual appearance of the page may use more discrete link text such as "[D]", which is recommended by NCAM (refer to [NCAM]). In this case, they should also provide more information about the link target so that users can distinguish links that share "[D]" as content (e.g., with the "title" attribute in HTML).

Excerpt from Core Techniques section of Technical Decument for WCAG 1.0