W3C

Techniques For Accessibility Evaluation And Repair Tools

W3C Working Draft, 26 April 2000

This version:
http://www.w3.org/TR/2000/WD-AERT-20000426
Latest version:
http://www.w3.org/TR/AERT
Editors:
Chris Ridpath, Adaptive Technology Resource Centre, University of Toronto -- Canada
Wendy Chisholm, W3C

Abstract

This document describes techniques that Web accessibility validation tools may use to evaluate the conformance of HTML documents to the Web Content Accessibility Guidelines 1.0 (WCAG 1.0). This document also describes techniques that Web authoring tools may use to help authors modify HTML documents to conform to WCAG 1.0. We anticipate that tool developers may develop accessibility validation and/or repair modules to be incorporated into commercial authoring tools, validation tools, and perhaps user agents.

Status Of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This is a W3C Working Draft produced by the Evaluation and Repair Tools Working Group. The working group encourages

The working group expects to collect and test new and existing techniques in the next few months. The document will be updated to reflect the group's findings.

Information about existing Evaluation, Repair, and Transformation Tools for Web Content Accessibility is available from the working group's home page.

This 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". A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.

Please send comments on this document to w3c-wai-er-ig@w3.org. The archives for this list are publicly available.

To do

Table of Contents


Introduction

The Web Accessibility Initiative (WAI) has produced a foundation document, The W3C Web Content Accessibility Guidelines (WCAG 1.0), that describes what must be done to make a Web page accessible to all. Tools are needed to help authors determine if a web site is accessible to everyone and to help repair it if it is not.

This document builds on the WCAG 1.0 foundation by outlining techniques that evaluation and repair tools may use 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 people with disabilities are included in the "anyone interested in creating accessible Web content." Creating accessible Web content is as important as accessing Web content. Therefore, evaluation and repair tools themselves need to be accessible to people with disabilities. However, this document does not describe how to make the user interface accessible. Please refer to the User Agent Accessibility Guidelines for information on making the user interface accessible.

Many people using evaluation and repair tools may be new to the Web and will not be familiar with the various markup languages that are used. Many others will not know about Web accessibility. Tools should be intuitive and easy to use and available at a minimal cost. Tools should not generate excessive warnings or false positive accessibility errors.

Some of the web-content accessibility checkpoints cannot be checked successfully by software algorithms alone. There will still be a dependence on the user's ability to exercise human judgment 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 W3C Web Content Accessibility Guidelines. It lists each guideline and checkpoint in in that document. Under each checkpoint it lists one or more techniques for evaluating and, in some cases, repair.  Each technique comprises the following subsections:

Open issues for this technique
This section lists open issues and questions about a particular technique.  
Evaluation:
The algorithmic and heuristic tests that will be applied. consisting of


Note: in a few cases, the warning is always presented.

Suggested message:
Messages displayed to the author if the element is found and the requirement is not satisfied.
Suggested repair:
Actions that may be required to repair the accessibility problem.
Test files:
Used to test evaluation tools to see if they find the accessibility problem. These are under construction!!
Discussion files:
Discussion and comments on the technique.

Note. This document specifies only the function of evaluation and repair tools. Nothing in this document should be taken to imply a particular user interface.


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.1 [priority 1] Check IMG elements for valid "alt" attribute

Open issues for this technique:
Evaluation:

Valid "alt" attribute:

Suggested message:
Suggested repair:
Test Files and Discussion Files:

Technique 1.1.2 [priority 1] Verify that valid IMG element descriptions ("longdesc" attribute or d-link) are provided where necessary.

Open issues for this technique:
Evaluation:

Valid "longdesc" attribute:

Suggested message:
Suggested repair:
Test Files and Discussion Files:

Technique 1.1.3 [priority 1] Check INPUT elements of type="image" for valid "alt" attribute

Evaluation:

Valid "alt" attribute:

Suggested message:
Suggested repair:

Technique 1.1.4 [priority 1] Check APPLET elements for valid HTML equivalent

Evaluation:

Valid "alt" attribute values:

Suggested message:
Suggested repair:
Test Files and Discussion Files:

Technique 1.1.5 [priority 1] Check OBJECT elements of type="image_MIME_types" for valid text equivalents and descriptions (where necessary)

Open issues for this technique:
Evaluation:

Valid alternative representation element:

Suggested message:
Suggested repair:
Test Files and Discussion Files:

Test file - OBJECT text equivalent.

Technique 1.1.6 [priority 1] Verify that text equivalents are provided for linked audio files where necessary

Evaluation:
Suggested message:
Suggested repair:
Test Files and Discussion Files:

Test file - text for sound files.

Technique 1.1.7 [priority 1] Verify that text equivalents are provided for embedded audio files where necessary

Evaluation:
Suggested message:
Suggested repair:

Technique 1.1.8 [priority 1] Check FRAME elements for valid "longdesc" attribute

Evaluation:

Valid "longdesc" attribute:

Suggested message:
Suggested repair:
Test Files and Discussion Files:

Technique 1.1.9 [priority 1] Check AREA elements for valid "alt" attribute

Evaluation:

Valid "alt" attribute:

Suggested message:
Suggested repair:

Prompt user for "alt" text for the AREA element.

Test Files and Discussion Files:

Technique 1.1.10 [priority 1] Check SCRIPT elements for valid equivalents where necessary

Evaluation:
Suggested message:
Suggested repair:
Test Files and Discussion Files:

Technique 1.1.11 [priority 1] Check A elements for valid text content

@@handled by technique 13.1.1 - verify that targets are clearly identified? What else do we need to check for?

Technique 1.1.12 [priority 1] Verify that valid text equivalents are provided for PRE and XMP elements used to create ASCII art.

Open issues for this technique:
Evaluation:
Suggested message:
Suggested repair:
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.1 [priority 1] Verify that a server-side image map has associated text links.

Open issues for this technique:
Evaluation:
Suggested message:
Suggested repair:
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.1 [priority 1] Verify that multimedia have audio descriptions.

Evaluation:
Suggested repair:

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.1 [priority 1] Verify that multimedia have synchronized equivalents.

Evaluation:
Suggested message:
Suggested repair:

Technique 1.4.2 [priority 1] Check SMIL files for synchronized media

Open issues for this technique:
Evaluation:

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.1 [priority 3] Verify that text links are provided for client-side image maps.

Evaluation:
Suggested message:
Suggested repair:
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.1 [priority 1] Verify that information conveyed with color is available without color

Evaluation:
Suggested message:
Suggested repair:

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.1 [priority 3] Test the color attributes of the following elements for visibility:

Evaluation:

Ideally, images and multimedia object should also be tested for color visibility but algorithms are beyond the scope of this specification.

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.

Suggested message:
Suggested repair:
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.1 [priority 2] Verify that elements do not need to be converted to an appropriate markup language.

Evaluation:
Suggested message:
Suggested repair:

Checkpoint 3.2 - Create documents that validate to published formal grammars

Technique 3.2.1 [priority 2] Check document for public text identifier

Open issues for this technique:
Evaluation:
Suggested message:
Suggested repair:
Test Files and Discussion Files:

Checkpoint 3.3 - Use style sheets to control layout and presentation

Technique 3.3.1 [priority 2] Check document for use of style sheets.

Evaluation:
Suggested message:
Suggested repair:

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

Technique 3.4.1 [priority 2] Check document for relative units of measure.

Evaluation:
Suggested message:
Suggested repair:

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

Technique 3.5.1 [priority 2] Check document for header nesting

Evaluation:
Suggested message:
Suggested repair:
Test Files and Discussion Files:

Technique 3.5.2 [priority 2] Check document for missing header markup

Evaluation:
Suggested message:
Suggested repair:
Test Files and Discussion Files:

Technique 3.5.3 [priority 2] Verify that header elements are not used for formatting.

Evaluation:
Suggested message:
Suggested repair:

Checkpoint 3.6 - Mark up lists and list items properly

Technique 3.6.1 [priority 2] Check that list elements are within a list container and well nested.

Evaluation:
Suggested message:
Suggested repair:

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

Technique 3.7.1 [priority 2] Verify instances where quote markup should be used.

Discussion Status:
Evaluation:
Suggested message:
Suggested repair:
Test Files and Discussion Files:

Technique 3.7.2 [priority 2] Verify that Q and BLOCKQUOTE are used properly

Evaluation:
Suggested message:
Suggested repair:

Technique 3.7.3 [priority 2] Verify that BLOCKQUOTE is not used for formatting

Evaluation:
Suggested message:
Suggested repair:

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.1 [priority 1] Verify changes in the natural language of document.

Evaluation:
Suggested message:
Suggested repair:
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.1 [priority 3] Verify that abbreviations and acronyms need expanding.

Evaluation:

Potential abbreviation:

Potential acronym:

Suggested message:
Suggested repair:

Checkpoint 4.3 - Identify the primary natural language of a document

Technique 4.3.1 [priority 3] Verify the primary language of the document

Evaluation:

Valid "lang" attribute:

Suggested message:
Suggested repair:
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.1 Determine the purpose of the table

