WD-WAI-PAGEAUTH-CHKLIST-19990217

Checklist for Web Content Accessibility Guidelines

W3C Working Draft 17-Feb-1999

This version:: http://www.w3.org/TR/1999/WD-WAI-PAGEAUTH-19990217/full-checklist
For this version of Web Content Accessibility Guidelines:: http://www.w3.org/TR/1999/WD-WAI-PAGEAUTH-19990217
Latest version of Web Content Accessibility Guidelines:: http://www.w3.org/TR/WD-WAI-PAGEAUTH

Editors:: Wendy Chisholm <chisholm@trace.wisc.edu>
Gregg Vanderheiden <gv@trace.wisc.edu>
Ian Jacobs <ij@w3.org>

Abstract

This document, which accompanies the "Web Content Accessibility Guidelines", is a checklist for Web content developers. Each checkpoint in the guidelines appears in the checklist below, organized by concept.

This document is part of a series of accessibility documents published by the Web Accessibility Initiative.

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. The goal of the WAI-GL working group is discussed in our charter.

Priorities

Each checkpoint in this checklist is assigned a priority:

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

In general

Priority 1 Checkpoints	Yes	No	N/A
A.5.1 Don't use color to convey information unless the information is also clear from the markup and/or text.
A.5.2 Use foreground and background color combinations that provide sufficient contrast when viewed by someone with color deficits or when viewed on a black and white screen.
A.9.4 For pages that use style sheets or presentational markup, ensure that the contents of each page are ordered and structured so that they may read properly even when the style sheet or presentational markup is overridden by the user.
A.10.1 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).
A.10.2 Avoid any blinking or updating of the screen that causes flicker.
Priority 2 Checkpoints	Yes	No	N/A
A.6.1 Nest headings properly (e.g., in HTML, H1 - H6).
A.6.2 Encode list structure and list items properly (e.g., in HTML: UL, OL, DL, LI).
A.6.3 Mark up quotations (e.g., with the Q and BLOCKQUOTE elements in HTML). Do not use quotation markup for formatting effects such as indentation.
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 also 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 also A.14).
A.6.6 Use relative sizing and positioning (e.g., percent values) rather than absolute (e.g., pixel or point values).
A.7.1 Clearly identify changes in the language of text (e.g., the HTML "lang" attribute, configure your server to take advantage of content negotiation mechanisms to allow browsers to retrieve files of the preferred language automatically).
A.7.2 Specify the expansion of abbreviations and acronyms (e.g., with the "title" attribute of the HTML ABBR or ACRONYM elements).
A.14.1 If W3C technologies are used (e.g. MathML, SMIL, HTML, XML, etc.), use the latest W3C specification whenever possible.
A.14.2 If W3C technologies are used, avoid deprecated language features whenever possible.
B.2.1 Wherever possible, make link phrases as terse as possible yet as meaningful as possible when read on their own or in succession. Avoid non-meaningful phrases, such as "click here."
B.3.1 Use the simplest and most straightforward language that is possible for the content of your site.
Priority 3 Checkpoints	Yes	No	N/A
A.12.3 Create a logical tab order through links, form controls, and objects (e.g., in HTML, via the "tabindex" attribute or through logical page design).
A.12.4 Provide keyboard shortcuts to links, including those in client-side image maps, form controls, and groups of form controls (e.g., in HTML, via the "accesskey" attribute).
A.14.4 Indicate what type of resource you are linking to, especially when linking to resources that are not W3C technologies, For example, to link to a PDF file from an HTML document, set the "type" attribute to "application/pdf" on the A element.
B.2.2 Use a clear, consistent navigation structure.
B.2.3 Offer navigation bars for easy access to the navigation structure.
B.2.4 Offer a site map.
B.2.5 Provide a description of the general layout of the site, the access features used, and how to use them.
B.2.6 Offer different types of searches for different skill levels and preferences.
B.2.7 Place distinguishing information at the beginning of headings, paragraphs, lists, etc.
B.2.8 Facilitate off-line browsing by creating a single downloadable file for documents that exist as a series of separate pages (e.g., by using the HTML LINK element, or creating a "zip" archive).
B.2.9 Group related links, such as links used to create a navigation bar, and attach a meaningful title on the element creating the group (e.g., in HTML use "title" on FRAME, DIV, SPAN, etc. Use class="nav" on elements creating navigation groups).
B.2.10 Provide a link at the beginning of a group of related links to bypass the group.
B.3.2 Use icons or graphics (with alternative text) where they facilitate comprehension of the page.
B.3.3 Create a consistent style of presentation between pages.

And if you use images and image maps

