Techniques For Accessibility Evaluation And Repair Tools

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

• feedback on existing techniques discussed in this document,
• suggestions for new techniques,
• implementation and testing of the techniques discussed in this document.

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 https://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

• Clean up all of the @@'s (open issues, 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 or appropriate.
• Inherit 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 "carview.php?tsp=document" or "page." Then check for consistent usage.
• Ensure that "Web" is capitalized consistently.
• Update and finish creating test files. Upload the images associated with the test files.
• Resolve open issues both listed in this document as well as in the list of open issues.

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

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

Open issues for this technique:

• @@WCAG issue: final word on null and blank alt-text. See discussion at https://lists.w3.org/Archives/Public/w3c-wai-er-ig/1999Jun/0050.html especially part about null or blank alt-text for links. Awaiting results of survey

Evaluation:

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

Valid "alt" attribute:

• "alt" attribute must exist
• Not allowed - NULL "alt" value (alt="carview.php?tsp=")
• 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 - alt-text

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:

• Daniel D. on May 19, 1999 suggested that we could check for the complexity of the image by looking for a "caption" attribute.

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:

• Test file - longdesc.

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="carview.php?tsp=")
• 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.

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="carview.php?tsp=")
• 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:

• Test file - alt for applets.

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:

• This only covers text equivalents. 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]

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:

Test file - OBJECT text equivalent.

