contents

W3CWD-WAI-PAGEAUTH-19980918

WAI Accessibility Guidelines: Page Authoring

W3C Working Draft - 18 September 1998

This version:
http://www.w3.org/TR/1998/WD-WAI-PAGEAUTH-19980918
Latest version:
http://www.w3.org/TR/WD-WAI-PAGEAUTH
Previous versions:
http://www.w3.org/TR/1998/WD-WAI-PAGEAUTH-0414
http://www.w3.org/TR/1998/WD-WAI-PAGEAUTH-0203
Related documents:
Table Version of the Guidelines
Techniques
Editors:
Gregg Vanderheiden <gv@trace.wisc.edu>
Wendy Chisholm <chisholm@trace.wisc.edu>
Ian Jacobs <ij@w3.org>

Copyright  ©  1998 W3C (MIT, INRIA, Keio ), All Rights Reserved.

Abstract

This document is a list of guidelines that page authors should follow in order to make their pages more accessible for people with disabilities as well as more useful to other users, new page viewing technologies (mobile and voice), and electronic agents such as indexing robots. Tools that generate documents in HTML (authoring tools, file conversion packages, or other products) should make it easy for authors to produce documents that follow these guidelines. This document is part of a series of accessibility documents published by the Web Accessibility Initiative.

Accessibility does not mean minimal page design, it means thoughtful page design. These guidelines outline procedures for authors, particularly those using multimedia content, to ensure that the content and functions provided by those elements are available to all users. In general, authors should not be discouraged from using multimedia, but rather should use it in a manner which ensures that the material they publish is accessible to the widest possible audience.

Status of this document

This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". This is work in progress and does not imply endorsement by, or the consensus of, either W3C or members of the WAI GL Working Group.

This document has been produced as part of the W3C WAI Activity, and is intended as a draft of a Proposed Recommendation for authoring accessible Web pages. The goal of the WAI-GL working group is discussed in our charter.

Comments

Please send detailed comments on this document to w3c-wai-gl@w3.org. Public comments about the WAI author guidelines can  also be sent to this mailing list.

Table of Contents

Rating and Classification
A. Make sure pages transform gracefully across users, techniques, and situations
B. Provide context and orientation information for complex pages or elements
C. Maximize usability by following good design practices
Appendix A: Testing
Appendix B: Definitions
Appendix C: Index of guidelines by priority
Appendix D: Index of techniques by priority

Rating and Classification

[PRIORITY 1]
This guideline must be followed by an author, or one or more groups of users will find it impossible to access information in the document. Implementing this guideline is a basic requirement for some groups to be able to use Web documents.
[PRIORITY 2]
This guideline should be followed by an author, or one or more groups of users will find it difficult to access information in the document. Implementing this guideline will significantly improve access to Web documents.
[PRIORITY 3]
This guideline may be followed by an author to make it easier for one or more groups of users to access information in the document. Implementing this guideline will improve access to Web documents.

Each Guideline and each Technique has a priority listed. For the guidelines, the priority refers to the importance of addressing the issue identified by the guideline. For Techniques, the priority refers to which technique best improves accessibility with respect to this guideline. For example, a Priority 1 Guideline may have a Priority 1 Technique, which must be done to provide accessibility, and a Priority 3 Technique, which may also be done to help address the issue.

A. Transform Gracefully

Make sure pages transform gracefully across users, techniques, and situations

To "transform gracefully" means that a page remains usable despite user, technological, or situational constraints. In order to use the page at all, some users may need to "turn off" features specified by the author (font size, color combinations, etc.). For example, a person with low vision might need to display all text in 36-point font, so any formatting based on an author-determined font size will fall apart.

To create documents that transform gracefully, authors should:

  1. Ensure that all the information on the page may be perceived entirely visually and entirely through auditory means, and that all information is also available in text.
  2. Always separate the content on your site (what you say), and the way you choose to structure that content (how you organize it), from the way the content and structure are presented (how you want people to "see" it).
  3. Ensure that pages will be operable on various types of hardware including devices without mice, with small, low resolution, or black and white screens, with only voice or text output, without screens, etc.

