W3C

Techniques For Evaluation And Implementation Of Web Content Accessibility Guidelines - 0.10

W3C Working Draft

This version:
http://www.w3.org/WAI/ER/IG/ert/ert-19991215.html
Latest version:
http://www.w3.org/WAI/ER/IG/ert/
Previous version:
http://www.w3.org/WAI/ER/IG/ert/ert-19991123.html
Editors:
Chris Ridpath, Adaptive Technology Resource Centre, University of Toronto-- Canada

Abstract

This document describes techniques that may be used by software programs in evaluating the conformance of HTML documents to The WAI Web Content Accessibility Guidelines. It also describes methods that may be used in software programs for modifying HTML documents so that they conform to these guidelines.

Status Of This Document

This is a work in progress and will be under constant revision. The goal is to have a first version of the document ready by October 31, 1999. The reason for such a short timeline is that this document will be used in the creation of software programs (e.g. A-Prompt, Bobby) and we want the software to be completed as soon as possible so that we may receive user feedback. Once we have user comments and suggestions we can return to this document for revisions and updates.

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.

This document has been produced as part of the W3C Web Accessibility Initiative. The goal of the Web Content Guidelines Working Group is discussed in the Working Group charter.

Table of Contents


Introduction

The Web Accessibility Initiative (WAI) produced a foundation document, The WAI Web Content Accessibility Guidelines, that describes what must be done to make an HTML page accessible to all. This document trys to make clear that the WWW should enable everyone, especially those with disabilities.

To determine if a web site is accessible to everyone, it is important to have functional, friendly and free tools for site evaluation and, if possible, repair of problems that may be uncovered. This document describes techniques that may be used by such 'evaluation and repair' tools to uncover accessibility problems and possibly repair them. These techniques may be used by those who create web authoring tools or by anyone interested in creating accessible web documents.

It is important that evaluation and repair tools themselves be accessible. Many people using these tools may be new to this technology and will require software programs that are easy to use while not condescending in tone. Is also important that the evaluation tool does not generate excessive warnings or false positive accessibility errors to avoid the 'cry wolf' syndrome.

It is clear that only a limited set of the WAI Guideline's checkpoints may be objectively tested by a software tool. There will still be a dependence on the user's ability to use common sense to determine conformance to the guidelines. It is imperative that any tool have features that assist in reminding, without nagging; in helping, without demeaning; in suggesting, without demanding. We hope that the techniques in this document, implemented in software programs, will gently guide authors along the path to more accessible documents.

Structure Of This Document

This document is based on The WAI Web Content Accessibility Guidelines. It examines each checkpoint in the guidelines and provides one or more techniques for the implementation of that checkpoint. Each implementation technique contains the following items:

Title:
The WAI guidelines checkpoint
Definition:
A technique to check for checkpoint compliance
Discussion Status:
Awaiting discussion, under discussion, discussion complete
Evaluation:
The HTML element(s) that must be examined
example language:
Messages displayed to the author if a problem is found
Repair Techniques:
Methods for repairing the HTML code
Test Files:
Used to test evaluation tools to see if they find the accessibility problem
Discussion Files:
Discussion and comments on the technique

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

Checkpoint 1.1 - Provide a text equivalent for every non-text element.

Technique 1.1.A [priority 1] Check Images for ALT text

Discussion Status:
Evaluation:

Valid ALT text:

Note: We're awaiting word from GL on null and blank alt text. See discussion at http://lists.w3.org/Archives/Public/w3c-wai-er-ig/1999Jun/0050.html especially part about null or blank alt text for links.

example language:
Repair Techniques:

Other checks:

Test Files and Discussion Files:

Technique 1.1.B [priority 1] Check images for LONGDESC and descriptive link

Discussion Status:
Evaluation:

Images that do not require a LONGDESC or descriptive link:

Valid LONGDESC URI:

example language:
Repair Technique:
Test Files and Discussion Files:

Technique 1.1.C [priority 1] Check input buttons that use an image for ALT text

Discussion Status:
Evaluation:

Valid ALT text:

example language:
Repair Technique:
Test Files and Discussion Files:

Technique 1.1.D [priority 1] Check applets for ALT text

Discussion Status:
Evaluation:

Valid ALT attribute text:

example language:
Repair Technique:
Test Files and Discussion Files:

Technique 1.1.E [priority 1] Check Applets for alternative content

Discussion Status:
Evaluation:

Valid text element:

example language:
Repair Technique:
Test Files and Discussion Files:

Link to test files for this technique.

Technique 1.1.F [priority 1] Check objects for alternative representation

Discussion Status:
Evaluation:

Valid alternative representation element:

example language:
Repair Technique:
Test Files and Discussion Files:

