All non-text content that is presented to the user has a text alternative that serves the equivalent purpose. (Level A)

Rationale

Any information conveyed by means other than text needs to be provided in text as well. The text should provide equivalent information. Examples of non-text content that convey information to users are images, graphs, media files, animations, CAPTCHA and audio alerts.

Short and long text alternatives can be used as needed to convey the equivalent of the non-text content. The most common short text alternative is the use of ALT text attributes for images. Examples of long alternatives include descriptions for graphs, charts or complex images.

There are a number of situations where providing a text equivalent is either not possible or not desirable. The requirements for each of these exceptions are categorized here for guidance.

Operable Exception: Where non-text content is operable, authors should ensure the control is named or the purpose is described. Examples include an image used as a button or link.

Not Feasible Exception: Where it is not feasible to provide a textual equivalent, authors should at least describe the content or its purpose so that it can be identified. Examples include tests which would be invalid if presented in text, content intended to create a sensory-specific experience, and audio-video (which are covered in part by separate Time-based Media criteria).

CAPTCHA Exception: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.

Decorative Exception: Where non-text content is meaningless, irrelevant or redundant, implement so it is ignored by assistive technologies. Examples include images that are purely decorative.

Refer to Understanding SC 1.1.1 for more information (external link to WCAG).

Development Techniques

Review the General techniques as well as other tabs applicable to your technology.  Prioritize the use of technology-specific techniques, and implement the General techniques as needed. You are always required to find, understand and implement accessible code techniques to meet the checkpoint. The documented techniques and supplements are not exhaustive; they illustrate acceptable ways to achieve the spirit of the checkpoint. If numbered, techniques are in order of preference, with recommended techniques listed first. Where used, IBM information that complements the WCAG techniques is indicated as supplemental.

General techniques

Instructions: Select the following situation that matches your content. Except where noted, any item in a described situation represents a technique that is deemed sufficient. Ensure you review WCAG Common Failures to avoid development mistakes.

Situation A: If a short description can serve the same purpose and present the same information as the non-text content

Situation B: If a short description cannot serve the same purpose and present the same information as the non-text content (e.g., a chart or diagram)

Provide a short text alternative using a technique from Situation A IN COMBINATION with one of the following long text alternative techniques:

Situation C: If non-text content is a control or accepts user input

Situation D: If a text equivalent is not feasible (for example because non-text content is time-based media, a test that would be invalid if presented in text, or primarily intended to create a specific sensory experience)

Provide a descriptive alternative using one of the following:

Situation E: If non-text content is a CAPTCHA

Complete both techniques:

Situation F: If the non-text content should be ignored by assistive technology

  • For situations that meet the Decorative Exception, implement or mark meaningless, irrelevant or redundant non-text content so it will be ignored by assistive technology. Refer to the techniques for your specific technology (e.g., Web) for further instruction.

Situation G: If the non-text content is an audio alert

  • Allow the user to choose alternative cues for audio alerts that are in another modality

Web (HTML, ARIA, CSS) techniques

Instructions: In addition to the General techniques, any of these Web techniques are deemed sufficient in the following situations when used as instructed. Where used, IBM information that complements the WCAG techniques is indicated as supplemental.

Situation A: If a short description can serve the same purpose and present the same information as the non-text content

Meet G94: Provide a short text alternative with any of the following:

Situation B: If a short description cannot serve the same purpose and present the same information as the non-text content (e.g., a chart or diagram)

Provide a short text alternative using a technique from Situation A in COMBINATION with one of the following long text alternative techniques:

Situation C: If non-text content is a control or accepts user input

Meet G82 Provide a text alternative that identifies the purpose with any of the following:

Situation D: If a text equivalent is not feasible (for example non-text content is time-based media, a test that would be invalid if presented in text, or primarily intended to create a specific sensory experience)

Situation F: If the non-text content should be ignored by assistive technology

HTML supplements

The following examples and comments provide additional information beyond that available in the WCAG techniques. They are grouped according to the situations described in the General and Web techniques. Where items supplement existing WCAG techniques, they are numbered accordingly (e.g., H37).

Situation A:

H37: Using alt attributes on img elements
Photographs of a person

If the image is a photograph of a person, the person's name would be appropriate alternative text. In the picture below, the alt text for a picture of Ginni Rometty is "Ginni Rometty." You do not need to identify the presence of a picture because assistive technology identifies images.

<img src="ginni.jpg" alt="Ginni Rometty" width="115" height="154" />

 Ginni Rometty

Even if a person's name appears directly before or after their photograph, include the alt text of the graphic. Although the text may seem redundant, the picture provides additional sensory content, and the screen reader user may want to copy and paste the picture to use in a presentation.

Images of text