Technique 1.1.6 [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:

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:

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

Technique 1.1.8 [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

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:

• Test file - longdesc for FRAMEs.

Technique 1.1.9 [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="carview.php?tsp=")
• 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:

• Test file - alt on AREA.

Technique 1.1.10 [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:

• Test file - text for SCRIPT.

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:

• A-Prompt has been using an algorithm to detect ASCII art (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.) Should we suggest this algorithm in the evaluation?
• What about ASCII art that is interspersed in text, such as in P elements?
• Bill Shackleton suggested that a tool use a library of well-known ascii art to detect some ascii art such as emoticons. Yahoo maintains a list of ascii art one list is specifically about smileys.

Evaluation:

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

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:

• ASCII Art Discussion Page - Yun Jo.

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:

• WCAG issue: text links are a priority 3 if the same image also has a client side map (images can have both a client-side and a server-side).

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

• Test file - server-side image map links.

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
• Requirement: Multimedia presentations should have an associated audio description.

Suggested repair:

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

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:

• Elements:
  • any_tag any_attribute=multimedia_uri,
  • OBJECT type=any_multimedia_type
• Requirement: Multimedia presentations should have synchronized equivalents.

Suggested message:

• For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives

Suggested repair:

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

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

Open issues for this technique:

• This technique is a specific example of 1.4.1. Should it stand on its own or be incorporated into 1.4.1?
• This technique is also SMIL specific while the majority of techniques are HTML specific. Should we include a SMIL specific technique?

Evaluation:

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

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:

• Test file - client-side image map links.

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.

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.

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:

• Test file - color contrast.

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

Open issues for this technique:

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

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

Test Files and Discussion Files:

• Test file - public text identifier.

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 should 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. We will inform user that style sheets can be used instead of layout tables in 5.1.1.

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
• Requirements For any HTML or CSS element defined to take a %LENGTH, %PIXELS, %MULTILENGTH, or %MULTILENGTHS, 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, OBJECT, and APPLET elements.

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 ?

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:

• Test file - header nesting.

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:

• Test file - header markup.

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

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 ?

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 (greater than 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:

• Test file - quote markup.

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.

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

Evaluation:

• Element: BLOCKQUOTE unless text content has quote marks ("carview.php?tsp=" or '').
• Requirement:
  • Not allowed: nested BLOCKQUOTEs.

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.

Potential abbreviation:

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

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.

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

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.
• A (somewhat costly) technique for guessing the primary language, is to check for the use of common words in a language. For example, if you find "a, the, you, for, is, of, and" then it's English. If you find "le, du, la, a, se, pour, aux, des, ne" then it's French, etc.

Test Files and Discussion Files:

• Test file - primary language.

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:

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

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.

• Test file - nested table headers.

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:

• Test file - linearizing tables.

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:

• Test file - table headers for formatting.

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.

Valid "summary" attribute:

• Not allowed - NULL "summary" value ("carview.php?tsp=")
• 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.

Suggested repair:

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

Test Files and Discussion Files:

• Test file - Table summary.

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

Evaluation:

• Element: TABLE
• Requirement: @@

Suggested message:

• This table does not have a caption: A table caption describes the nature of the table in one to three sentences. For example, "Cups of coffee consumed by each senator."

Suggested repair:

• Allow the author to enter a CAPTION

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 ("carview.php?tsp=")
• 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:

• Test file - table header abbreviations.

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.

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", ".smil" 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?

Test Files and Discussion Files:

• Test file - source of frame.

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:

• This is similar to issues related to Guideline 7. do we need to 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 @@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:

• Test file - source of frame.

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, OBJECT type=@@?, EMBED, APPLET
• Requirements:
  • existence of "alt" and/or "title" and/OR
  • accessible alternative content in the body of OBJECT, NOSCRIPT, NOEMBED, or APPLET.

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. @@Does this mean checking Java, Flash, etc? Can we only do this for scripting? Or prompt the author to check?

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.

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

Valid NOFRAMES section

• Must contain at least one word of text or accessible HTML code.
• The contents of the NOFRAMES element must provide the necessary links to navigate the site.
• 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:

• Test file - NOFRAMES.

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

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:

• Test file - blink.

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:

• Test file - marquee.

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:

• Discussion - moving content created by programmatic objects.

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:

• Test file - auto refresh.

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:

• Test file - redirect.

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:

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

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:

• This technique is strongly tied to Guideline 8 and checkpoint 1.1 (image maps). Is there redundancy that we can get rid of?

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.

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

Open issues for this technique:

• If the tab order jumps around too much it could be confusing to someone using magnification or a cognitive disability. Can we check for this?

Evaluation:

• Elements:
  • A
  • AREA
  • BUTTON
  • INPUT
  • OBJECT
  • SELECT
  • TEXTAREA
• Requirements:
  • May contain a valid "tabindex" attribute.

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.

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

Open issues for this technique:

• How do we handle the "until user agents" clause?
• Is it enough for the document to inform the user that the link will open in a new window or must we completely avoid new windows?

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

Test Files and Discussion Files:

• Test file - link targets.

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

Open issues for this technique:

• Do all APPLET elements trigger this technique?
• Are there other embedded elements or scripting languages that ought to trigger this technique?

Evaluation:

• Elements:
  • SCRIPT
  • APPLET
• Requirement: SCRIPT must not contain code of window.open()

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.

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: Text labels must be positioned as the first text immediately before or after the form control.

Suggested message:

• Labels for form controls should be positioned close to their corresponding form controls. This control [control type] does not have a closely positioned label.

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(@@link)
• Trace "HelpDB" (@@link)
• 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 type="text | checkbox | radio"
  • TEXTAREA
  • OPTION
• Requirements
  • INPUT elements that have a type of "text", "checkbox" or "radio" must have at least one word of text in their "value" attribute.
  • Between the TEXTAREA start and TEXTAREA end elements must be at least one word of text.
  • One OPTION in each group contained by SELECT elements must have a "selected" attribute.

Suggested message:

• INPUT element missing value: This form control is missing placeholder text.
• TEXTAREA missing text: This TEXTAREA is missing placeholder text.
• OPTION not selected: At least one OPTION must be selected within this group.

Suggested repair:

• INPUT element missing value: Allow user to enter placeholder text.
• TEXTAREA missing text: Allow user to enter text.
• OPTION not selected: Display all options and allow user to select one as "selected".

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 end element.
• Requirement: A sections within the same line of text must be separated by a sequence of "whitespace, non-whitespace, whitespace".
• Whitespace is a space, tab, CR, or  
• Non-whitespace is any text character.

Suggested message:

• These sequential links do not have separating characters: [sequential links].

Suggested repair:

• Allow user to insert " | " characters between sequential links. Allow user to choose another character other than "|" for separator.

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.

Open issues for this technique:

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

Evaluation:

• Element: ?@@
• Requirements:
  • Check for uses of non-W3C technologies such as: PDF, Flash, GIF images, JPG images, proprietary HTML elements (@@other major ones??).
  • @@link 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.
• 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:
  • Should not be used.
  • See checkpoint 3.2 for more information on public text identifiers.

Suggested message:

• This HTML element [deprecated element] is now deprecated and should not be used. Use this element instead: [replacement element].

Suggested repair:

• Allow the user to replace FONT with CSS.
• Allow the user to replace IMG and APPLET with OBJECT.

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 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: All elements specified in this document.
• Requirements: Check the document for compliance to the WCAG guidelines according to the level specified by the user.

Suggested message:

• This document does not conform to the WCAG guidelines. If you are unable to make the necessary repairs to this document then please create another equivalent page that is accessible and link to it from this document.

Suggested repair:

• Allow user to insert a link in the document to another more accessible page.
• 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: Must have valid "title" attribute .

Valid "title" attribute:

• Not allowed - NULL value ("carview.php?tsp=")
• Not allowed - spaces (" ")
• Suspicious - placeholder title text

Suggested message:

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

Suggested repair:

• Display the frame content and allow user to enter a new title for the frame.

Test Files and Discussion Files:

• Test file - frame titles.

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:

• Elements: INPUT and LABEL
• Requirements:
  • INPUT elements must have a valid "id" attribute.
  • LABEL elements must have a valid "for" attribute that matches the ID of one of the INPUT elements in the document.

Suggested message:

• This form control is not explicitly labeled: [form control].
• This label is not explicitly associated with a form control: [label].

Suggested repair:

• Allow the user to set the "id" attribute for each INPUT element in the document.
• Allow the user to set the "for" attribute of each LABEL element so it matches an INPUT 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:
  • Names must be unique for each target.
  • Must be meaningful
  • Should be terse

Suspicious anchor names:

• click here
• more
• follow this
• greater than 60 characters

Suggested message:

• If non-meaningful text found: This link text may not be meaningful when read on its own: [link text].
• If lengthy text found: This link text is quite long and should be shortened: [link text].

Suggested repair:

• Allow user to change the link text and surrounding text.
• 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: Must have at least one of these elements in the document.

Suggested message:

• This document does not contain any META information.

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

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

• WCAG question: can we suggest that links be grouped by DIV or SPAN?
• WCAG question: is the use of MAP to group links completely agreed upon?

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.

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

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

• Is there a 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.

Open issues for this technique:

• See 1.1.13 for algorithm to find ASCII art

Evaluation:

• Elements: PRE and XMP
• Requirements: A link must be provided to skip over ASCII art.

Example of message to be displayed:

• A link must be provided to skip over this character based (ASCII art) artwork: [display artwork]

Suggested repair:

• Allow user to insert a link in the document that skips over the ASCII art.
• Set title of link to "Skip Over ASCII Art" so it can be detected in future.

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? 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:

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

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