Guidelines A.1 - A.12 address these issues.

A.1. Provide alternative text for all images, applets, and image maps. [Priority 1]

This includes images used as submit buttons, bullets in lists, and all of the links within an image map as well as invisible images used to layout a page. Alternative text does not describe the visual appearance of an image, applet, or image map. Rather, it is used to represent the function that the image, applet, or image map performs whether it be decorative, informative, or for purposes of layout. If alternative text is not provided, users who are blind, have low vision, or any user who cannot or has chosen not to view graphics will not know the purpose of the visual components on the page. Since "bare" ASCII art (characters that form images) does not allow alt-text, it must be marked up specially for this purpose.

Techniques:

  1. For all images (IMG) provide alt-text (via the "alt" attribute). [Priority 1] Note. This includes images used as image maps, spacers, bullets in lists, and links.
  2. For all applets (APPLET) provide alt-text (via the "alt" attribute) and content. [Priority 1]
  3. For all image map links (AREA)
  4. If server-side image maps must be used, provide text links for each hotspot in the image map. [Priority 1]
  5. For all graphical buttons (INPUT type="image"),
    1. Provide alt-text (via the "alt" attribute) [Priority 1]
    2. Do not use an image map to create a set of buttons in a form. Instead, use separate buttons or images (accompanied by alt-text). [Priority 2]
  6. Replace ASCII art with an image and alt-text. [Priority 1 or 2 depending on the importance of the information (e.g., an important chart)] Note. If the description of (important) ASCII art is long, provide a description in addition to alt-text (see A.2).
  7. If OBJECT is used to incorporate an image, applet, or script into a page, use any of the many ways to convey that information in cases where the OBJECT cannot be perceived (e.g., with "title" or within the body of the OBJECT element). [Priority 1]

A.2. Provide descriptions for important graphics, scripts, or applets if they are not fully described through alternative text or in the document's content. [Priority 1]

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.

Techniques:

  1. Provide a long description of all graphics that convey important information. To do so:
  2. If OBJECT is used to incorporate an image, applet, or script into a page, and it presents important information, use any of the many ways to provide a long description of the information in cases where the OBJECT cannot be perceived (e.g., within the body of the OBJECT element). [Priority 1]

A.3. Provide textual equivalents (captions) for all audio information [Priority 1]

If the audio is associated with a visual presentation (movie or animation), synchronize the textual equivalents with the visual presentation. Otherwise, users who are deaf, or hard of hearing, or any user who cannot or has chosen not to hear sound cannot perceive the information presented through speech, sound effects, music, etc.

Techniques:

  1. For stand-alone audio files provide a textual transcript of all words spoken or sung as well as all significant sounds. [Priority 1]
  2. For audio associated with video, provide a textual transcript (of dialog and sounds) synchronized with the video (e.g., captions). [Priority 1]
  3. Where sounds are played automatically, provide visual notification and transcripts. [Priority  1 or 2 depending on the importance of the sound]

A.4. Provide verbal descriptions of moving visual information in both auditory and text form (for movies, animations, etc.). [Priority 1]

If the visual presentation is associated with an auditory presentation (e.g., for a movie), synchronize the audio version of the descriptions with the existing auditory presentation and collate the text version of the descriptions with the text transcript (captions) of the primary audio track. Otherwise, if actions, body language, or other visual cues present information that is not expressed through auditory means as well (through dialogue, sound effects, etc.), users who cannot see (or look at) the page will not be able to perceive it. The collated text version allows access to the information by devices that do not play movies and by people who are deaf-blind.

Techniques:

  1. For short animations such as animated "gifs" images, provide alt-text (see A.1)and a long description (see A.2) if needed. [Priority 1]
  2. For movies, provide auditory descriptions that are synchronized with the original audio. [Priority 1]
  3. Provide a text version of the auditory description that is collated with the text transcript (captions) of the primary audio track. [Priority 2]

A.5. Ensure that text and graphics are perceivable and understandable when viewed without color. [Priority 1]