If the image is of text, wherever possible meet 1.4.5 Images of Text by using text instead of images of text. If the technology does not allow the use of text, the ideal alternative text is the exact text contained in the image. For example, if the text in the graphic is "Done" the alternative text should also be "Done".

<img src="done.gif" alt="Done" />
 

Situation B:

H45: Using longdesc

While you can use the longdesc attribute to provide a long description, most browsers do not render the link specified in the longdesc on the Web page. Therefore, it is preferable to use the techniques described in Situation B of the General techniques.

Use the HTML5 <canvas> element with WAI-ARIA image role, alt text, and aria-describedby

The following example shows the use of the canvas element with a WAI-ARIA image role attribute, label and a description within the canvas tags that an assistive technology will announce to the end user making it accessible.

<!-- Canvas exposed as an image element. -->
<canvas id="example" width="260" height="200" role="img" alt="Circles" aria-describedby="img1">
</canvas>
<div id="img1">
 <p>The prose in this div describes the circles in detail</p>
</div>
 

Situation D:

Use the body of the HTML5 <audio> and <video> elements to provide a descriptive label

When a browser does not support these elements, the alternative text is displayed.

<video ....>
<p>A description of the effects of gravity on an object.</p>
</video>
<audio ....>
<p>A list of IBM's global offices by country.</p>
</audio>

Mobile (iOS) techniques

Instructions: In addition to the General and Web techniques, any of these Mobile iOS techniques are deemed sufficient in the following situations when used as instructed. Links are to Apple's Accessibility Programming Guide for iOS. Where used, IBM information that complements the iOS techniques is indicated as supplemental.

Situation A: If a short description can serve the same purpose and present the same information as the non-text content

Meet G94: Provide a short text alternative with the following:

Situation E: If non-text content is a CAPTCHA

Meet G144: Using a different modality with the following:

Situation F: If the non-text content should be ignored by assistive technology

Situation G: When alerting the user with a sound, provide a vibration feedback

The vibration can be simultaneous with the sound, or an alternative to the sound feedback.

Native iOS Supplements

The following examples and comments provide additional information beyond that available in the Apple iOS techniques. They are grouped according to the situations described in the General techniques.

Situation F:

Do not give labels or hints to unimportant images.

VoiceOver ignores non-text content that does not have a label or hint. Therefore, no special coding is necessary for unimportant, non-text content.

Hybrid supplements

The following examples and comments provide additional information beyond that available in the WCAG and Apple iOS techniques. They are grouped according to the situations described in the General and Web techniques.

Situation E:

Provide an audio version of CAPTCHA using the HTML audio element (Hybrid)

Apple recommends using the HTML5 <audio><video>, and <track> elements for audio and video content on mobile Safari. These elements support audio and video playback natively in the browser  using the browser's  built-in controls.  Developers can also create their own customized media controllers for rich interactivity using web-standard CSS and JavaScript.  Developers should references Apple's "About HTML5 Audio and Video" and  "iOS-Specific Considerations" for proper implementation.

Eclipse techniques

Instructions: In addition to the General techniques, the Eclipse techniques in this section are deemed sufficient in the following situations when used as instructed.

Situation A: If a short description can serve the same purpose and present the same information as the non-text content

Situation C: If non-text content is a control or accepts user input

Situation G: If the non-text content is an audio alert

Eclipse supplements

The following examples and comments provide additional information.

Provide a tooltip text that labels images that are not decorative and have meaning

  • Implement getToolTipText and setToolTipText methods for non-text controls that extend org.eclipse.swt.widgets.Control.
  • Implement getToolTipText and setToolTipText methods for non-text items that extend org.eclipse.swt.widgets.Item and provide these methods, e.g. TabItem, ToolItem and TrayItem.
  • For other non-text items which do not explicitly provide the ability to set tooltips, provide custom tooltips either through an SWT Shell or through the org.eclipse.jface.window.ToolTip class. Refer to SWT Snippet 125 Create emulated tool tips for items in a table under SWT Snippets or JFace Snippet011 Custom Tooltips for concrete examples.

Return Object information

Applications must return Object information for non-text controls as outlined in the required development techniques of Checkpoint 502.3.1 Object Information.

Allow the user to choose alternative cues for audio alerts using one of the following techniques

Use System sounds

The Windows SoundSentry feature can be used to provide visual feedback for general system alerts such as warning beeps. SoundSentry directs the operating system to display a visual signal when a sound is generated by an application. When the user sets Use text or visual alternatives for sounds in the Ease of Access Center, the system will replace system sounds with visual cues. For applications that use system sounds, no special coding is required.

Access the ShowSounds parameter

ShowSounds is an accessibility feature in Windows that instructs programs that usually convey information only by sound to also provide all information visually, such as by displaying text captions or informative icons. The ShowSounds feature is set by the user through the Ease of Access Center in the Windows Control Panel. For more information, refer to the ShowSounds Parameter information page on MSDN.

