Guideline: Provide alternative text for all images, applets, and image maps, including images used as submit buttons and all of the links within a client-side image map. [Priority 1]
Rationale: Otherwise, users who are blind, have low vision, or have chosen not to view graphics will not know the purpose of the visual components on the page.Example
Since ASCII art uses characters to create a visual image there is no way to attach alt-text as with other images.
- For all images(IMG) provide alt-text ("alt") [Priority 1]
- For all applets (APPLET)provide alt-text and content [Priority 1]
- For all image map links (AREA)
- Provide alt-text [Priority 1].
- Also provide redundant links [Priority 2].
- Don't use server-side image maps unless the same function or information is available in an alternative accessible format. [Priority 1]
- For all graphical buttons (INPUTtype="image") provide alt-text ("alt")[Priority 1]
- Replace ASCII art with an image and alt-text. [Priority 2 unless the art conveys important information (e.g., a chart) then it would be Priority 1]. Note. If description of (important) ASCII art does not fit in "alt" then use d-link (see A-2).
- If OBJECT is used to embed any of the above components, provide text within the OBJECT element(since OBJECT does not have "alt") [Priority 1].
Guideline: Provide descriptions for graphics, scripts, or applets that convey important information. [Priority 1]
Rationale: Otherwise, important information presented graphically (charts, billboards, diagrams) will not be perceivable to people with blindness, some people with low vision, and users who have chosen not to view graphics, scripts, or applets or whose browser does not support scripts or applets.
- When most browsers in use support longdesc use longdesc. Until then use d-links (or invisible d-link). [Priority 1] Note. If you use both "longdesc" and d-link or if you use "rel" to link the image and d-link, a tool under development will be able to convert d-links to"longdesc" and/or OBJECTs as well as remove d-links automatically if desired.
- When most browsers support OBJECT use OBJECT to include graphics, scripts and applets, etc. [Priority 1]Note. If "longdesc" and OBJECT become supported at the same time then OBJECT would be the preferred implementation.
Guideline: Provide textual equivalents (captions) of all audio information. If the audio is associated with a visual presentation (movie or animation),synchronize the textual equivalents with the visual presentation. [Priority 1]
Rationale: Otherwise, users who are deaf, or hard of hearing, or who have turned sound off cannot perceive the information presented through sounds such as speech, sound effects, and music.
- For stand alone audio files provide a textual transcript of all words spoken or sung and significant sounds. [Priority 1]
- Tie text transcripts to the audio clip with "rel" if the transcript is in a separate document. [Priority 3]
- For audio associated with video, provide a textual transcript (of dialog and sounds)synchronizedwith the video. [Priority 1]
- Where sounds are played automatically, provide visual notification and transcripts. If the sound is important [Priority1], if not [Priority 2].
Guideline: Provide auditory descriptions of moving visual information (movies, animations, etc.). If the visual presentation is associated with an auditory presentation, synchronize the auditory descriptions with the existing auditory presentation and collatethe text version of the descriptions with the text transcript (captions)of the primary audio track. [Priority 1]
Rationale: Otherwise, users who cannot see (or look at) the page will not be able to perceive information presented through action, body language, or other visual cues that are not available through the auditory information (dialogue, sound effects, etc.).
- For short animations such as animated .gifs SeeA-1 (Provide alternative text...)[Priority 1]
- For movies, provide auditory descriptions that are synchronized with the original audio. [Priority 1]
- Provide a text version of the auditory description which is collated with the text transcript of the primary audio track. [Priority 1??]
Guideline: Use structures that support the inclusion of alternate presentation types. [Priority 1]
Rationale: If other types of information, such as images, are used as the source of a frame there is no way to attach alternative information to the information. In the image example, there is no way to attach alt-text (.seeA-1).
- The source of a frame should be an HTML file. [Priority 1]
Guideline: Avoid use of color in a way that causes problems for people with colorblindness. [Priority 1]
Rationale: If color is used to convey information, be sure information is perceivable to those who can not perceive color. (guideline or strategy??) contrast and coding.needs work
Quick test: Is your page viewable and understandable in monochrome?
- Don't use color to convey information, unless it is also clear from the markup and/or text.
- Do not use foreground and background color combinations that do not provide sufficient contrast when viewed by someone with colorblindness.
B. Output Display Independence.
Enable the document to be presented in a variety of media types with a variety of output devices.
OR Enable the document to be reformatted for the purpose of presentation in different media and different output devices.
Guideline: Separate content and structure from presentation. [Priority 2]
Rationale: When content is tied to presentation, such as color-coding list items to distinguish between them in some way, it is difficult to impossible to transform the information into a different modality. Example.
Character spacing and non-letter characters cause problems for screenreaders
- Mark up structure with structural elements (headings, lists, sections, etc.) [Priority 2]
- Style sheets should be used to control layout and presentation wherever possible. Where a majority of users have browsers that do not yet support desired style sheet features, tables(to control layout) and bit-maptext with alt-text (for special text effects) may be used, with alternative pages used as necessary. [Priority 2]
- Use relative sizing and positioning (e.g., percent) rather than absolute (e.g., pixels or point). [Priority 2]
Guideline: Use elements and attributes appropriately. [Priority 2]
Rationale: When elements and attributes are used inappropriately, such as using structural elements for presentation purposes (e.g., H1 to create large, bold face text, or BIG and B to mark a heading),user agents that allow users to navigate through the structurewill be unable to do so properly. Reformatting the page for other media and devices can also be difficult.
- Nest headings properly (H1 -H6). [Priority 2]
- Encode list structure and list items properly (UL, OL, DL, LI).[Priority 2]
- Avoid deprecated elements and attributes, especially presentation elements (TT and FONT) and attributes ("background" and "align"). Use stylesheets instead.[Priority 2]
- CMN - Do not use image maps to create graphical "submit"buttons. (use BUTTON properly instead?) [Priority 2]
Guideline: Ensure that moving, blinking, scrolling, or auto-updating objects or pages maybe paused or frozen. This is particularly important for objects that contain text. Note. Does not apply to instant redirection.[Priority 1]
Some people with cognitive limitations or visual disabilities are unable to read moving text quickly enough or at all. Movement can also cause such a distraction that the rest of the page becomes unreadable for people with cognitive disabilities. Screen readers are unable to read moving text. People with physical disabilities might not be able to move quickly or accurately enough to interact with moving objects.
- Avoid using movement where possible. [Priority 3]
- Provide a mechanism to allow users to freeze movement or updating in applets and scripts or use StyleSheets and scripting to create movement. [Priority 1]
- For auto-refreshing pages, provide a second copy of the page where refreshing is done by clicking on a link (until user agents provide this ability themselves). [Priority 1]
Note. Avoid BLINK and MARQUEE since they are proprietary elements.
Guideline: Changes in language within text should be identified. (Need for any text to identify clearly the language that it is written in.) [Priority2]
Rationale: This is a particular problem for Braille translators, especially when multiple languages appear on the same page.
- Use the "lang" attribute to identify the language of the text. [Priority 2]
C. Control Device Independence.
Ensure all elements on a page are operational in a device independent fashion.
Guideline: Ensure that pages using newer technologies will fail gracefully if the technology is not supported or is turned off. [Priority 1]
Rationale: With each release of HTML new features have been added. Older browsers ignore new features and some users configure their browser not to make use of new features. These users often see nothing more than a blank page or an unreadable page when new technologies do not fail gracefully.
New technologies must fail gracefully and accessibly. [Priority 1]
- How frames can fail gracefully (NOFRAME)
- How scripts can fail gracefully (NOSCRIPT)
- How style sheets can fail gracefully
- How applets can fail gracefully (OBJECT, APPLET)
- For forms and tables, provide a phone number, fax number, e-mail, or postal address.
See also E-5 - text-only pages.
Guideline: Enable keyboard operation of all page elements. [Priority 1]
Rationale: Someone who is using the page without sight, with voice input, or with a keyboard (or other input device other than a mouse) will have a difficult time navigating a page if keyboard shortcuts are not provided for objects on the page. Access to image maps is impossible for these users if alternatives are not provided.
- For image maps, provide alternative text for links (as discussed in A-1above.) [Priority 1]
- Provide keyboard shortcuts to links (including those in client-side image maps), form controls, and groupings of form controls. ("accesskey"). [Priority3]
- Create a logical tab orderthrough links and form controls. ("tabindex"). [Priority3]
Guideline: Provide interim solutions to facilitate operation via assistive technologies and older browsers [Priority 2]
Rationale: Older browsers are unable to "Tab" to edit boxes, textareas and lists of consecutive links, making it difficult to impossible for users to access them.
Users not operating in a graphical environment are disoriented by being transferred to a new window without warning.
Until most users are able to secure newer technologies that address these issues:
- Include default, place-holding characters in edit boxes and text areas. [Priority 3]
- Include non-link, printable characters (surrounded by spaces) between links that occur consecutively. [Priority 3]
- Do not use pop-up windows, new windows, or change active window unless the user is aware that this is happening. [Priority 2]
Provide meta-information for complex elements as orientation and contextual cues.
Guideline: For frames, provide sufficient information to determine the purpose of the frames and how they relate to each other. [Priority 1]
Rationale: Users with blindness and low vision often access the screen with "tunnel vision" and are unable to get an overview understanding of the page. Complex intertwinings of frames may also be difficult for people with cognitive disabilitiesto use.
Titles on frames allow user agents (browsers) to create a list of frames so users can keep track of them by name.
Note. If you use both "longdesc" and "d-link"or if you use "rel" to link the frame and d-link, a tool under development will be able to convert d-links to "longdesc" automatically.
- Provide titles for frames ("title"on FRAME) [Priority 1]
- When "longdesc"is supported by most browsers in use, use "longdesc"(where needed) to associate a fuller description (than is provided by the title) directly with the frame. Until then used-links to describe the frame more fully. [Priority 2]
Guideline: Properly markup abbreviations and acronyms. [Priority 2]
Unless expansions for abbreviations and acronyms are provided they may be indecipherable when spoken or brailled.
- For abbreviations use ABBR with "title" to specify the expansion. [Priority 2]
- For acronyms use ACRONYM with "title" to specify the expansion. [Priority 2]
Guideline: Group controls, selections, and labels into semantic units. [Priority2]
Rationale: Groupings provide meta-information about relationships between controls that are useful for all users
- Group form controls (FIELDSETand "legend") [Priority 2 for radio buttons and checkboxes, Priority 3 for other controls.]
- Associate labels to their controls (LABEL and "for") [Priority 2 for more than one control per line, Priority 3 otherwise.]
- Create a hierarchy of long lists of choices (OPTGROUP) [Priority 2]
Rationale: Many user agents restructure tables to present them. Without appropriate markup the tables will not make sense when restructured. Tables also present special problems to users of screen-readers.
These guidelines benefit users who are accessing the table auditorally or viewing only a portion of the page at a time ( users with blindness and low vision, or using an auto-pc, or devices with small displays)
- Until user agents and screen readers are able to handle text presented side-by-side, tables that produce text which is displayed as parallel word-wrapped columns require a linear text alternative. See last resorts [Priority 1]
- Provide summaries for tables ("SUMMARY" on TABLE) [Priority 3]
- Identify headers for Rows and Columns (TH) [Priority 2]
- Where tables have structural divisions beyond those implicit in the rows and columns (see HTML 4.0 table algorithm), use appropriate mark-up to identify those divisions (THEAD TFOOT TBODY AXIS SCOPE COLGROUP etc) [Priority 2]
- Provide abbreviations for header labels ("abbr" on TH) [Priority 3]
Guideline: Create link phrases that make sense when read out of context, but that are not too verbose. [Priority 3]
Rationale: Users who access a page auditorally ( users with blindness, low vision, or those using an auto-pc) often tab through the links on a page. If a link does not make sense when read out of context, they will have to stop to read around the link to gather the context.
- Create link phrases that make sense when read out of context that are not too verbose. [Priority 3]
E. General Recommendations
Guideline: Use elements, attributes, and style rules that comply with one of the W3CHTML or CSS specifications. [Priority 1]
Rationale: By avoiding proprietary elements and complying with a W3C specification you increase the likelihood that your page will be more consistent across platforms as well as more usable by a variety of populations. Use a "W3C validator" to check pages such as the HTML Validator Service[Priority 1].
- HTML specifications (HTML 2.0 or higher).
- CSS specifications
Guideline: Objects or elements that contain their own user interface should have accessibility built in.
Rationale: The accessibility of objects with their own interface is independent of the accessibility of the user agent. Accessibility must therefore be built into the objects.
- Where possible make applets directly accessible. [Priority 2]
Guideline: Ensure that there are accessible alternatives to information or functionality provided by active content such as scripts and applets. [Priority1]
Rationale: Many users can not run scripts or applets at all. The "fail gracefully" provisions would cover this situation. However, some users who can, but rely on assistive technology such as screen readers or special input devices may not be able to receive the information, or activate the functions that the content provides.
- Provide accessible alternatives to functions or information in the content of NOSCRIPT, APPLET, or OBJECT.
Guideline: If after best efforts, any page is still not accessible, provide a link to an alternative page that is accessible, has equivalent information, and is updated as often as the inaccessible page. [Priority 1]
Rationale: Some pages will be unable to fail gracefully at this time either because the visual components are too complex, or because assistive technologies or user agents (browsers) are lacking a specific feature.
Known instances when a text-only page will be needed (not a definitive list):
If you can not make a page accessible then do one of the following [Priority 1]:
- Complex tables, such as those of text and numbers - convert into a linear fashion.
- Create a second (accessible) page manually that is updated as frequently as the inaccessible page.
- Use a server-side script that creates an accessible version of the page on demand (may require special formatting or markup of page).
- Use a database to write pages on the fly in desired format.