Otherwise, if color is used to convey information, users who cannot differentiate between certain colors (and users with devices that have non-color or non-visual displays) will not receive the information.
When foreground and background colors are too close to the same hue, they may not provide sufficient contrast when viewed using monochrome displays or by people with different types of color blindness.

Techniques:

  1. Don't use color to convey information unless the information is also clear from the markup and/or text. [Priority 1]
  2. Use foreground and background color combinations that provide sufficient contrast when viewed by someone with color blindness or when viewed on a black and white screen. [Priority 1]

A.6. Indicate structure with structural elements, and control presentation with presentation elements and style sheets. [Priority 2]

When structural elements and attributes are used to create presentation effects, user agents that allow users to navigate through the structure will be unable to do so properly. Such practices also make it difficult to render the page on other media and devices. For instance, don't use H1 to create large, bold face text unless that text is actually a top-level heading.

Techniques:

  1. Nest headings properly (H1 - H6). [Priority 2]
  2. Encode list structure and list items properly (UL, OL, DL, LI). [Priority 2]
  3. Mark up quotations with the Q and BLOCKQUOTE elements. Do not use them for formatting effects such as indentation. [Priority 2]
  4. Use style sheets to control layout and presentation wherever possible as soon as a majority of browsers in use support them well (see A.9). Until then, simple tables (to control layout) and bitmap text with alt-text (for special text effects) may be used, with alternative pages used as necessary to ensure that the information on the page is accessible (see C.1). [Priority 2]
  5. Use relative sizing and positioning (e.g., percent) rather than absolute (e.g., pixels or point). [Priority 2]

A.7. Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused or frozen. [Priority 1]

This is particularly important for objects that contain text and does not apply to instant redirection. 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. People with photosensitive epilepsy can have seizures triggered by flickering or flashing in the 4 to 59 flashes per second (Hertz) range with a peak sensitivity at 20 flashes per second.

Techniques:

  1. Movement should be avoided when possible, but if it must be used, provide a mechanism to allow users to freeze motion or updates in applets and scripts or use style sheets and scripting to create movement. (see also A.10) [Priority 2]
  2. For auto-refreshing or timed response pages, provide a second copy of the page where refresh only happens after a link has been selected (until user agents provide this ability themselves). [Priority 1]
  3. Avoid any blinking or updating of the screen that causes flicker. [Priority 1]

Note 1. BLINK and MARQUEE are not defined in any W3C HTML specification and should not be used. See C.1

Note 2. See also A.4.1 which discusses animated "gifs."

A.8. Provide supplemental information needed to pronounce or interpret abbreviated or foreign text. [Priority 2]

Unless changes between multiple languages on the same page are identified, and expansions for abbreviations and acronyms are provided, they may be indecipherable when spoken or brailled.

Techniques:

  1. Use the "lang" attribute to clearly identify changes in the language of text. [Priority 2]
  2. For abbreviations and acronyms use either ABBR or ACRONYM with the "title" attribute to specify the expansion. [Priority 2]

A.9. Ensure that pages using newer W3C features (technologies) will transform gracefully into an accessible form if the feature is not supported or is turned off. [Priority 1]

Some more recent features that are not completely backwards compatible include frames, scripts, style sheets, and applets. Each release of HTML has included new language features. For example, HTML 4.0 added the ability to attach style sheets to a page and to embed scripts and applets into a page. 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 unusable page when new features do not transform gracefully. For example, if you specify an image as the source of a frame (via the "src" attribute), then there is no simple way to attach alt-text (see A.1) to that image.

Techniques:

  1. Frames:
    1. Provide a fallback page for pages that contain frames (e.g., by using NOFRAME). [Priority 1]
    2. Ensure that the source of each frame is an HTML file. [Priority 1]
  2. For scripts that present critical information or functions, provide an alternative, equivalent presentation or mechanism (e.g., by using NOSCRIPT). [Priority 1]
  3. For pages that use style sheets, ensure that the contents of each page are ordered and structured so that they read appropriately without the style sheet. [Priority 1]
  4. Applets: (embedded using OBJECT or APPLET)
    1. At a minimum:
    2. If possible, provide an alternative function or presentation in a format other than an applet. For example, a canned "mpeg" movie of a physics simulation (written in Java) or a single frame of the animation saved as a "gif" image. [Priority 2]