A Windows-based Eclipse application using the 32 bit Standard Widget Toolkit can test to see if the system environment is set to enable visual cues for audio alerts by examining the ShowSounds parameter. The application can examine the ShowSounds parameter by calling the org.eclipse.swt.internal.win32.OS.GetSystemMetrics function with the SM_SHOWSOUNDS flag set. Alternately, the application can call the org.eclipse.swt.internal.win32.OS.SystemParametersInfo function with the SPI_GETSHOWSOUNDS flag set. If the ShowSounds parameter is enabled, applications must present visual equivalents of important information that would otherwise be presented by audio alone.

 Provide a custom setting

The application can provide its own custom setting for visual cues.

Provide alternative visual cues for audio alerts

Provide alternative visual cue for audio alerts using one of the following techniques.

Dialog box

The application can provide visual cues by displaying a dialog box, such as a MessageBox, for the alert. Refer to the Dialog Boxes information page on MSDN for detailed information.

Status indicator

The application can provide visual cues by displaying a status indicator on the notification area of the taskbar that flashes when initially displayed to attract the user's attention. Refer to The Taskbar information page on MSDN for detailed information.

Text message

 The application can provide visual cues by placing a text message in a status bar. Refer to the Status Bar information page on MSDN for detail information.

Windows-based (MSAA+IA2) techniques

Instructions: In addition to the General techniques, the Windows techniques in this section are deemed sufficient in the following situations when used as instructed.

Situation A: If a short description can serve the same purpose and present the same information as the non-text content

Situation C: If non-text content is a control or accepts user input

Situation G: If the non-text content is an audio alert

Windows supplements

The following examples and comments provide additional information.

Provide a tooltip text that labels images that are not decorative and have meaning

  • Implement getToolTipText and setToolTipText methods for non-text controls that extend org.eclipse.swt.widgets.Control.
  • Implement getToolTipText and setToolTipText methods for non-text items that extend org.eclipse.swt.widgets.Item and provide these methods, e.g. TabItem, ToolItem and TrayItem.
  • For other non-text items which do not explicitly provide the ability to set tooltips, provide custom tooltips either through an SWT Shell or through the org.eclipse.jface.window.ToolTip class. Refer to SWT Snippet 125 Create emulated tool tips for items in a table under SWT Snippets or JFace Snippet011 Custom Tooltips for concrete examples.

Return Object information

Applications must return Object information for non-text controls as outlined in the required development techniques of Checkpoint 502.3.1 Object Information.

Allow the user to choose alternative cues for audio alerts using one of the following techniques

Use System sounds

The Windows SoundSentry feature can be used to provide visual feedback for general system alerts such as warning beeps. SoundSentry directs the operating system to display a visual signal when a sound is generated by an application. When the user sets Use text or visual alternatives for sounds in the Ease of Access Center, the system will replace system sounds with visual cues. For applications that use system sounds, no special coding is required.

Access the ShowSounds parameter

ShowSounds is an accessibility feature in Windows that instructs programs that usually convey information only by sound to also provide all information visually, such as by displaying text captions or informative icons. The ShowSounds feature is set by the user through the Ease of Access Center in the Windows Control Panel. For more information, refer to the ShowSounds Parameter information page on MSDN.

A Windows-based Eclipse application using the 32 bit Standard Widget Toolkit can test to see if the system environment is set to enable visual cues for audio alerts by examining the ShowSounds parameter. The application can examine the ShowSounds parameter by calling the org.eclipse.swt.internal.win32.OS.GetSystemMetrics function with the SM_SHOWSOUNDS flag set. Alternately, the application can call the org.eclipse.swt.internal.win32.OS.SystemParametersInfo function with the SPI_GETSHOWSOUNDS flag set. If the ShowSounds parameter is enabled, applications must present visual equivalents of important information that would otherwise be presented by audio alone.

 Provide a custom setting

The application can provide its own custom setting for visual cues.

Provide alternative visual cues for audio alerts

Provide alternative visual cue for audio alerts using one of the following techniques.

Dialog box

The application can provide visual cues by displaying a dialog box, such as a MessageBox, for the alert. Refer to the Dialog Boxes information page on MSDN for detailed information.

Status indicator

The application can provide visual cues by displaying a status indicator on the notification area of the taskbar that flashes when initially displayed to attract the user's attention. Refer to The Taskbar information page on MSDN for detailed information.

Text message

 The application can provide visual cues by placing a text message in a status bar. Refer to the Status Bar information page on MSDN for detail information.


Most links in this checklist reside outside ibm.com at the Web Content Accessibility Guidelines (WCAG) 2.0. W3C Recommendation 11 December 2008: http://www.w3.org/TR/WCAG20/

Copyright © 1994-2017 World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University, Beihang University). All Rights Reserved.

Copyright © 2001, 2017 IBM Corporation