Link to test files for this technique.

Technique 1.1.G [priority 1] Check frames for an associated LONGDESC file

Discussion Status:
Evaluation:

Valid LONGDESC file name:

example language:
Repair Technique:
Test Files and Discussion Files:

Technique 1.1.H [priority 1] Check AREA elements for ALT text

Discussion Status:
Evaluation:

Valid ALT attribute:

example language:
Repair Technique:

Prompt user for ALT text for the area element.

Test Files and Discussion Files:

Technique 1.1.I [priority 1] Check if audio files have an associated text transcript

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Link to test files for this technique.

Technique 1.1.J [priority 1] Check SCRIPT element for associated NOSCRIPT element

Discussion Status:
Evaluation:

Valid text element:

example language:
Repair Technique:
Test Files and Discussion Files:

Technique 1.1.K [priority 3] User notification for ASCII art

Discussion Status:
Evaluation:

All BODY elements will generate a user notification.

Note: We are still working on methods of determining if a document contains ASCII art. If we can't find a suitable algorithm that finds ASCII art then all pages will get a notification.

ASCII Art Discussion Page

example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 1.2 - Provide redundant text links for each active region of a server-side image map.

Technique 1.2.A [priority 1] Prompt user for text links if ISMAP used.

Discussion Status:
Evaluation:

Valid ISMAP attribute:

example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 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.

Technique 1.3.A [priority 1] User Notification for audio description.

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 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.

Technique 1.4.A [priority 1] User Notification for synchronized alternatives.

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 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

Technique 1.5.A [priority 3] Prompt user for text links if USEMAP used.

Discussion Status:
Evaluation:

Valid USEMAP attribute:

example language:
Repair Technique:
Test Files and Discussion Files:

Guideline 2. Don't rely on color alone.

Checkpoint 2.1 - Ensure that all information conveyed with color is also available without color, for example from context or markup.

Technique 2.1.A [priority 1] User notification for color use

Discussion Status:
Evaluation:

Display a user notification if the document contains any of the following elements:

example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 2.2 - Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen.

Technique 2.2.A [priority 3] Test the color attributes of the following elements for visibility:

Discussion Status:
Evaluation:

Test the following elements and attributes for color visibility

Color visibility can be determined according to the following algorithm:

(This is a suggested algorithm that is still open to change.)

Two colors provide good color visibility if the brightness difference and the color difference between the two colors are greater than a set range.

Color brightness is determined by the following formula:
((Red value X 299) + (Green value X 587) + (Blue value X 114)) / 1000
Note: This algorithm is taken from a formula for converting RGB values to YIQ values. This brightness value gives a perceived brightness for a color.

Color difference is determined by the following formula:
(maximum (Red value 1, Red value 2) - minimum (Red value 1, Red value 2)) + (maximum (Green value 1, Green value 2) - minimum (Green value 1, Green value 2)) + (maximum (Blue value 1, Blue value 2) - minimum (Blue value 1, Blue value 2))

The rage for color brightness difference is 125. The range for color difference is 500.

example language:
Repair Technique:
Test Files and Discussion Files:

Guideline 3. Use markup and style sheets and do so properly

Checkpoint 3.1 - When an appropriate markup language exists, use markup rather than images to convey information

Technique 3.1.A [priority 2] User notification for appropriate markup language

Discussion Status:
Evaluation:
example language:
Repair Technique:

Checkpoint 3.2 - Create documents that validate to published formal grammars

Technique 3.2.A [priority 2] Check document for public text identifier

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 3.3 - Use style sheets to control layout and presentation

Technique 3.3.A [priority 2] Check document for use of style sheets. Notify user if they are not used.

Discussion Status:
Evaluation:
example language:
Repair Technique:

Checkpoint 3.4 - Use relative rather than absolute units in markup language attribute values and style sheet property values

Technique 3.4.A [priority 2] Check document for relative or absolute units.

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 3.5 - Use header elements to convey document structure and use them according to specification

Technique 3.5.A [priority 2] Check document for header nesting

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Technique 3.5.B [priority 2] Check document for missing header markup

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Technique 3.5.C [priority 2] User notification of improper header use

Discussion Status:
Evaluation:
example language:
Repair Technique:

Checkpoint 3.6 - Mark up lists and list items properly

Discussion Status:
Evaluation:

(I think the idea behind this checkpoint is that ordered lists should be used for nested lists and that each item should contain information about the nesting. Example list items: 1, 1.2, 1.2, 1.3. But how can this be done? The following example shows that browsers don't display nested list numbers very well.)

The nested list:

<OL> <LI>item 1<OL> <LI>1 Item 1.1</LI> <LI>2 Item 1.2</LI> <LI>3 Item 1.3</LI> </OL> </LI> <LI>item 2</LI> </OL>

Displays as:

  1. item 1
    1. 1 Item 1.1
    2. 2 Item 1.2
    3. 3 Item 1.3
  2. item 2

LI elements should not occur outside of UL of OL elements.

example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 3.7 - Mark up quotations. Do not use quotation markup for formatting effects such as indentation

Technique 3.7.A [priority 2] Check document for missing quote markup

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Technique 3.7.B [priority 2] Check Q and BLOCKQUOTE to ensure they are used properly

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Technique 3.7.C [priority 2] User notification of improper BLOCKQUOTE or Q use

Discussion Status:
Evaluation:
example language:

BLOCKQUOTE or Q elements should be used to define quotes and should not be used for formatting text.

Repair Technique:

Guideline 4. Clarify natural language usage

Checkpoint 4.1 - Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions)

Technique 4.1.A [priority 1] User notification of changes in natural language of document.

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 4.2 - Specify the expansion of each abbreviation or acronym in a document where it first occurs

Technique 4.2.A [priority 3] User notification of abbreviation and acronym expansion.

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 4.3 - Identify the primary natural language of a document

Technique 4.3.A [priority 3] Check the primary language of the document

Discussion Status:
Evaluation:

Allowed LANG attributes:

example language:
Repair Technique:
Test Files and Discussion Files:

Guideline 5. Create tables that transform gracefully

Checkpoint 5.1 - For data tables, identify row and column headers

Technique 5.1.A [priority 1] Check the table for row and column headers

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 5.2 - For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells

Technique 5.2.A - [Priority 1] Check tables for multiple levels of logical row/column headers

Discussion Status:
Evaluation:
example language:
Repair Technique:

Checkpoint 5.3 - Do not use tables for layout unless the table makes sense when linearized

Technique 5.3.A [priority 2] User notification of using tables for layout

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 5.4 - If a table is used for layout, do not use any structural markup for the purpose of visual formatting

Technique 5.4.A [priority 2] Check layout tables for structural markup

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 5.5 - Provide summaries for tables

Technique 5.5.A [priority 3] Check table for valid SUMMARY

Discussion Status:
Evaluation:

Valid SUMMARY attributes:

example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 5.6 - Provide abbreviations for header labels

Technique 5.6.A [priority 3] Check table for header abbreviations

Discussion Status:
Evaluation:

Valid ABBR attributes:

example language:
Repair Technique:
Test Files and Discussion Files:

Guideline 6. Ensure that pages featuring new technologies transform gracefully

Checkpoint 6.1 - Organize documents so they may be read without style sheets

Technique 6.1.A [priority 1] User notification of style sheet use.

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 6.2 - Ensure that equivalents for dynamic content are updated when the dynamic content changes

Technique 6.2.A [priority 1] User notification if FRAME source is not an HTML document.

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Technique 6.2.B [priority 1] User notification of dynamic content changes

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 6.3 - Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported

Technique 6.3.A [priority 1] User notification of usability when programatic objects are disabled.

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 6.4 - For scripts and applets, ensure that event handlers are input device-independent

Technique 6.4.A [priority 2] User notification of device independent event handlers.

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 6.5 - Ensure that dynamic content is accessible or provide an alternative presentation or page

Technique 6.5.A [priority 2] Check if there is a NOFRAMES section after a FRAMES section.

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Guideline 7. Ensure user control of time-sensitive content changes

Checkpoint 7.1 - Until user agents allow users to control flickering, avoid causing the screen to flicker

Technique 7.1.A [priority 1] User notification of potential screen flicker

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 7.2 - Until user agents allow users to control blinking, avoid causing content to blink

Technique 7.2.A [priority 1] Remove any BLINK elements from document

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 7.3 - Until user agents allow users to freeze moving content, avoid movement in pages

Technique 7.3.A [priority 1] Remove any MARQUEE elements from document

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Technique 7.3.B [priority 1] Remove any scripts that cause text to scroll

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 7.4 - Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages

Technique 7.4.A [priority 2] Remove auto-refresh attributes from META elements

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 7.5 - Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically

Technique 7.5.A [priority 2] Remove auto-redirect attributes from META elements

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Guideline 8. Ensure direct accessibility of embedded user interfaces

Checkpoint 8.1 - Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies

Technique 8.1.A [priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2] User notification if programmatic elements used

Discussion Status:
Evaluation:
example language:
Repair Technique:

Guideline 9. Design for device-independence

Checkpoint 9.1 - Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape

Technique 9.1.A [priority 1] User notification of server-side image map use