Priority 1 Checkpoints	Yes	No	N/A
A.1.1 Provide alternative text for all images (e.g., in HTML, via the "alt" attribute of the IMG and INPUT elements, or via "title" or within the content of OBJECT). Note. This includes images used as image maps, spacers, bullets in lists, graphical buttons, links, and to present math equations.
A.1.3 For all image map links, provide text for each link (e.g., via the "alt" attribute of HTML AREA element or by using the MAP element with anchors defined with the A element).
A.1.6 For ASCII art, either replace it with an image and alternative text or provide a description and a means to skip over the art (e.g., a link). [Priority 1] or [Priority 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 alternative text. (See also A.2)
A.2.1 Provide a long description of all graphics, scripts, or applets that convey important information (e.g., in HTML, via "longdesc" on IMG, with a d-link (or an invisible d-link), or as content of OBJECT).
A.12.1 For image maps, provide alternative text for links. (See also A.1)
Priority 2 Checkpoints	Yes	No	N/A
A.1.4 For all image map links, provide redundant textual links. [Priority 2] if client-side image maps are used, [Priority 1] for server-side.
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 alternative text).

And if you use tables

Priority 1 Checkpoints	Yes	No	N/A
A.8.1 If a table is used for layout, do not use any structural markup for the purpose of visual formatting. For example, in HTML do not use the table header (TH) element to cause the contents of a cell to be displayed centered and in bold. Other attributes of a table, such as a caption describing the layout purpose and content of columns is valuable, particularly if some cells become navbars, frames, images, imagemaps, or lists of links.
A.8.2 For data tables, identify headers for rows and columns (e.g., the HTML TD and TH elements).
A.8.3 For data tables that have more than one row and/or more than one column of header cells, use markup to associate data cells and header cells (e.g., in HTML, THEAD, TFOOT, TBODY, COLGROUP, the "axis", "scope", and "headers" attributes, etc.).
Priority 2 Checkpoints	Yes	No	N/A
A.13.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 3 Checkpoints	Yes	No	N/A
A.8.4 Provide summaries for tables (e.g., via the "summary" attribute on HTML TABLE elements).
A.8.5 Provide abbreviations for header labels (e.g., in HTML, the "abbr" attribute on TH).

And if you use frames

Priority 1 Checkpoints	Yes	No	N/A
A.9.2 Ensure that descriptions of dynamic content are updated with changes in content (e.g., in HTML,
B.1.1 Title each frame so that users can keep track of frames by title (e.g., via the "title" attribute on HTML FRAME elements).
Priority 2 Checkpoints	Yes	No	N/A
A.9.1 Provide a fallback page for pages with dynamic content (HTML examples: NOFRAMES at the end of each frameset, NOSCRIPT for every script, server-side scripts instead of client-side).
B.1.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone. (e.g., in HTML, use "longdesc," or a d-link).

And if you use forms

Priority 2 Checkpoints	Yes	No	N/A
A.13.4 For all form controls with implicitly associated labels, ensure that the label is properly positioned. The label must immediately precede its control on the same line (allowing more than one control/label per line) or be on the line before the control (with only one label and one control per line).
B.1.3 Group form controls (e.g., in HTML use the FIELDSET and LEGEND elements). [Priority 2] for radio buttons and checkboxes, [Priority 3] for other controls.
B.1.4 Associate labels explicitly with their controls (e.g., in HTML use LABEL and its "for" attribute).
B.1.5 Divide long lists of choices into groups (e.g., with the HTML OPTGROUP element).
Priority 3 Checkpoints	Yes	No	N/A
A.13.2 Include default, place-holding characters in edit boxes and text areas (e.g., TEXTAREA and INPUT in HTML).
A.13.3 Include non-link, printable characters (surrounded by spaces) between links that occur consecutively.

And if you use applets and scripts

Priority 1 Checkpoints	Yes	No	N/A
A.1.2 Provide alternative text for all applets and other programmatic objects (e.g., in HTML, via the "alt" attribute or within the content of APPLET, or via the "title" attribute or within the content of OBJECT). (See also A.11)
A.9.3 For scripts that present critical information or functions, provide an alternative, equivalent presentation or mechanism (e.g., by using NOSCRIPT in HTML, or a server-side script).
Priority 2 Checkpoints	Yes	No	N/A
A.9.5 For applets and programmatic objects, when 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.
A.10.3 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.11)
A.11.1 Where possible, make programmatic elements, such as scripts and applets, directly accessible. (See also A.9). [Priority 1] if information or functionality is important, and not presented elsewhere, otherwise [Priority 2].
A.12.2 If possible, ensure that all elements that have their own interface are keyboard operable. (See also A.12)
A.13.1 Do not use pop-up windows, new windows, or change active window unless the user is aware that this is happening.

And if you use multimedia

Priority 1 Checkpoints	Yes	No	N/A
A.3.1 For stand-alone audio files, provide a textual transcript of all words spoken or sung as well as all significant sounds.
A.3.2 For audio associated with video, provide a textual transcript (of dialog and sounds) synchronized with the video (e.g., captions).
A.3.3 Where sounds are played automatically, provide visual notification and transcripts. [Priority 1] or [Priority 2] depending on the importance of the sound.
A.4.1 For short animations such as animated "gifs" images, provide alternative text (See also A.1) and a long description (See also A.2) if needed.
A.4.2 For movies, provide auditory descriptions that are synchronized with the original audio.
Priority 2 Checkpoints	Yes	No	N/A
A.4.3 Provide text version of the auditory description that is collated with the text transcript (captions) of the primary audio track.

And if all else fails

Priority 1 Checkpoints	Yes	No	N/A
A.14.3 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, and is updated as often as the inaccessible (original) page.