The purpose of the table must be determined before performing an accessibility evaluation. To help the author make this assessment, the following language may be used:

Suggested message:

Technique 5.1.2 [priority 1] Check data table for row and column headers

Evaluation:
Suggested message:
Suggested repair:
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.1 - [Priority 1] Check data tables for multiple levels of row and column headers

Evaluation:
Suggested message:
Suggested repair:

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

Technique 5.3.1 [priority 2] Verify that layout tables make sense when linearized

Evaluation:
Suggested message:
Suggested repair:
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.1 [priority 2] Check layout tables for structural markup

Evaluation:
Suggested message:
Suggested repair:
Test Files and Discussion Files:

Checkpoint 5.5 - Provide summaries for tables

Technique 5.5.1 [priority 3] Check TABLE elements for valid "summary" attribute

Evaluation:

Valid "summary" attribute:

Suggested message:
Suggested repair:
Test Files and Discussion Files:

Technique 5.5.2 [priority 2] Check TABLE elements for valid CAPTION element.

Evaluation:
Suggested message:
Suggested repair:

Checkpoint 5.6 - Provide abbreviations for header labels

Technique 5.6.1 [priority 3] Check table for header abbreviations

Discussion Status:
Evaluation:

Valid "abbr" attributes:

Suggested message:
Suggested repair:
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.1 [priority 1] Verify that the document is readable when style sheets are not applied.

Evaluation:
Suggested message:
Suggested repair:

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

Technique 6.2.1 [priority 1] Check the source of FRAME and IFRAME elements for valid markup files.

Evaluation:
Suggested message:
Suggested repair:
Test Files and Discussion Files:

Technique 6.2.2 [priority 1] Verify that equivalents of dynamic content are updated and available as often as the dynamic content.

Open issues for this technique:
Evaluation:
Suggested message:
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.1 [priority 1] Verify that the page is usable when programmatic objects are disabled.

Evaluation:
Suggested message:
Suggested repair:

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

Technique 6.4.1 [priority 2] Check for device independent event handlers.

Evaluation:
Suggested message:
Suggested repair:

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

Technique 6.5.1 [priority 2] Check that a NOFRAMES element exists within each FRAMESET.

Evaluation:

Valid NOFRAMES section

Suggested message:
Suggested repair:
Test Files and Discussion Files:

Technique 6.5.2 [priority 2] @@Need something for scripts and programmatic objects?

@@ is this covered by 6.3.1 (Verify that the page is usable when programmatic objects are disabled)?


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.1 [priority 1] Verify that the page does not cause flicker.

Discussion Status:
Evaluation:
Suggested message:
Suggested repair:

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

Technique 7.2.1 [priority 1] Check for BLINK elements

Evaluation:
Suggested message:
Suggested repair:
Test Files and Discussion Files:

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

Technique 7.3.1 [priority 1] Check for MARQUEE elements

Evaluation:
Suggested message:
Suggested repair:
Test Files and Discussion Files:

Technique 7.3.2 [priority 1] Verify that programmatic objects do not create moving content

Evaluation:
Suggested message:
Suggested repair:
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

Evaluation:
Suggested message:
Suggested repair:
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.1 [priority 2] Check auto-redirect attributes on META elements

Evaluation:
Suggested message:
Suggested repair:
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.1 [priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2] Verify that programmatic objects are directly accessible.

Open issues for this technique:
Evaluation:
Suggested message:
Suggested repair:

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.1 [priority 1] Check for use of server-side image maps

Evaluation:
Suggested message:
Suggested repair:

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

Open issues for this technique:
Evaluation:
Suggested message:
Suggested repair:

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

Technique 9.3.1 [priority 2] Check scripts for logical event handlers

Evaluation:
Suggested message:
Suggested repair:

Allow the user to add or replace the event handlers according to the following list:


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

Technique 9.4.1 [priority 3] Check for "tabindex" attribute

Open issues for this technique:
Evaluation:

Valid "tabindex" attribute:

Suggested message:
Suggested repair:

Checkpoint 9.5 - Provide keyboard shortcuts to important links, form controls, and groups of form controls

Technique 9.5.1 [priority 3] Check for "accesskey" attribute.

Evaluation:
Suggested message:
Suggested repair:

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.1 [priority 1] Check A and AREA elements for valid "target" attributes

Open issues for this technique:
Evaluation:
Suggested message:
Suggested repair:
Test Files and Discussion Files:

Technique 10.1.2 [priority 1] Verify that scripts do not spawn new windows.

Open issues for this technique:
Evaluation:
Suggested message:
Suggested repair:

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