See also C.1.2 - alternative pages.

A.10. Elements that contain their own user interface should have accessibility built in. [Priority 2]

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 or an alternative must be provided (see A.11.4).

Technique:

  1. Where possible make applets directly accessible (see also A.9.4). [Priority 1 if information or functionality is important, and not presented elsewhere,otherwise Priority 2]

A.11. Use features that enable activation of page elements via input devices other than a pointing device (e.g., via keyboard, voice, etc.). [Priority 1]

Someone who is using the page without sight, with voice input, or with a keyboard (or input device other than a pointing device, e.g., a mouse or braille display) will have a difficult time navigating a page if operation requires a pointing device. If a page is usable via a keyboard, it is more likely that it should also be operable via speech input, or a command line interface. Access to image maps is impossible for these users if alternatives are not provided.

Techniques:

  1. For image maps, provide alternative text for links. [Priority 1] (see also A.1)
  2. If possible, ensure that all elements that have their own interface are keyboard operable (see also A.11). [Priority 2]
  3. Create a logical tab order through links, form controls, and objects (via the "tabindex" attribute or through logical page design). [Priority 3]
  4. Provide keyboard shortcuts (via the "accesskey" attribute) to links (including those in client-side image maps), form controls, and groups of form controls). [Priority 3]

A.12. Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly. [Priority 2]

Older browsers are unable to "Tab" to edit boxes, text areas 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.

Techniques:

Until most users are able to secure newer technologies that address these issues:

  1. Include default, place-holding characters in edit boxes and text areas. [Priority 3]
  2. Include non-link, printable characters (surrounded by spaces) between links that occur consecutively. [Priority 3]
  3. Do not use pop-up windows, new windows, or change active window unless the user is aware that this is happening. [Priority 2]
  4. For all form controls with labels, ensure that the label that is either:
  5. Until user agents and screen readers are able to handle text presented side-by-side, all tables that lay out text in parallel, word-wrapped columns require a linear text alternative (on the current page or some other). [Priority 2]

B. Context and Orientation

Provide context and orientation information for complex pages or elements.

To provide context and orientation information means that additional information is provided to help users gain an understanding of the "big picture" presented by a page, table, frame, or form. Oftentimes users are limited to viewing only a portion of a page, either because they are accessing the page one word at a time (speech synthesis or braille display), or one section at a time (small display, or a magnified display).

To create documents that provide context and orientation information, authors should:

  1. Structure and group information.
  2. Clearly label the structure and groups.

Guidelines B.1-B.3 address these issues.

B.1. For frames, provide sufficient information to determine the purpose of the frames and how they relate to each other. [Priority 1]

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 relationships between frames may also be difficult for people with cognitive disabilities to use.

Techniques:

  1. Provide titles for frames (via the "title" attribute on FRAME) so that users can keep track of frames by name. [Priority 1]
  2. Use "longdesc" (where needed) to associate a more complete description (than is provided by the title) directly with the frame. Until "longdesc" is widely supported, also use a d-link or invisible d-link. [Priority 2]

B.2. Group controls, selections, and labels into semantic units. [Priority 2]

This provides contextual information about the relationship between controls, which is useful for all users.

Techniques:

  1. Group form controls (using the FIELDSET and LEGEND elements). [Priority 2 for radio buttons and checkboxes, Priority 3 for other controls.]
  2. Associate labels to their controls (using LABEL and its "for" attribute). [Priority 2]
  3. Create a hierarchy of long lists of choices (with OPTGROUP). [Priority 2]

 

B.3. Ensure that tables (not used for layout) have necessary markup to be properly restructured or presented by accessible browsers and other user agents. [Priority 1]

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 that are accessing the table through auditory means (e.g., an Automobile PC which operates by speech input and output) or viewing only a portion of the page at a time (e.g., users with blindness or low vision using speech or a braille display, or other users of devices with small displays, etc.).

