Techniques For Evaluation And Implementation Of Web Content Accessibility Guidelines

Abstract

This document describes techniques that may be used by software programs in evaluating the conformance of HTML documents to The Web Content Accessibility Guidelines 1.0. It also describes techniques 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 W3C Working Draft for review by the Evaluation and Repair Tools Working Group and other invited parties. It has not been reviewed by the WAI Interest Group. 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". 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.

To do

• Clean up all of the @@'s (editor questions and comments).
• Check for consistent language usage.
• Link to WCAG, AU and UA Techniques and EO Curriculum where appropriate.
• Use WCAG notes or rationale as example language where possible, unless we have something clearer.
• Inherit all of the reference info between checkpoints from WCAG (e.g., at the end of Checkpoint 10.1, "refer also to Checkpoint 12.4").
• Determine if we want to use "author" or "user." Then check for consistent usage.
• Determine if we want to use "document" or "page." Then check for consistent usage.
• Ensure that "Web" is capitalized consistently.
• Ensure that links to test and discussion files have unique link text.
• Resolve open issues.

Introduction

The Web Accessibility Initiative (WAI) has produced a foundation document, The WAI 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 WAI 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:

Discussion status

This section lists open issues and questions about a particular technique.  

Evaluation:

The algorithmic and heuristic tests that will be applied. consisting of