Discussion Status:
Evaluation:
example language:
Repair Technique
Test Files and Discussion Files:

Checkpoint 9.2 - Ensure that any element that has its own interface can be operated in a device-independent manner

(Image map text links - checked in techniques 1.2.A and 1.5.A.


Checkpoint 9.3 - For scripts, specify logical event handlers rather than device-dependent event handlers

Technique 9.3.A [priority 2] User notification of logical event handlers for scripts

Discussion Status:
Evaluation:
example language:
Repair Technique
Test Files and Discussion Files:

Checkpoint 9.4 - Create a logical tab order through links, form controls, and objects


Checkpoint 9.5 - Provide keyboard shortcuts to important links


Guideline 10. Use interim solutions

Checkpoint 10.1 - Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user

Technique 10.1.A [priority 1] Check anchors for 'new window' attributes

Discussion Status:
Evaluation:
example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 10.2 - Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned


Checkpoint 10.3 - Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns


Checkpoint 10.4 - Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas


Checkpoint 10.5 - Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links


Guideline 11. Use W3C technologies and guidelines

Checkpoint 11.1 - Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported


Checkpoint 11.2 - Avoid deprecated features of W3C technologies

(This looks like something that the editor should check for.)


Checkpoint 11.3 - Provide information so that users may receive documents according to their preferences

(We're doing all we can by prompting user to specify language of document in technique 4.3.A.)


Checkpoint 11.4 - If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page

(Should we notify user of this? For every page?)


Guideline 12. Provide context and orientation information

Checkpoint 12.1 - Title each frame to facilitate frame identification and navigation

Technique 12.1.A [priority 1] Check frames for title

Discussion Status:
Evaluation:

Valid title text for frame:

example language:
Repair Technique:
Test Files and Discussion Files:

Checkpoint 12.2 - Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone

(Suggest that if the frame title does not describe the frame that a LONGDESC is needed?)


Checkpoint 12.3 - Divide large blocks of information into more manageable groups where natural and appropriate

(Any suggestions??)


Checkpoint 12.4 - Associate labels explicitly with their controls

(Check for the presence of a validated LABEL element?)


Guideline 13. Provide clear navigation mechanisms

Checkpoint 13.1 - Clearly identify the target of each link

(Search for text string 'click here'? Perhaps display all the anchor text and ask user if they are all clear?)


Checkpoint 13.2 - Provide metadata to add semantic information to pages and sites

(Suggestions??)


Checkpoint 13.3 - Provide information about the general layout of a site

(Can't be machine checked. User notification?)


Checkpoint 13.4 - Use navigation mechanisms in a consistent manner

(Can't be machine checked. User notification?)


Checkpoint 13.5 - Provide navigation bars to highlight and give access to the navigation mechanism

(Can't be machine checked. User notification?)


Checkpoint 13.6 - Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group

(Can't be machine checked. User notification?)


Checkpoint 13.7 - If search functions are provided, enable different types of searches for different skill levels and preferences

(Can't be machine checked. User notification?)


Checkpoint 13.8 - Place distinguishing information at the beginning of headings, paragraphs, lists, etc

(Can't be machine checked. User notification?)


Checkpoint 13.9 - Provide information about document collections

(Can't be machine checked. User notification?)


Checkpoint 13.10 - Provide a means to skip over multi-line ASCII art

(Can't be machine checked - this sort of ASCII art is larger than just emoticons. User notification?)


Guideline 14. Ensure that documents are clear and simple

Checkpoint 14.1 - Use the clearest and simplest language appropriate for a site's content

(Check document using fog index? User notification?)


Checkpoint 14.2 - Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page

(Can't be machine checked. User notification?)


Checkpoint 14.3 - Create a style of presentation that is consistent across pages

(Can't be machine checked. User notification?)


Document Rating

After evaluating a document, an evaluation and/or repair tool should provide the user with a document rating. The rating is based on conformance to the WAI Page Authoring Guidelines and will be:

Some checkpoints can not be checked by a software program and will require user evaluation. The user must be informed of the items that they must check.


Appendixes

Appendix A - Placeholder ALT text


Appendix B - Image File Suffixes


Appendix C - Placeholder OBJECT ALT text


Appendix D - Sound File Suffixes


Appendix E - Placeholder NOSCRIPT text


Appendix F - Placeholder TABLE SUMMARY text


Appendix G - Placeholder table header ABBR text


Appendix H - Placeholder FRAME TITLE text


Appendix I - Applet Executable Suffix


Appendix J - Bullet Identification

An image will be identified as a bullet if it has the following characteristics:

Identifying Bullets page


Appendix K - Horizontal Rule Identification

An image will be identified as a horizontal rule if it has the following characteristics:

Identifying HRs page