Techniques:

  1. Provide summaries for tables (via the "summary" attribute on TABLE). [Priority 3]
  2. Identify headers for rows and columns (TD and TH). [Priority 2]
  3. Where tables have structural divisions beyond those implicit in the rows and columns, use appropriate markup to identify those divisions (THEAD, TFOOT, TBODY, COLGROUP, the "axis" and "scope" attributes, etc.). [Priority 2]
  4. Provide abbreviations for header labels (via the "abbr" attribute on TH). [Priority 3]

B.4. Wherever possible, create "good" link phrases. [Priority 2]

"Good" link phrases:

"Auditory users," people who are blind, have difficulty seeing, or who are using devices with small or no displays are unable to scan the page quickly with their eyes and often use a list of links to get an overview of a page or to quickly find a link. When links are not descriptive enough, do not make sense when read out of context, or are not unique, the auditory user must stop to read the text surrounding each link to identify it.

Wherever possible:

  1. If more than one link shares the same textual phrase, all those links should point to the same resource. [Priority 2]
  2. Avoid phrases that are not meaningful on their own such as "click here." [Priority 2]
  3. Avoid creating link phrases that contain full sentences. [Priority 2]

C. Good Practices

Maximize usability by following good design practices.

Good design is accessible design and vice-versa. For instance, many of the practices that lead to more accessible pages also make them accessible to indexing engines as well as more usable by all users. Good design practices include consistency, generality, simplicity, reuse, and validation.

C.1. Only use technologies defined in a W3C specification and use them in an accessible manner. Where not possible, provide an accessible alternative page that does. [Priority 1]

Many non-HTML technologies (e.g., PDF, Shockwave, and other non-W3C data formats) used to encode information require either plug-ins or stand-alone applications that often create pages that cannot be viewed or navigated using standard Web access tools. Also, W3C technologies may be used in ways that do not transform gracefully (e.g., because the visual components are too complex, or because assistive technologies or user agents (browsers) are lacking a specific feature).  By avoiding non-standard features (elements, attributes, properties, etc. only supported by a specific browser type) and ensuring that all technologies transform gracefully, your pages will be accessible to more people using a wider variety of hardware and software.

Note. Not all PDF pages are accessible or readable after being run through a PDF translator. Individually test each page for readability after the translation process. If a page does not automatically translate, revise the page until its PDF representation converts appropriately through the publicly-available converter(s) or prepare and post an HTML or plain text equivalent.

  1. If W3C technologies are used:
    1. Use the latest W3C specifications whenever possible. [Priority 2]
    2. Avoid deprecated elements whenever possible. [Priority 2]
  2. If, after all of your best efforts, you can not avoid using a non-W3C technology or any W3C technology in an accessible way then you MUST provide a link to an alternative page that: [Priority 1]
    Note.  Because of the  difficulty in keeping alternative pages up to date with the full content of the original page, alternative pages should be provided only after you have tried all of the other pertinent techniques outlined in this document to make your original page accessible (unless the alternative page is automatically generated from the same source as the original page).
    Guidelines and methods for creating alternative pages

C.2. Provide mechanisms that facilitate navigation within your site. [Priority 3]

Through good design, increase the chance that a person can easily find what they are looking for and can easily navigate throughout the site. Consistent page layouts between pages and a clear navigation structure will not only benefit people with cognitive disabilities, but everyone that visits your site.

To decrease the amount of sifting readers perform to find important information, place distinguishing information at the beginning of headings, paragraphs, lists, etc. This is commonly referred to as "front-loading" and is especially helpful for people accessing information serially.

  1. Create a consistent style of presentation between pages. [Priority 3]
  2. Use a clear, consistent navigation structure. [Priority 3]
  3. Offer navigation bars for easy access to the navigation structure. [Priority 3]
  4. Provide a description of the general layout of the site, the access features used, and how to use them. [Priority 3]
  5. Offer a site map. [Priority 3]
  6. Offer different types of searches for different skill levels and preferences. [Priority 3]
  7. Place distinguishing information at the beginning of headings, paragraphs, lists, etc. [Priority 3]