• Elements - the elements to which this test applies, e.g. <IMG> etc. If it only applies to an element of a particular type, this is noted (e.g. <INPUT  TYPE="image">
• Requirements - the conditions which will be tested for by means of algorithms and heuristics.

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.

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
• Checkpoint 1.2 - Provide redundant text links for each active region of a server-side image map
• 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
• 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
• 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

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

Evaluation:

• Element: <IMG>
• Requirement: Valid "alt" attribute.

Valid "alt" attribute:

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.

• "alt" attribute must exist
• Not allowed - NULL "alt" value (alt="")
• Allowed - "alt" value of 1 or more spaces ("alt=" "") but only if image is not within an "A element"
• Suspicious - "alt" attribute value could be file size (ends with "bytes")
• Suspicious - "alt" attribute value ends with image file suffix.
• Suspicious - "alt" attribute value is placeholder text.
• Suspicious - "alt" attribute value is longer than 150 characters. Suggest that a description file be created.

Suggested message:

• Missing text equivalent: Missing text equivalent for image.
• Suspicious "alt" attribute: Suspicious text equivalent for image: [current "alt" text] - [could be file size | could be file name | could be placeholder text | text equivalent should be short, perhaps this could be a "longdesc"].
• Invalid "alt" attribute: Invalid text equivalent for image: [text equivalents can not be empty].

Suggested repair:

• Prompt the user for a text equivalent for the image.
• If the document contains another instance of the image and that image contains an "alt" attribute, suggest that "alt" attribute value.
• If the image is assumed to be a bullet, suggested text should be "bullet".
• If the image is assumed to be a horizontal rule, suggested text should be "horizontal rule".
• Other suggestions by Daniel Dardailler
• Suggestions by Michael Vorburger
• After user has entered an "alt" attribute for the image, check the site for other instances of the image. If the site contains other images that are the same and they do not have a text equivalent, suggest that all same images without an "alt" attribute use the new "alt" attribute value.

Test Files and Discussion Files:

• Test file 1

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

Evaluation:

• Element: <IMG>
• Requirements:
  • Valid "longdesc" attribute or a d-link required if describing the image will add information not given in the text of the page. The amount of information in the image and the context in which it is used will determine how detailed the description should be. Note: d-link now deprecated.
  • Cases where a description is not required:
    • bullets - refer to Appendix J.
    • horizontal rules - refer to Appendix K.

Valid "longdesc" attribute:

• any valid URI

Suggested message:

• If describing the image will add information not given in the text of the page, you need to provide a description of the image. The amount of information in the image and the context in which it is used will determine how detailed the description should be.

Suggested repair:

• Ask user if the image presents information that is not included in the page or in the text equivalent for the image. Allow the user to create or associate a description.
  • with the "longdesc" attribute on an IMG element
  • via a D-link
• If another document on the same site uses the same image and has a "longdesc", suggest that "longdesc" file.

Test Files and Discussion Files:

• Link to discussion on this technique.
• Link to test files for this technique.

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

Evaluation:

• Element: <INPUT type="image">
• Requirement: Valid "alt" attribute.

Valid "alt" attribute:

• "alt" attribute must exist
• Not valid - NULL "alt" value (alt="")
• Not valid - "alt" value of 1 or more spaces (alt=" ")
• Suspicious - "alt" attribute value could be file size (ends with "bytes")
• Suspicious - "alt" attribute value ends with image file suffix.
• Suspicious - "alt" attribute value is placeholder text.

Suggested message:

• Missing text equivalent: Missing text equivalent for this button.
• Suspicious text equivalent: Suspicious text equivalent for button: [current "alt" attribute] - [could be file size | could be file name | could be placeholder text].
• Invalid text equivalent: Invalid text equivalent for button: [ "alt" attribute can not be empty | text equivalent can not contain only 'spaces'].

Suggested repair:

• Prompt the user for text equivalent.
• If another document on the same site has an INPUT element with the same TYPE value, suggest that type value.

Test Files and Discussion Files:

• Link to test files for this technique.

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

Evaluation:

• Element: <APPLET>
• Requirements:
  • Valid "alt" attribute OR
  • accessible  HTML within APPLET element

Valid "alt" attribute values:

• Not allowed - NULL "alt" attribute value (alt="")
• Not allowed - "alt" attribute value of 1 or more spaces (alt=" ")
• Suspicious - "alt" attribute value could be file size (ends with "bytes")
• Suspicious - "alt" attribute value ends with image file suffix.
• Suspicious - "alt" attribute value is placeholder alt-text text.
• Suspicious - "alt" attribute ends with applet executable suffix.
• Allowed - no "alt" attribute if text is provided within the content of the APPLET element.

Suggested message:

• Missing text equivalent: Applet must have valid a valid "alt" attribute or accessible HTML content."
• Suspicious text equivalent: Suspicious text equivalent for applet: [current "alt" attribute value] - [could be file size | could be image file name | could be placeholder text | could be applet executable name].
• Invalid text equivalent: Invalid "alt" attribute for applet - [text equivalent can not be empty | text equivalent can not be all 'spaces'].

Suggested repair:

• Prompt the user for text equivalent.
• If the same applet is used on the same site and has an "alt" attribute, suggest that "alt" attribute value.

Test Files and Discussion Files:

• Link to test files for this technique.
• Link to test files for this technique.

Technique 1.1.6 [priority 1] Check OBJECT elements of type="<image MIME types>" for valid text equivalents and descriptions (where necessary)

@@this just says text equivalents. len's additions are non-text. where is non-text covered if not here?

Evaluation:

• Element: <OBJECT>
• Requirement: Between OBJECT start element and OBJECT end element must be a valid alternative representation element.

Valid alternative representation element:

• A text element with at least one word of text.
• An IMG element with valid alt- text
• A valid URI
• Suspicious - "alt" attribute value is placeholder OBJECT text equivalent

Suggested message:

• Missing alternative representation: Missing alternative representation for this object.
• Suspicious alternative representation: Suspicious alternative representation for this object: [current alternative representation] - [could be placeholder text]
• @@likewise, might be "missing text equivalent"

Suggested repair:

• Prompt user for new alternative representation.
• If the site contains a document that contains the same object and that object contains a valid alternative representation, suggest that alternative representation.

Test Files and Discussion Files:

Link to test files for this technique.

@@LRK:  divided 1.1.7 into two cases: "linked" and "embedded" audio since the tests are different.(is "linked" proper terminology for object?)

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

Evaluation:

• Elements: <A href=soundFile>
• Requirement: Audio file must be described within the document or document must contain a link to a text equivalent file.

Suggested message:

• Audio files require a text equivalent. Is there an associated text equivalent for this audio file: [audio file name]?

Suggested repair:

• Prompt user for text transcript of audio file.

Test Files and Discussion Files: @@LRK: if we leave 1.1.7a and 1.1.7b split we'll have to split the files too.

Link to test files for this technique.

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

Evaluation:

• Elements: <OBJECT type=Audio or Video MIME TYPE>
• Requirement: Audio file must be described within the document or document must contain a link to a text equivalent file.

Suggested message:

• Audio and video files require a text equivalent. Is there an associated text equivalent for this audio/video file: [audio/video file name]?

Suggested repair:

• Prompt user for text transcript of audio/video file and embed it between start and end tag.

Test Files and Discussion Files:

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

Evaluation:

• Element: <FRAME>
• Requirement: Valid "longdesc" attribute (refer to checkpoint 12.1 for information about titling frames).
• If a FRAMESET has three or more frames and at least one of the frames does not have a "longdesc" attribute, ask the user if the relationships between frames are not apparent in the titles for each frame.

Valid "longdesc" attribute:

• Must not be NULL
• Must be a valid URI
• The file pointed to by the URI must be accessible HTML  @@LRK:: Added

Suggested message:

• Missing "longdesc": Missing description for this frame.
• Invalid "longdesc" URI: Invalid 'long description' file name for this frameset: [current "longdesc" URI] - [can not be empty].

Suggested repair:

• If the relationships between frames are not obvious then ask that they provide a description of the relationships. Allow the user to create a "longdesc" file or associate an existing "longdesc" file. It is suggested that each FRAME in the reference the same "longdesc" as the description of the relationships should be available from each FRAME.

Test Files and Discussion Files:

• Link to discussion on this technique.
• Link to test files for this technique.

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

Evaluation:

• Element:<AREA>
• Requirement: Elements must have a valid "alt" attribute.

Valid "alt" attribute:

• Not allowed - NULL "alt" value (alt="")
• Suspicious - "alt" attribute value is placeholder text.
• @@is this complete?

Suggested message:

• Missing text equivalent: Missing text equivalent for this image map area.
• Suspicious "alt": Suspicious "alt" attribute for this image map area: [current alt text].

Suggested repair:

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

Test Files and Discussion Files:

• Link to test files for this technique.

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

Evaluation:

• Element: <SCRIPT>
• Requirements:
  • NOSCRIPT section must follow the SCRIPT end element AND
  • NOSCRIPT section must contain Accessible HTML
  • NOSCRIPT section must not contain placeholder text

Suggested message:

• Language for missing NOSCRIPT: Missing NOSCRIPT element for this SCRIPT element.
• If contained HTML not accessible: NOSCRIPT section contains inaccessible HTML: [description of problems].

Suggested repair:

• Insert NOSCRIPT section
• Allow user to insert text or link to text equivalent file that describes the SCRIPT

Test Files and Discussion Files:

• Link to test files for this technique.

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

@@No information at this time.

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

Evaluation:

• Elements: PRE and XMP
• Requirement: ASCII art has an associated text equivalent.

@@The algorithm A-Prompt has been using for ASCII art detection is: There must be 5 or more lines of text and there must be 5 or more same characters in a sequence. This works quite well but detects things such as code samples (don't require text equiv.) and guitar tabulature (do require text equiv.). I have a list of ASCII art pages that we have tried this on if you would like to see results.

ASCII Art Discussion Page

Suggested message:

• Character based artwork (ASCII art) requires a textual description.

Suggested repair:

• Ask user for a description of the ASCII art or allow them to add a link to a text equivalent file.

Test Files and Discussion Files:

• Link to discussion on this technique.
• Link to test files for this technique.

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.

@@LRK: Issue: Text links only priority 3 if the same image also has a client side map (images can have both). This is an issue I raised with WCAG.

Evaluation:

• Element: <IMG ISMAP>
• Requirement: text link for each active area of the image map

Suggested message:

• Server-side image maps should have associated text links in the document.

Suggested repair:

• Prompt the user for associated text links OR
• help the user convert the server-side image map to a client-side image map and provide text-equivalents for each link in the client-side image map.
• If possible, check the text links against the links contained on the server-side image map by @@LRK added
  • asking user to upload the server side definition file if it's a standard format or
  • pinging the image map with random coordinates and seeing if all returned pages correspond to the links.

Test Files and Discussion Files:

• Link to test files for this technique.

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:

• Elements:
  • <any_tag any_attribute=multimedia_uri>,
  • OBJECT type=any_multimedia_type
  • @@LRK: is this correct and complete?  
• Requirement: Multimedia presentations should have an associated audio description.

Suggested repair:

• @@CR - Does this mean that the repair is to create an audio file (record the repair persons voice)?
• Display the multimedia file and allow the user to create an audio description of the important information.
• Allow the user to add a link to an existing audio description file.

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

Evaluation:

@@CR: The key word in this guideline seems to be 'synchronize'. How do we synchronize any equivalent alternatives? Can this be done in the HTML code?

• Elements:
  • <any_tag any_attribute=multimedia_uri>,
  • OBJECT type=any_multimedia_type
  • @@LRK: is this correct and complete?  @@Any multimedia object will generate a user notification
• Requirement: Multimedia presentations should have a synchronized equivalents.

Suggested message:

• For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (??what's the right phrase from WCAG to use here?@@)

Suggested repair:

• Give user option to edit option with editor of their choice (e.g. the default editor on their system) @@LRK

Test Files and Discussion Files:

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

@@LRK Omit this section?  Seems to duplicate 1.4.a

Evaluation:

• SMIL Elements:
• Requirement: SMIL files should have the system-captions flag for at least one text stream and one auditory stream.

Suggested message:

• none

Actions:

• none

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

Evaluation:

• Element: <IMG usemap>
• Requirement: Document must contain text links for each active area of the image map.
• Associated text links may be found by searching the document for anchors with href attribute values that correspond to the AREA elements in the given usemap.

Suggested message:

• Client-side image maps should have associated text links.

Suggested repair:

• Allow the user to create associated text links for each active area in the image map.

Test Files and Discussion Files:

• Link to test files for this technique.

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

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:

• Elements: IMG | APPLET | OBJECT | SCRIPT | INPUT | as well as the HTML elements and attributes listed in the next technique (2.2.1).

Suggested message:

• Ensure that information is not conveyed through color alone. For example, when asking for input from users, do not write "Please select an item from those listed in green." Instead, ensure that information is available through other style effects (e.g., a font effect) and through context (e.g,. comprehensive text links).

Suggested repair:

• Display a user notification if any of the color-possible elements are in the document.

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

Evaluation:

• Elements:
  • <BODY bgcolor | text | alink | link | vlink | background = anything>  OR
  • <TABLE bordercolor | bgcolor =anything>  OR
  • <TD | TH    bgcolor =anything > OR
  • <HR color =anything> OR
  • <any_element style="any_color_specification">
  • <STYLE> "any_color_specification"... </STYLE>
  • Where any_color_specification is defined as any CSS specification which contains:

    color | background-color | background-image | background

• Requirement: Determine color visibility.@@needs work?

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

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:

• Poor visibility between text and background colors.

Suggested repair:

• Allow the user to change the poor color combinations.
• Store any good color combinations entered by the user and use them as default prompts in the future.

Test Files and Discussion Files:

• Link to test files for this technique.

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
• Checkpoint 3.2 - Create documents that validate to published formal grammars
• Checkpoint 3.3 - Use style sheets to control layout and presentation
• Checkpoint 3.4 - Use relative rather than absolute units in markup language attribute values and style sheet property values
• Checkpoint 3.5 - Use header elements to convey document structure and use them according to specification
• Checkpoint 3.6 - Mark up lists and list items properly
• Checkpoint 3.7 - Mark up quotations. Do not use quotation markup for formatting effects such as indentation

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:

• Elements: PRE | IMG | OBJECT | APPLET

Suggested message:

• When an appropriate markup language exists, use markup rather than images to convey information. For example, use MathML to mark up mathematical equations, and style sheets to format text and control layout

Suggested repair:

• Display a user notification if any of these possible conversion elements are in the document.
• Help authors convert decorative ASCII art in PRE elements to SVG or an image format. @@CR - Is this necessary? We already prompt for a text description of ASCII art.
• Help authors convert ASCII art representing tables of data in PRE elements to TABLE elements.
• Help authors convert images (IMG or OBJECT) used to format text to XHTML/XML with style sheets.
• Help authors convert images (IMG or OBJECT) used to format mathematical equations to MathML.

Checkpoint 3.2 - Create documents that validate to published formal grammars

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

Discussion Status:

• @@reference BizTalk and OASIS catalogs?

Evaluation:

• Element: none  (i.e. applies to all documents)
• Requirements:
  • Document must contain a <!DOCTYPE ...> declaration
  • Document type must conform to the HTML specification and the list of public text identifiers

Suggested message:

• If no <!DOCTYPE ...> at all: Missing language identifier for this document.
• If document type is defined in HTML element: "Document type should be in the document type definition.  It's use in the HTML element is deprecated  @@ added by LRK.

Suggested repair:

• If the document type is in the HTML element: move to the <!DOCTYPE ...> declaration.
• If no valid document type at all: Prompt the user for a public text identifier, preferably by offering a menu of choices and explanations @@LRK added menu

Test Files and Discussion Files:

• Link to test file for this technique.

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:

• Elements: none (i.e. applies to all documents)
• Requirements: Document must contain at least one of the following:STYLE or LINK rel="stylesheet" elements within the HEAD element | "style" attributes on any element | FONT | BASEFONT | "text," "vlink," "link," and "alink" attributes on BODY.
• If layout tables are identified (see technique 5.1.1), trigger this check as well. @@CR - Is this necessary? We will inform user that style sheets can be used instead of layout tables in 5.1.1.

@@CR - We are suggesting that all documents require a style sheet. Is this really necessary?

Suggested message:

• Use style sheets to control layout and presentation. For example, use the CSS 'font' property instead of the HTML FONT and BASEFONT elements to control font styles

Suggested repair:

• If style sheets are not used, verify that the author has chosen not to modify the presentation in any way.
• If FONT or BASEFONT elements or "text," "vlink," "link," and "alink" attributes on BODY, suggest or help the author convert the presentation properties to style sheets.
• If the author chooses to convert deprecated markup to style sheets or add style sheets, trigger technique 6.1 to verify that the document is readable when style sheets are not applied.

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:

• Elements:
  • "style" attribute on any element OR
  • STYLE @@CR- STYLE itself does not have size parameters. Remove?
• Requirements For any HTML or CSS element defined to take a %LENGTH, %PIXELS, %MULTILENGTH, or %MULTILENGTHS, (@@CR - we should list all of these) a validated value should either end with "%" or begin with "+" or "-" or use the "em" or "ex" units.
• Exception: "width" and "height" attributes of IMG elements. @@CR - What about width & height of OBJECT and APPLET?

Suggested message:

• This element uses absolute units of measure rather than relative units of measure.

Suggested repair:

• Allow user to change the units of measure as follows:
  1. Allow user to specify which of the absolute sizes is the default
  2. Automatically compute all others in terms of the default, with choice of %, +/-, or em/ex  @@LRK

Test Files and Discussion Files:

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:

• Elements: Header elements (H1-H6)

• Requirements: Header elements should nest according to the following rules
  1. Header levels must not increase by more than 1 level. Example: H2 following H1 is good. H3 following H1 is bad.
  2. Header elements can decrease by any level. Example: H2 following H5 is OK.

Suggested message:

• Improper header nesting: Header levels must not increase by more than one level per heading. Do not use headings to create font effects; use style sheets to change font styles.

Suggested repair:

• Allow user to modify the header numbering within the document.

Test Files and Discussion Files:

• Link to test file for this technique.

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

Evaluation:

• Element:<P>
• Requirement: Paragraphs should be verified that they are not headings. Potential headings can be identified by:
  1. Text elements occur within a paragraph AND
  2. The paragraph is less than 10 words AND
  3. The paragraph contains only text items or formatting elements AND
  4. All text in the paragraph is formatted as bold and/or italics and/or underline.

Suggested message:

• Text has been identified that could possibly be a header. Is this text used as a header: [potential header text]?

Suggested repair:

• Allow user to convert the text to a header.

Test Files and Discussion Files:

• Link to test file for this technique.

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

Evaluation:

• Elements: Header elements (H1- H6)
• Requirement: If a header element's text content is longer than 20 words, query the user.

Suggested message:

• Header elements (H1 - H6) should be used to define headers and should not be used for formatting text.

Suggested repair:

• Allow the user to convert any header text to another type. Possible types are:
  1. Paragraph
  2. Blockquote

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:

• Elements:
  • UL
  • OL
  • DL
• Requirements
  • Each UL/OL/DL tag must be followed by at least one LI. (This avoids the use of lists to create formatting e.g. via <UL><UL><UL>... )
  • Suspicious: a single LI, which may be used merely for formatting

• Not allowed: LI element used outside of an OL, UL, DIR, or MENU element.
• Not allowed: DT or DD element used outside of a DL element @@LRK this is redundant with of "valid HTML" requirement

Suggested message:

• List items should not be used for formatting text. Use Style sheets or tables for formatting text.

Suggested repair:

• Allow the user to format the text within the LI element to another element via  a choice of
  • Style sheets OR
  • Tables  

Test Files and Discussion Files:

• Link to discussion on this technique.

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:

• Q is not supported in today's browsers, thus converting quotes marks to Q will basically delete the quote marks for all users. what do we suggest in the meantime?

Evaluation:

• Element: <P> [list of others?] elements
• Requirement: quote should be marked up with Q or BLOCKQUOTE. Potential quotes can be identified by:
  1. Any text that is enclosed by quote marks (" " or ' ').
  2. Indented text.
  3. Lots of emphasized text (>x words??)

Suggested message:

• The following text may need to be marked using Q or BLOCKQUOTE: [potential quote text].

Suggested repair:

• Allow the user to convert blocks of text to Q or BLOCKQUOTE.

Test Files and Discussion Files:

• Link to test file for this technique.

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

Evaluation:

• Elements: Q and BLOCKQUOTE
• Requirement:
  • Inline quotes (marked with Q) have at least one word in front of, or behind, the quote text and are less than 10 words
  • Long quotes (marked with BLOCKQUOTE) are greater than 10 words.

Suggested message:

• If a block of text is marked as BLOCKQUOTE when it should be marked as Q: This text should be marked as Q not BLOCKQUOTE: [quote text].
• If a block of text is marked as Q when it should be marked as BLOCKQUOTE: This text should be marked as BLOCKQUOTE not Q: [quote text].

Suggested repair:

• Allow the user to convert blocks of text to Q or BLOCKQUOTE or vice versa.

Test Files and Discussion Files:

• Link to test file for this technique.

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

Evaluation:

• Element: <BLOCKQUOTE>
• If text enclosed by BLOCKQUOTE has quote marks ("" or '') then do not present this notification. @@??
• Nested BLOCKQUOTEs is not allowed.

Suggested message:

• This text should be marked as normal text but formatted using style sheets or a table.
• BLOCKQUOTEelements should be used to define quotes and should not be used for formatting text.

Suggested repair:

• Allow the user to transform the text in the BLOCKQUOTE element into a P (paragraph) element.

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)
• Checkpoint 4.2 - Specify the expansion of each abbreviation or acronym in a document where it first occurs
• Checkpoint 4.3 - Identify the primary natural language of a document

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:

• Element: none (i.e. applies to all documents that contain text)
• Requirement: The document must contain at least 3 words of text.

Suggested message:

• Any words or phrases in a document that are not in the primary language of the document should be identified.

Suggested repair:

• Display the above user notification and provide the following suggestions:
  • For blocks of text that are not in the primary language and are already enclosed by markup elements such as Paragraph, DIV or EM, set the "lang" attribute of the markup element.
  • For words or phrases that are not in the primary language, enclose them with a SPAN element and set the SPAN element's "lang" attribute.
  • Ensure that all captions and other text equivalents are checked.

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:

• Elements: none (i.e. applies to all documents that contain text)
• Requirements:
  • Document must contain at least 3 words.
  • Document contains a potential abbreviation or acronym.

Definition of potential abbreviation:

• Any word greater than 2 characters that is all capital letters

Definition of potential acronym:

• Any word that starts with a capital letter, contains lower case characters and ends with a period.

Suggested message:

• A potential acronym/abbreviation has been discovered: [potential acronym/abbreviation].

Suggested repair:

• Ask the user if the acronym or abbreviation was defined elsewhere on the page and if so give the user the option to re-use it.
• Allow the user to enter a definition for the abbreviation of acronym.

Test Files and Discussion Files:

• Link to discussion file for this technique.

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:

• Element: <HTML>
• Requirements: Must contain a valid "lang" attribute

Definition of valid "lang" attribute:

• Must be one of the ISO 639 language codes.

Suggested message:

• Missing "lang" attribute: The primary language of this document has not been set.
• Invalid "lang" attribute: The primary language of this document is invalid.

Suggested repair:

• Prompt the user for the primary language of the document.
• Ensure that the language entered is one of the ISO 639 language codes.

Test Files and Discussion Files:

• Link to test file for this technique.
• Link to discussion file for this technique.

Guideline 5. Create tables that transform gracefully

• Checkpoint 5.1 - For data tables, identify row and column headers
• 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
• Checkpoint 5.3 - Do not use tables for layout unless the table makes sense when linearized
• Checkpoint 5.4 - If a table is used for layout, do not use any structural markup for the purpose of visual formatting
• Checkpoint 5.5 - Provide summaries for tables
• Checkpoint 5.6 - Provide abbreviations for header labels

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:

• Data tables present relational data such as a bus schedule, a comparison of regional sales figures, or a listing of employee contact information. Cells in data tables are related to each other and usually must be perceived as a group.
• Layout tables visually format images, text, and other information on the page such as a navigation bar, or a newspaper page with stories, links, and images. Each cell in a layout table is normally independent and can be viewed on its own.

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

Evaluation:

• Element: <TABLE>.
• Requirement: the table must have at least one complete row of headers or one complete column of headers.
• This technique applies only to tables used for data, not to tables used for layout purposes.

Suggested message:

• If both row and column headers are missing: Table is missing headers.
• If either row or column headers are missing: Table has row/column headers but may require column/row headers.

Suggested repair:

• Allow the user to modify the table to include row headers and/or column headers.
• Allow the user to convert the top row and/or the left column to headers.
• The user should create at least one complete row or one complete column of headers.

Test Files and Discussion Files:

• Link to test file for this technique.

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:

• Element: <TH span=(2 or more)>  and either
  • two or more TR elements containing at least one TH
  • two or more TH elements within any TR
• Requirements:
  • use of SCOPE | AXIS | HEADER
  • two or more rows containing TH OR  
  • two or more columns contain TH

Suggested message:

• Your table should identify structural groups of rows and groups of columns. Label table elements with the "scope", "headers", and "axis" attributes so that future browsers and assistive technologies will be able to select data from your table by filtering on categories.

Suggested repair:

• If the table does contain 2 or more logical levels of row or column headers, use the HTML 4 table algorithm to show the author how the headers are currently associated with the cells. If the author determines that the current mark-up is not sufficient, allow the author to markup the table TD or TH elements with scope, axis, or headers attributes.

• Link to test file for this technique.

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:

• Element: <TABLE>
• Requirement: Layout tables should make sense when linearized. This technique applies only to tables used for layout purposes, not to data tables.

Suggested message:

• Tables used for layout should make sense when linearized.
• When a table is 'linearized,' the cells are read in the order in which they appear in the HTML source.

Suggested repair:

• Linearize the table and ask the author to verify that the result is understandable.

Test Files and Discussion Files:

• Link to test file for this technique.

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:

• Element: <TABLE>
• Requirements: Contains at least one TH element. This technique applies only to tables used for layout purposes, not to data tables.

Suggested message:

• Tables used for layout should not use table headings to create formatting effects.

Suggested repair:

• Allow user to change appearance of TH cells by
  • style sheet properties
  • EM and/or STRONG

Test Files and Discussion Files:

• Link to test file for this technique.

Checkpoint 5.5 - Provide summaries for tables

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

Evaluation:

• Element: <TABLE>
• Requirement: Must have valid "summary" attribute.
• If the table has nested headings, cells that span multiple columns or rows, or other relationships that may not be obvious from analyzing the structure of the table but that may be apparent in a visual rendering of the table, a valid "summary" attribute may be provided. @@CR - All tables require summary not just these ones.

Definition of valid "summary" attribute:

• Not allowed - NULL "summary" value ("")
• Not allowed - "summary" value of spaces (" ")
• Suspicious - placeholder "summary" value

Suggested message:

• For missing summary - "Table is missing a summary." "In the summary, describe the purpose of the table (either layout or data). For example ''This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar.
• Additional help text: A summary of the relationships among cells is especially important for tables with nested headings, cells that span multiple columns or rows, or other relationships that may not be obvious from analyzing the structure of the table but that may be apparent in a visual rendering of the table. A summary may also describe how the table fits into the context of the current document. If no caption is provided, it is even more critical to provide a summary. @@CR- "Additional help" is beyond the scope of this document.

Suggested repair:

• Allow the user to enter a summary of the table.

Test Files and Discussion Files:

• Link to test file for this technique.

Checkpoint 5.6 - Provide abbreviations for header labels

Technique 5.6.1 [priority 3] Check table for header abbreviations

Discussion Status:

• How determine if an abbreviation is pronounceable? ASCII characters only?

Evaluation:

• Element: <TH>
• Requirement: Valid "abbr" attribute if the header name is greater than 15 characters.

Valid "abbr" attributes:

• Not allowed - NULL "abbr" value ("")
• Not allowed - "abbr" value of spaces (" ")
• Suspicious - placeholder "abbr" values
• "abbr" values should be shorter than 15 characters, but still pronounceable.

Suggested message:

• Table header is missing an abbreviation.

Suggested repair:

• Allow user to enter abbreviations for table header elements.

Test Files and Discussion Files:

• Link to test file for this technique.

Guideline 6. Ensure that pages featuring new technologies transform gracefully

• Checkpoint 6.1 - Organize documents so they may be read without style sheets
• Checkpoint 6.2 - Ensure that equivalents for dynamic content are updated when the dynamic content changes
• Checkpoint 6.3 - Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported
• Checkpoint 6.4 - For scripts and applets, ensure that event handlers are input device-independent
• Checkpoint 6.5 - Ensure that dynamic content is accessible or provide an alternative presentation or page

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:

• Elements:
  • <LINK rel="stylesheet">
  • <STYLE>
  • At least one "style" attribute used on any element.

Suggested message:

• Ensure this document can be read without style sheets.

@@link to CSS module how to make readable.

Suggested repair:

• Display a user notification if any use of style sheets is detected.

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:

• Elements: FRAME or IFRAME
• Requirements:
  • Valid "src" attribute values must have a suffix of ".htm," ".html," ".shtm," ".shtml," ".cfm," ".cfml," ".asp," ".cgi," ".pl" (@@what are the extensions for SMIL and MathML files?) or target document must have a known public identifier at the top of file.

Suggested message:

• Frame source: [frame source file name] is not a valid markup file.

Suggested repair:

• Create an HTML "wrapper" around known object types, e.g. if the target is an image, place the image in an HTML file.
• Adjust Javascript to point inside the wrapper   @@LRK:  (yikes you say? well, we can ask...)

Test Files and Discussion Files:

• Link to test file for this technique.
• Link to discussion on this technique.

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

@@is that really what we want to say here? This gets into issues related to Guideline 7. I guess we could tie them together in some way...?

Evaluation:

• Elements: SCRIPT, APPLET, OBJECT  type=@@?, any_element  event_attribute where event_attribute is "onmouseover" etc.
• Requirements: any actions that change the display must change the equivalent @@LRK::Is this computable in a practical time (cf. NP complete) .  Computer science help needed here.  Of course, as in other parts of document, the fact that the equivalent changes is no guarantee that equivalent is correct than it is guaranteed that "alt" text for an image is correct.

Suggested message:

• Ensure that the descriptions of dynamic content are updated with changes in the dynamic content.

Test Files and Discussion Files:

• Link to test file for this technique.
• Link to discussion on this technique.

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:

• Elements: SCRIPT @@CR- covered in 1.1.11, OBJECT type=@@?, EMBED, APPLET
• Requirements: existence of "alt" and/or "title" and/OR contained alternatives, as appropriate. @@contained alternatives?? @@CR- Alt & Title are not enough. This calls for alternate content
• Between the start and end elements must be an accessible alternative representation of the object.

Suggested message:

• Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported.

Suggested repair:

• Provide means to create an accessible alternative representation or provide a link to one.

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:

• Elements: SCRIPT, OBJECT  type=@@?, EMBED, APPLET
• Requirements: Objects must not contain device dependent event handlers. @@LRK: need help here. @@CR- Yikes, must we parse Java and script code?

Suggested message:

• For scripts and applets, ensure that event handlers are input device-independent.

Suggested repair:

• Display object source code and suggest device independent replacement code.

Test Files and Discussion Files:

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:

• Element: <FRAMESET>
• Requirements:
  • A valid NOFRAMES section should exist within each FRAMESET section

Definition of valid NOFRAMES section

• Must contain at least one word of text or accessible HTML code.
• The contents of the NOFRAMES element must allow the user access to the site. @@CR- I'm not sure what this means?
• Not allowed: Telling the user that they should upgrade to a browser that supports frames. Suspicious words within the text of a NOFRAMES element: "upgrade," "full advantage," supports frames," "missing" etc.

Suggested message:

• Does your page work if frames are not loaded?

Suggested repair:

• Allow user to construct a valid NOFRAMESsection.

Test Files and Discussion Files:

• Link to test file for this technique.

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

@@CR - Isn't 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.
• Checkpoint 7.2 - Until user agents allow users to control blinking, avoid causing content to blink
• Checkpoint 7.3 - Until user agents allow users to freeze moving content, avoid movement in pages
• Checkpoint 7.4 - Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages
• Checkpoint 7.5 - Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically

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:

• It is desirable that a tool be able to measure flicker. This could be done by software that renders, takes screenshots and compares. [Len Kasday, 23 January 2000]

Evaluation:

• Elements:
  • <SCRIPT>
  • <OBJECT type =>(@@what are the type attribute values for Java, etc.?)
  • <EMBED>
  • <APPLET>
  • <IMG> element with "src" name ending with '.gif'.

Suggested message:

• Display flicker is distracting and may be dangerous to some users. Please ensure this element does not cause the display to flicker.

Suggested repair:

• Display the object and allow the user to verify that it does not cause display flicker. If object does cause flicker, allow user to modify object.

Test Files and Discussion Files:

• Link to test file for this technique.

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:

• Element: <BLINK>

Suggested message:

• The BLINK element is not defined in any W3C HTML specification and should not be used.

Suggested repair:

• Allow the user to remove BLINK elements from the document.
• Allow the user to replace BLINK elements with any of the following elements:
  1. STRONG
  2. EM
  3. SPAN- allow the user to enter attributes for the element.
  4. H1
  5. H2
  6. H3
  7. H4
  8. H5
  9. H6

Test Files and Discussion Files:

• Link to test file for this technique.

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:

• Element: <MARQUEE>.

Suggested message:

• The MARQUEE element is not defined in any W3C HTML specification and should not be used.

Suggested repair:

• Allow the user to remove MARQUEE elements from the document.
• Allow the user to replace MARQUEE elements with any of the following elements:
  1. STRONG
  2. EM
  3. SPAN - allow the user to enter attributes for the element.
  4. H1
  5. H2
  6. H3
  7. H4
  8. H5
  9. H6

Test Files and Discussion Files:

• Link to test file for this technique.

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

Evaluation:

• Elements:
  • SCRIPT - distinguished by (see discussion)??
  • OBJECT type =(@@what are the type attribute values for Java, etc.?)
  • EMBED
  • APPLET

Suggested message:

• Moving text may be difficult to read and is inaccessible for many viewers.

Suggested repair:

• Allow the user to remove the SCRIPT from the document or create a mechanism to stop the movement.
• @@ what about OBJECT, EMBED, and APPLET?

Test Files and Discussion Files:

• Link to discussion file for this technique.

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:

• Elements: META  http-equiv="refresh"  content=integer_greater_than_zero
• Note:If the "content" attribute is a URI this is an auto-redirect page. Refer to technique 7.5.1

Suggested message:

• This page uses auto-refresh which can make the page difficult to read for some people.

Suggested repair:

• Allow user option to either:
  • Remove the auto-refresh from the document OR
  • Create a page with link to new page.

Test Files and Discussion Files:

• Link to test file for this technique.

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:

• Element: <META http-equiv="refresh" content="any-URI">.

Suggested message:

• This page uses auto-redirect which can make the page difficult to read for some people.

Suggested repair:

• Allow the user to remove the auto-redirect from the document and add a link to the new document.

Test Files and Discussion Files:

• Link to test file for this technique.

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.

Discussion Status:

• Tools should include means to test the embedded technologies, e.g. java, at least by running them, preferably by including any test software supplied for the technology. [Len Kasday - 23 January 2000]

Evaluation:

• Elements: OBJECT, APPLET, EMBED or SCRIPT.

Suggested message:

• This element may not be accessible to all users. Please ensure there is an accessible interface to this object.
• Ensure that scripts, applets, or other programmatic objects are directly accessible

Suggested repair:

• Display a user notification if any of the programmatic elements are in the document.

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.
• Checkpoint 9.2 - Ensure that any element that has its own interface can be operated in a device-independent manner.
• Checkpoint 9.3 - For scripts, specify logical event handlers rather than device-dependent event handlers.
• Checkpoint 9.4 - Create a logical tab order through links, form controls, and objects.
• Checkpoint 9.5 - Provide keyboard shortcuts to important links, form controls, and groups of form controls

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:

• Element:<IMG "ismap">

Suggested message:

• Use client-side image maps instead of server-side maps.

Suggested repair:

• Allow the user to convert the server-side image map to a client-side image map.

Test Files and Discussion Files:

• Link to test file for this technique.

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.

@@Programmatic objects check in 6.5 and 8.1.A Need clarification. Strongly tied to Guideline 8.

Evaluation:

• Elements:
  • OBJECT type =(@@what are the type attribute values for Java, etc.?)
  • EMBED
  • APPLET

Suggested message:

• Ensure this programmatic object can be operated in a device independent manner.

Suggested repair:

• Display a user notification if any of the programmatic objects are in the document.

Test Files and Discussion Files:

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:

• Elements: All elements that can contain event handlers
• Requirement: Elements must have a device independent event handler if they have any of the following device dependent event handlers:
  • onMouseDown()
  • onMouseUp()
  • onClick()
  • onMouseOver()
  • onMouseOut()
  • onMouseMove()

Suggested message:

• For scripts, specify logical event handlers rather than device-dependent event handlers.

Suggested repair:

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

• "onMouseDown" add or replace with "onKeyDown"
• "onMouseUp" add or replace with "onKeyUp"
• "onClick" add or replace with "onKeyPress"
• "onMouseOver" add or replace with "onFocus"
• "onMouseOut" add or replace with "onBlur"
• "onMouseMove" remove or replace with ??@@

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

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

Evaluation:

• Elements:
  • <A>
  • <AREA>
  • <BUTTON>
  • <INPUT>
  • <OBJECT>
  • <SELECT>
  • <TEXTAREA>
• Requirements:
  • Must contain a valid "tabindex" attribute. @@CR- Can this be optional?

Definition of valid "tabindex" attribute:

• Must be an integer greater than or equal to zero.

Suggested message:

• These controls are missing a tab order. A tab order makes controls easier to navigate for many users.

@@LRK:: Issue: if the tabindex jumps around too much it could be confusing to someone using magnification or a cognitive disability.

Suggested repair:

• Display the controls and allow the user to set the tabindex of each.

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:

• Elements:
  • <A>
  • <AREA>
  • <BUTTON>
  • <INPUT>
  • <LABEL>
  • <LEGEND>
  • <TEXTAREA>
• Requirements:
  • If any of these elements are present, at least one of them should have a valid "accesskey" attribute

Suggested message:

• There are no keyboard shortcut keys to any of the controls in this document. Important links and controls should have shortcut keys.

Suggested repair:

• Display the objects that can contain shortcut keys and allow the user to assign shortcut keys to them.

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

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

Discussion Status:

• @@ how do we handle the "until user agents" clause?

Evaluation:

• Elements:
  • <A>
  • <AREA>
• Requirements:
  • Should not have "target" attributes of "_blank" or "_new".

Suggested message:

• This anchor element [anchor text] will open a new window that can disorient some users.

Suggested repair:

• Allow the user to
  • remove the "target" attribute or
  • use an existing window as the target
  • @@CR - If the document informs the user that the link will open in a new window is that enough?

Test Files and Discussion Files:

• Link to test file for this technique.
• Link to discussion on this technique.

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

Evaluation:

• Elements:
  • SCRIPT
  • APPLET
  • @@other embedded scripting languages?
• Requirement: SCRIPT must not contain code of window.open()
• @@CR - All applets get warning message?

Suggested message:

• This script will open a new window that can be disorienting for some users.

Suggested repair:

• Allow the user to remove the scripting code that opens a new window.

@@CR - got to here

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:

• Create a separate technique for LEGEND and LABEL? [Michael Cooper - 28 January 2000]

Evaluation:

• Elements:
  • INPUT
  • SELECT
  • TEXTAREA
• Requirement: A label for a text area, a text input control or group of controls (e.g., a group of checkboxes) must immediately precede its control (or group of controls) on the same line (if there is only one control or group) or be in the line preceding the control (or group of controls).

Suggested message:

• A label for a text area, a text input control or group of controls (e.g., a group of checkboxes) must immediately precede its control (or group of controls) on the same line (if there is only one control or group) or be in the line preceding the control (or group of controls).

Suggested repair:

• Allow the user to reposition labels associated with form controls as follows:
  • Labels for radio buttons and checkboxes should appear after the radio button or checkbox. For example: [checkbox] oranges, [checkbox] apples.
  • Labels for text fields appear before the text field. For example: last name [text area].
  • Labels for groups of any form control should appear before the group. For example: choose a city [radio button] Boston [radio button] Madison.

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:

• Element: <TABLE>
• Requirement: A linear version of the table is provided

Suggested message:

• Please consult the definition of linearized table. This checkpoint benefits people with user agents (such as some screen readers) that are unable to handle blocks of text presented side-by-side; the checkpoint should not discourage content developers from using tables to represent tabular information.

Suggested repair:

• If it has been determined that the table is used for layout (see Technique 5.1.1) then create a linear version of the table by: [@@insert heuristics from table linearizer - basically replace TABLE markup with text structural markup]. The author will then need to check that it is readable.
• If it has been determined that the table is used for data (see Technique 5.1.1) then create a linear version of the table by: [@@table linearizer heuristics? basically, for each cell repeat the column and row headers associated with it]. The author will then need to check that it is readable.

Test Files and Discussion Files:

• Table linearizer
• Trace "HelpDB"
• other examples

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:

• Elements:
  • INPUT
  • TEXTAREA
  • OPTION
• Requirements
  • Check INPUT type="text" for valid "value" attribute.
  • Check INPUT type="checkbox" | "radio" with the same "name" attribute for one of them to have a "selected" attribute.
  • Check TEXTAREA for valid text content.
  • Check all OPTIONs in a SELECT element for one of them to have a "selected" attribute.

Suggested message:

• none.

Suggested repair:

• For INPUT type="text" and TEXTAREA elements, ask the user for default text or suggest a space.
• For groups of radio buttons, checkboxes, and selection boxes, ask the user to pick one to be the default.

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:

• Element: <A>
• Requirement: Check for at least one non-whitespace character surrounded by at least one whitespace character between every close A and open A element. Whitespace is a space, tab, CR, or &nbsp;

Suggested message:

• none.

Suggested repair:

• Suggest that the author select to use vertical bars "|" between A elements, but allow them to choose another character if they prefer. Insert the selected character surrounded by white space between each </A> and <A> element.

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
• Checkpoint 11.3 - Provide information so that users may receive documents according to their preferences
• 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

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.

Evaluation:

• Element: ?@@
• Requirements:
  • Check for uses of non-W3C technologies such as: PDF, Flash, GIF images, JPG images, proprietary HTML elements (@@other major ones??).
  • @@See 1.1.1 for images used for mathematical equations.
  • Note. I left out JavaScript because there is not a W3C equivalent technology yet.

Suggested message:

• Non-W3C technology used: W3C technologies have been reviewed for accessibility issues throughout the design phase and have accessibility built-in. Many non-W3C formats require specific applications (often called plug-ins) that are inaccessible or do not work well with assistive technologies. Using W3C technologies will tend to make pages more accessible to more people using a wider variety of hardware and software. If inaccessible technologies (proprietary or not) must be used, equivalent accessible pages must be provided.

Suggested repair:

• Suggest that where appropriate, the author:
  • convert quicktime movies (others?) into SMIL presentations.
  • convert GIF and JPG images with text to text with style sheets.
  • convert Flash animations to a combination of valid HTML, SMIL, and PNG or SVG.
  • @@convert images of math equations to MathML.
• @@Note: many of these W3C formats are not widely supported yet. Therefore, how do we deal with this in the meantime? Present the info and let the author decide?
• Use a text-only page generator (such as Adobe's PDFtoText) to create an equivalent accessible page.

Checkpoint 11.2 - Avoid deprecated features of W3C technologies

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

Evaluation:

• Elements: APPLET, BASEFONT, CENTER, DIR, FONT, ISINDEX, MENU, S, STRIKE, and U. (Refer to the list of deprecated elements in the HTML 4.01 specification.)
• Requirements:
  • Use W3C validation services to validate documents as per their public text identifier.
  • See checkpoint 3.2 for more information on public text identifiers.

Suggested message:

• Use of deprecated HTML element: you are validating against [public text identifier] and the following elements have been deprecated in favor of newer elements. [insert list of deprecated elements used in the page with what they should be replaced with].

Suggested repair:

• Help the author replace FONT with use of CSS.
• Help the author replace IMG and APPLET with OBJECT.
• @@Others?

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:

• Element: ?@@
• Requirement: ?@@

Suggested message:

• none.

Suggested repair:

• Prompt user to specify language of document in technique 4.3.1.
• Use CC/PP or XML/XSLT or other transformations on the server or gateway to configure a page for various user preferences and device profiles.
• Serve style sheets based on user preferences - use the media types.
• Work with your server system administrator to provide content negotiation.
• Use browser sniffing on the client to request documents on the server.
• Use cookies to remember user preferences between sessions and server documents per those preferences.
• Link to other versions of the document (other formats and languages).
• If not possible to use content negotiation, indicate content type or language through markup (e.g., in HTML use "type" and "hreflang").

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:

• Elements: not applicable
• Requirements: For each page, keep track of which checkpoints the author has passed, either through automatic evaluation or confirmed through prompting the author. Ask what level of conformance the author is trying to reach. If checkpoints for that level have not yet been met, ask the author if they would like to continue working to make the page accessible. If they do not, ask them if they would like to provide an alternative, accessible page.

Suggested message:

• Before resorting to an alternative page, reconsider the design of the original page; making it accessible is likely to improve it for all users.

Suggested repair:

• Dynamically generated alternative pages [references@@].
• Tools to generate alternative pages [references@@].

Guideline 12. Provide context and orientation information

• Checkpoint 12.1 - Title each frame to facilitate frame identification and navigation
• Checkpoint 12.2 - Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone
• Checkpoint 12.3 - Divide large blocks of information into more manageable groups where natural and appropriate
• Checkpoint 12.4 - Associate labels explicitly with their controls

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:

• Element: <FRAME>
• Requirement:a FRAME element must have valid "title" attribute
  • Not allowed - NULL value ("")
  • Not allowed - spaces (" ")
  • Suspicious - placeholder title text

Suggested message:

• Missing title for this frame: [frame file name].

Suggested repair:

• Prompt user for frame title.

Test Files and Discussion Files:

• Link to test file for this technique.

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

@@ isn't this 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:

• Element: <INPUT>
• Requirement: Check that the "for" attribute value of a LABEL element matches the "id" value of a form control on the current page.

Suggested message:

• Form controls are not explicitly labeled.

Suggested repair:

• If a LABEL does not have a valid "for" attribute, list all of the controls without explicitly associated labels and let the author pick one.
• If a form control does not have a LABEL, verify that the author has implicitly associated text with the form control then help the author convert associated text into a LABEL element.

Guideline 13. Provide clear navigation mechanisms

• Checkpoint 13.1 - Clearly identify the target of each link
• Checkpoint 13.2 - Provide metadata to add semantic information to pages and sites
• Checkpoint 13.3 - Provide information about the general layout of a site
• Checkpoint 13.4 - Use navigation mechanisms in a consistent manner
• Checkpoint 13.5 - Provide navigation bars to highlight and give access to the navigation mechanism
• 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
• Checkpoint 13.7 - If search functions are provided, enable different types of searches for different skill levels and preferences
• Checkpoint 13.8 - Place distinguishing information at the beginning of headings, paragraphs, lists, etc
• Checkpoint 13.9 - Provide information about document collections
• Checkpoint 13.10 - Provide a means to skip over multi-line ASCII art

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:

• Element: <A>
• Requirements:
  • Check for commonly used non-meaningful phrases such as "click here" and "more" as link text.
  • Check that if link text is not unique, duplicates link to the same place.

Suggested message:

• Link text should be meaningful enough to make sense when read out of context -- either on its own or as part of a sequence of links. Link text should also be terse.

Suggested repair:

• Retrieve the TITLE of the target page and suggest that as link text.
• If the author is trying to make a Level Triple A site, Ask the author to provide supplemental information about the link in the "title" attribute.

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:

• Elements:
  • META
  • ADDRESS
  • TITLE
  • LINK
• Requirements: Check for META, ADDRESS, TITLE and LINK elements in the HEAD element of HTML/XHTML files.

Suggested message:

• none.

Suggested repair:

• If no META, ADDRESS, TITLE or LINK elements are found, request information from the author to be stored as meta information. Examples of content to prompt for:
  • title of the page (required for frames, see checkpoint 12.1),
  • type of content,
  • descriptions of the content of the page,
  • conformance claims,
  • author information,
  • next page in a series (e.g., LINK rel="next").
• If a LINK element is found, check if it is used for style sheets. If it is, then proceed as if no LINK element were found.
• If a META element is found, check if it is used to create a redirect. If it is, then proceed as if no META element were found (refer also to checkpoints 7.4 and 7.5).

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

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

Checkpoint 13.4 - Use navigation mechanisms in a consistent manner

Evaluation:

• Elements: Not applicable
• Requirements: Not applicable

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

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

Discussion status:

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

Evaluation:

• Element: Several <A> elements all in one row or column of table and/or separated only by
  • spaces,
  • bullets,
  • BR elements,
  • or a few characters such as "] [" or " | " or
• Requirement: links should be grouped by SPAN,DIV or MAP elements. @@DIV or SPAN?

Suggested message:

• Groups of links should be grouped with a structural element.

Suggested repair:

• Ask the user if an identified list of links should be grouped.
• If the user wants to group the links, use one of the following techniques
  • a MAP element (@@still outstanding issues in WCAG w/this technique?)
  • SPAN or DIV with appropriate "title"  @@??
• Suggest that the user provide a link to bypass the group or that they move the group to the bottom of the page or that they use a high "tabindex" attribute value.

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:

• Element: <FORM>
• Requirement: Check if a FORM is used to submit a search.

Suggested message:

• When providing search functionality, content developers should offer search mechanisms that satisfy varying skill levels and preferences. Most search facilities require the user to enter keywords for search terms. Users with spelling disabilities and users unfamiliar with the language of your site will have a difficult time finding what they need if the search requires perfect spelling. Search engines might include a spell checker, offer "best guess" alternatives, query-by-example searches, similarity searches, etc.

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

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

Discussion Status:

• @@Way to use RDF to describe document collections?

Evaluation:

• Elements: @@? LINK, A
• Requirement: If the page is part of a collection, such as a slide show, or a chapter in a book, the previous and next pages ought to be marked as such.

Suggested message:

• Bundled documents can facilitate reading off-line.

Suggested repair:

• In HTML/XHTML specify document collections with the LINK element and the "rel" and "rev" attributes.
• Suggest that that the author create a collection by building an archive (e.g., with zip, tar and gzip, stuffit, etc.) of the multiple pages.

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.

Discussion status:

• @@This is a new technique
• Can't be machine checked - this sort of ASCII art is larger than just emoticons. User notification?

Evaluation:

• Elements: not applicable
• Requirements: no heuristically found ACSII art @@LRK need heuristics

Example of message to be displayed:

• If this is a picture made of of text characters, it isn't accessible

Suggested repair:

• Provide description of ASCII art and a link to skip past it
  • perhaps make description invisible e.g. as using the "alt" attribute of a transparent image
  • In future, wrap in DIV with descriptive "title"
• Provide means to convert AREA to IMG with "alt" attribute

Guideline 14. Ensure that documents are clear and simple

• Checkpoint 14.1 - Use the clearest and simplest language appropriate for a site's content
• Checkpoint 14.2 - Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page
• Checkpoint 14.3 - Create a style of presentation that is consistent across pages

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

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

Discussion Status:

• @@this requires looking at pages throughout the site. Need two levels of checking: page vs site?

Evaluation:

• Elements: STYLE and LINK
• Requirements:
  • The properties of STYLE elements should be consistent between pages.
  • The names of external style sheets (referenced with LINK elements) should be consistent between pages.
  • This should be verified by the author. There are good reasons to use different styles between pages.

Suggested message:

• Consistent page layout and recognizable graphics benefit all users. In particular, they help people with cognitive disabilities or who have difficulty reading.

Suggested repair:

• If style properties vary between pages, or various external style sheets are used, suggest the author consolidate style properties into external style sheets and use consistently.

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:

• Level "A": all Priority 1 checkpoints are satisfied;
• Level "Double-A": all Priority 1 and 2 checkpoints are satisfied;
• Level "Triple-A": all Priority 1, 2, and 3 checkpoints are satisfied;

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

• an image file suffix (see Appendix B)
• the single word "Image", "Photo"
• the word "images"  (e.g. as in "turn on images").

Appendix B - Image File Suffixes

• .jpg
• .gif
• .png

Appendix C - Placeholder OBJECT text equivalent

• {object text goes here}

Appendix D - Sound File Suffixes

• .wav
• .au
• .snd
• .dwd
• .iff
• .svx
• .sam
• .smp
• .vce
• .voc
• .pcm
• .aif

Appendix E - Placeholder NOSCRIPT text

• {NOSCRIPT text goes here}

Appendix F - Placeholder TABLE "summary" text

• Summary
• Table
• Table Summary

Appendix G - Placeholder table header "abbr" text

• @@

Appendix H - Placeholder FRAME "title" text

• @@

Appendix I - Applet Executable Suffix

• .class
• .java
• .jar
• .zip

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

• Bobby - Accessibility evaluator tool
• Lynx Viewer - Displays a text-only view of web pages
• A-Prompt - Accessibility evaluator and repair tool

Glossary

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.

@@Copyright info? it's at the top...