Technique 10.2.1 [priority 2] Verify that LABEL elements are properly positioned.

Refer also to checkpoint 12.4

Discussion Status:
Evaluation:
Suggested message:
Suggested repair:

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

Technique 10.3.1 [priority 3] Verify that a linearized version of tables used for layout is provided.

Evaluation:
Suggested message:
Suggested repair:
Test Files and Discussion Files:

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

Technique 10.4.1 [priority 3] Check for valid default values of INPUT, TEXTAREA, and SELECT elements.

Evaluation:
Suggested message:
Suggested repair:

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

Technique 10.5.1 [priority 3] Check for non-whitespace characters between consecutive A elements.

Evaluation:
Suggested message:
Suggested repair:

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

Technique 11.1.1 [priority 2] Verify that W3C technologies are used, where possible and appropriate.

Open issues for this technique:
Evaluation:
Suggested message:
Suggested repair:

Checkpoint 11.2 - Avoid deprecated features of W3C technologies

Technique 11.2.1 [priority 2] Check for deprecated features of W3C technologies.

Evaluation:
Suggested message:
Suggested repair:

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

Technique 11.3.1 [priority 3] Check that documents are served per user preferences.

Evaluation:
Suggested repair:

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

Technique 11.4.1 [priority 1] Verify that the page has passed all checkpoints of the desired conformance level.

Evaluation:
Suggested message:
Suggested repair:

Guideline 12. Provide context and orientation information


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

Technique 12.1.1 [priority 1] Check FRAME elements for valid "title" attributes

Evaluation:

Valid "title" attribute:

Suggested message:
Suggested repair:
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

@@ covered by 1.1.8?

@@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

Technique 12.4.1 [priority 2] Check LABEL elements for valid "for" attribute values.

Evaluation:
Suggested message:
Suggested repair:

Guideline 13. Provide clear navigation mechanisms


Checkpoint 13.1 - Clearly identify the target of each link

Technique 13.1.1 [priority 2] Verify that the target of each link is clearly identified.

Evaluation:

Suspicious anchor names:

Suggested message:
Suggested repair:
Related resources

Harper, S., Stevens, R., and Goble, C. (1999). Towel: Real World Mobility on the Web. In Vanderdonckt, J. and Puerta, A., eds.: Computer-Aided Design of User Interfaces II. Dordrecht, Netherlands: Kluwer Academic Publishers.


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

Technique 13.2.1 [priority 2] Check for META, ADDRESS, TITLE and LINK elements.

Evaluation:
Suggested message:
Suggested repair:

Technique 13.2.2 [priority 2] Check for use of RDF.

@@Similar to 13.2.1, yet might be best in own technique??


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

@@Machine checkable? Generate user notification?


Checkpoint 13.4 - Use navigation mechanisms in a consistent manner

@@Machine checkable? Generate user notification?


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

@@Machine checkable? Generate 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

Technique 13.6.1 [Priority 3] Verify if links should be grouped.

Open issues for this technique:
Discussion status:

This suggests another technique that is not widely supported by user agents.

Evaluation:
Suggested message:
Suggested repair:

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

Technique 13.7.1 [priority 3] Verify that search functions enable a variety of skill levels and preferences.

Evaluation:
Suggested message:

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

@@Machine checkable? Generate user notification?


Checkpoint 13.9 - Provide information about document collections

Technique 13.9.1 [priority 3] Verify that information about document collections is provided.

Open issues for this technique:
Evaluation:
Suggested message:
Suggested repair:

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

Technique 13.10.1 [priority 3] Verify that one can skip over multi-line ASCII art.

Open issues for this technique:
Evaluation:
Example of message to be displayed:
Suggested repair:

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? Generate user notification?


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

@@Machine checkable? Generate user notification?


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

Technique 14.3.1 [priority 3] Verify that a consistent style of presentation is used across pages.

Open issues for this technique:
Evaluation:
Suggested message:
Suggested repair:

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 W3C Web Content Accessibility 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.

Refer to the Rating Algorithm for Evaluation of Web Pages by Len Kasday.


Appendix A - Placeholder text


Appendix B - Image File Suffixes


Appendix C - Placeholder OBJECT text equivalent


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


Appendix L - Links To Associated Sites


Glossary

@@link to WCAG and ATAG glossaries?

Programmatic object
An object that is embedded in a document with the SCRIPT or APPLET elements, and sometimes with the OBJECT or EMBED elements. @@need to clarify the definition and then use it.

Level Double-A conformance icon,     
     W3C-WAI Web Content Accessibility Guidelines 1.0 Valid HTML 4.0! Valid CSS!