C.3. Create a single downloadable file for documents that exist as a series of separate pages. [Priority 3]

This helps people reading documents off-line. Currently, an archival or compression program is needed to create the single file. In the near future, user agents will be able to collate separate pages based on meta information.

  1. Indicate which is the first page of the document and which page follows the current one. (e.g., by using LINK). [Priority 3]
  2. Create a bundled version of all pages that comprise the document. [Priority 3]

Appendix A: Testing

Validate your pages and assess the accessibility with automated tools, manual tests, and other services.

It is important to test your site with various types of browsers, older versions of current browsers, and services that emulate browsers. Testing your site with a variety of browsers and other services will allow you to gain firsthand experience of some of the issues people deal with. Adjustments to your design based on the results of tests will increase the likelihood that your site will be usable by a wide range of people and technologies.

  1. Use an automated accessibility, and browser validation tool.
  2. Use the W3C HTML Validation Service, available at http://validator.w3.org/
  3. Use the W3C CSS Validation Service, available at http://jigsaw.w3.org/css-validator/
  4. Use a text-only browser or emulator
  5. Use multiple graphic browsers, with:
  6. It may also be helpful to test a site with a self-voicing browser, a screen reader, magnification software, a small display, etc..

Appendix B: Definitions

Applet
A program inserted into a Web page.
ASCII art
ASCII art refers to text characters and symbols that are combined to create an image. For example ";-)" is the smiley emoticon and the following drawing represents a cow. 
          (__)             
          (oo)   
   /-------\/          
  / |     ||
 *  ||----||             
    ^^    ^^
Backwards compatible
Something that has been designed to work with earlier versions of a language, program, etc.
Braille
Braille uses six raised dots in different patterns to represent letters and numbers to be read by people who are blind with their fingertips. Dynamic braille involves the use of a display where dot patterns are raised and lowered electronically.
Accessible The word "Accessible" in braille.
Image
A graphical presentation.
Image map
An image that has been divided into regions; clicking in a region causes an action to occur.
Important
Something is important if understanding it in detail is necessary for the overall understanding of a document.
Instant redirection
A page is loaded but immediately replaced by another due to meta information in the transient document.
Page authors
Those who are creating Web pages.
Screen magnifier
A software program that magnifies a portion of the screen, so that it can be more easily viewed. Used primarily by individuals with low vision.
Screen reader
A software program that reads the contents of the screen aloud to a user. Used primarily by individuals who are blind, screen readers can usually only read text that is printed, not painted, to the screen.

Appendix C: Guidelines by Priority

Priority 1
  1. A.1. Provide alternative text for images, applets, and image maps
  2. A.2. Provide descriptions for important graphics, scripts, or applets if they are not fully described through alternative text or in the document's content.
  3. A.3. Provide textual equivalents for audio information
  4. A.4. Provide verbal descriptions of moving visual information in both auditory and text form
  5. A.5. Ensure that text and graphics are perceivable and understandable when viewed without color
  6. A.7. Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused or frozen
  7. A.9. Ensure that pages using newer W3C features (technologies) will transform gracefully into an accessible form
  8. A.11. Use features that enable activation of page elements via input devices other than a pointing device (e.g., via keyboard, voice, etc.).
  9. B.1. For frames, provide sufficient information to determine the purpose of the frames and how they relate to each other
  10. B.3. Ensure that tables (not used for layout) have necessary markup to be properly restructured or presented by accessible browsers and other user agents
  11. C.1. Only use technologies defined in a W3C specification and use them in an accessible manner. Where not possible, provide an accessible alternative page that does..
Priority 2
  1. A.6. Indicate structure with structural elements, and control presentation with presentation elements and style sheets
  2. A.8. Provide supplemental information needed to pronounce or interpret abbreviated or foreign text.
  3. A.10. Elements that contain their own user interface should have accessibility built in
  4. A.12. Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly.
  5. B.2. Group controls, selections, and labels into semantic units
  6. B.4. Wherever possible, create good link phrases
Priority 3
  1. C.2. Provide mechanisms that facilitate navigation within your site.
  2. C.3. Create a single downloadable file for documents that exist as a series of separate pages

Appendix D: Techniques by priority

Priority 1
  1. A.1.1. For all images (IMG) provide alt-text (via the "alt" attribute). Note. This includes images used as spacers, bullets in lists, and links.
  2. A.1.2. For all applets (APPLET) provide alt-text (via the "alt" attribute) and content.
  3. A.1.3. For all image map links (AREA)
  4. A.1.4. If server-side image maps must be used, provide text links for each hotspot in the image map.
  5. A.1.5. For all graphical buttons (INPUT type="image") provide alt-text (via the "alt" attribute)
  6. A.1.6. Replace ASCII art with an image and alt-text. [Priority 1 or 2 depending on the importance of the information (e.g., an important chart)]
  7. A.1.7. If OBJECT is used to incorporate an image, applet, or script into a page, use any of the many ways to convey that information in cases where the OBJECT cannot be perceived, such as with "title" or within the body of the OBJECT element. [Priority 1]
  8. A.2.1. Provide a long description of all graphics that convey important information. To do so:
    • Use "longdesc".
    • Until most browsers support "longdesc", also use a d-link (or invisible d-link).
  9. A.2.2. If OBJECT is used to incorporate an image, applet, or script into a page, and it presents important information, use any of the many ways to convey that information in cases where the OBJECT cannot be perceived.
  10. A.3.1. For stand-alone audio files provide a textual transcript of all words spoken or sung as well as all significant sounds.
  11. A.3.2. For audio associated with video, provide a textual transcript (of dialog and sounds) synchronized with the video (e.g., captions).
  12. A.3.3. Where sounds are played automatically, provide visual notification and transcripts. [Priority  1 or 2 depending on the importance of the sound]
  13. A.4.1. For short animations such as animated "gifs" images, provide alt-text (see A.1) and a long description (see A.2) if needed.
  14. A.4.2. For movies, provide auditory descriptions that are synchronized with the original audio.
  15. A.5.1. Don't use color to convey information unless the information is also clear from the markup and/or text.
  16. A.5.2. Use foreground and background color combinations that provide sufficient contrast when viewed by someone with color blindness or when viewed on a black and white screen.
  17. A.7.2. For auto-refreshing or timed response pages, provide a second copy of the page where refresh only happens after a link has been selected (until user agents provide this ability themselves).
  18. A.7.3. Avoid any blinking or updating of the screen that causes flicker.
  19. A.9.1. Provide a fallback page for pages that contain frames (e.g., by using NOFRAME).
  20. A.9.2. For scripts that present critical information or functions, provide an alternative, equivalent presentation or mechanism (e.g., by using NOSCRIPT).
  21. A.9.3. For pages that use style sheets, ensure that the contents of each page are ordered and structured so that they read appropriately without the style sheet.
  22. A.9.4. Applets: (embedded using OBJECT or APPLET) At a minimum:
  23. A.11.1. For image maps, provide alternative text for links. (see also A.1)
  24. B.1.1. Provide titles for frames (via the "title" attribute on FRAME) so that users can keep track of frames by name.
  25. C.1.2.If, after all of your best efforts, you can not avoid using a non-W3C technology or any W3C technology in an accessible way then you MUST provide a link to an alternative page that:
    • uses W3C technologies,
    • is accessible,
    • has equivalent information,
    • is updated as often as the inaccessible (original) page

    Guidelines and methods for creating alternative pages

Priority 2
  1. A.4.3. Provide a text version of the auditory description that is collated with the text transcript (captions) of the primary audio track.
  2. A.6.1. Nest headings properly (H1 - H6).
  3. A.6.2. Encode list structure and list items properly (UL, OL, DL, LI).
  4. A.6.3. Mark up quotations with the Q and BLOCKQUOTE elements. Do not use them for formatting effects such as indentation.
  5. A.1.5. Do not use an image map to create a set of buttons in a form. Instead, use separate buttons or images (accompanied by alt-text).
  6. A.6.4. Use style sheets to control layout and presentation wherever possible as soon as a majority of browsers in use support them well (see A.9). Until then, simple tables (to control layout) and bitmap text with alt-text (for special text effects) may be used, with alternative pages used as necessary to ensure that the information on the page is accessible (see C.1).
  7. A.6.5. Use relative sizing and positioning (e.g., percent) rather than absolute (e.g., pixels or point).
  8. A.7.1. Movement should be avoided when possible, but if it must be used, provide a mechanism to allow users to freeze motion or updates in applets and scripts or use style sheets and scripting to create movement. (see also A.10)
  9. A.8.1. Use the "lang" attribute to clearly identify changes in the language of text.
  10. A.8.2. For abbreviations and acronyms use either ABBR or ACRONYM with the "title" attribute to specify the expansion.
  11. A.9.4.2. For applets, if possible, provide an alternative function or presentation in a format other than an applet. For example, a canned "mpeg" movie of a physics simulation (written in Java) or a single frame of the animation saved as a "gif" image.
  12. A.10.1. Where possible make applets directly accessible (see also A.9.4).
  13. A.12.5. Until user agents and screen readers are able to handle text presented side-by-side, all tables that lay out text in parallel, word-wrapped columns require a linear text alternative (on the current page or some other).
  14. A.12.3. Do not use pop-up windows, new windows, or change active window unless the user is aware that this is happening.
  15. A.12.4. For all form controls with labels, ensure that the label that is either:
  16. B.1.2. Use "longdesc" (where needed) to associate a more complete description (than is provided by the title) directly with the frame. Until "longdesc" is widely supported, also use a d-link or invisible d-link.
  17. B.2.1. Group form controls (using the FIELDSET and LEGEND elements). [Priority 2 for radio buttons and checkboxes, Priority 3 for other controls.]
  18. B.2.2. Associate labels to their controls (using LABEL and its "for" attribute).
  19. B.2.3. Create a hierarchy of long lists of choices (with OPTGROUP).
  20. B.3.2. Identify headers for rows and columns (TD and TH).
  21. B.3.3. Where tables have structural divisions beyond those implicit in the rows and columns, use appropriate markup to identify those divisions (THEAD, TFOOT, TBODY, COLGROUP, the "axis" and "scope" attributes, etc.).
  22. B.4. Wherever possible:
    1. If more than one link shares the same textual phrase, all those links should point to the same resource.
    2. Avoid phrases that are not meaningful on their own such as "click here."
    3. Avoid creating link phrases that contain full sentences.
  23. C.1.1.1. Use the latest W3C specifications whenever possible.
  24. C.1.1.2. Avoid deprecated elements whenever possible.
Priority 3
  1. A.11.3. Create a logical tab order through links, form controls, and objects (via the "tabindex" attribute or through logical page design).
  2. A.11.4. Provide keyboard shortcuts (via the "accesskey" attribute) to links (including those in client-side image maps), form controls, and groups of form controls).
  3. A.12.1. Include default, place-holding characters in edit boxes and text areas.
  4. A.12.2. Include non-link, printable characters (surrounded by spaces) between links that occur consecutively.
  5. B.3.1. Provide summaries for tables (via the "summary" attribute on TABLE).
  6. B.3.4. Provide abbreviations for header labels (via the "abbr" attribute on TH).
  7. C.2.1. Create a consistent style of presentation between pages.
  8. C.2.2. Use a clear, consistent navigation structure.
  9. C.2.3. Offer navigation bars for easy access to the navigation structure.
  10. C.2.4. Provide a description of the general layout of the site, the access features used, and how to use them.
  11. C.2.5. Offer a site map.
  12. C.2.6. Offer different types of searches for different skill levels and preferences.
  13. C.2.7. Place distinguishing information at the beginning of headings, paragraphs, lists, etc.
  14. C.3.1. Indicate which is the first page of the document and which page follows the current one. (e.g., by using LINK).
  15. C.3.2. Create a bundled version of all pages that comprise the document.

contents