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 http://www.w3.org/TR/.

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

To do

• 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.
• For all "until user agents" clauses we will create techniques for user-side tool. (Refer to minutes from 24 July 2000)
• Currently, links to WCAG Techniques are to the working group draft. Once this goes to public working draft, update the links.
• Link to tools that have implemented specific techniques or to ATAG Techniques (this replaces all of the "Suggested message" and "example language" sections for each technique).
• 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 "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 is an informative document that 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. Tools are not expected to conform to the processes in this document. This is not a definitive list of what an evaluation and repair tool must perform. It is expected that tools may be developed that focus on one technique while others will try to implement all of the techniques depending on the goals of the tool.

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 creating content for the Web 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. However, this document does not address how to interact with the author. Please refer to the Authoring Tool Accessibility Guidelines for information on dialog and interface techniques for creating authoring tools.

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.

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 http://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.
  • "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.

Repair

• Prompt the author 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 the author 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 H.
    • horizontal rules - refer to Appendix I.
  • Valid "longdesc" attribute is any valid URI

Repair

• Ask the author if the image presents information that is not included in the page or in the text equivalent for the image. Allow the author 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.

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.
  • "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 or is of an image mime type.
  • Suspicious - "alt" attribute value is placeholder text.

Repair

• Prompt the author 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
    • 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 or image mime type.
    • 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.

    OR

  • accessible  HTML within APPLET element

Repair

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

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

Repair

• Prompt the author 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.

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

Evaluation

• Elements: A href=sound file
• Requirement: Audio file must be described within the document or document must contain a link to a text equivalent file. @@Search for link text containing the word "transcript?"

Repair

• Prompt the author for a text transcript of the audio file or a link to a transcript.

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.

Repair

• Prompt the author for a text transcript or to link to a 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).
  • Must not be NULL
  • Must be a valid URI
  • The file pointed to by the URI must be accessible HTML
• If a FRAMESET has three or more frames and at least one of the frames does not have a "longdesc" attribute, ask the author to determine if the relationship between frames is obvious (from the titles of each frame) or if the relationship(s) need to be described.

Repair

• If the relationships between frames are not obvious then ask that they provide a description of the relationships. Allow the author 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.

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

Evaluation

• Element:AREA
• Requirement: Elements must have a valid "alt" attribute.
  • Not allowed - NULL "alt" value (alt="")
  • Suspicious - "alt" attribute value is placeholder text.
  • @@is this complete?

Repair

• Prompt the author for "alt" text for the AREA element.
• Fetch the TITLE of the link target.

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

Repair

• Insert NOSCRIPT section
• Allow the author to insert text or link to text equivalent file that describes the 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.

Repair

• Ask the author 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

Repair

• Prompt the author for associated text links OR
• help the author 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, fetch the TITLE of the link target.
• If possible, check the text links against the links contained on the server-side image map by asking the author to upload the server side definition file if it's a standard format.

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.

Open issue

@@Waiting for clarification from WCAG WG.

Evaluation

• Elements:
  • any_tag any_attribute=multimedia_uri,
  • OBJECT type=any_multimedia_type
• Requirement: Multimedia presentations should have an associated audio description.

Repair

• Display the multimedia file and allow the author to create an audio description of the important information.
• Allow the author 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.

Repair

• Give the author the 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.

Repair

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

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

Repair

• Display an author notification if any of the color-possible elements are in the document.
• Display the page without color formatting so the author can see what the page looks like without color.

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.

Repair

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

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

Repair

• Display an author 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:
  • HTML/XHTML documents must contain a !DOCTYPE ... declaration before the root element.
  • A valid XML document must contain a !DOCTYPE ... declaration before the root element, although a well-formed XML document does not have to have a !DOCTYPE ... declaration.
  • Documents of type HTMLmust conform to the HTML specification and the list of public text identifiers
  • Documents of type XHTML must conform to the XHTML 1.0 specification.
  • Documents of type XML must be well-formed and should validate to a public DTD.

Repair

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

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 the author that style sheets can be used instead of layout tables in 5.1.1.
• If CSS is used, validate it (refer to the W3C CSS Validator).

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.

Repair

• Allow the author to change the units of measure as follows:
  1. Allow the author 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.

Repair

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

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.

Repair

• Allow the author to convert the text to a header.

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

Repair

• Allow the author 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 tag must be followed by at least one LI, while each DL must be followed by at least one DT/DD pair. (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

Repair

• Allow the author to format the text within the LI, DT, or DD 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 quote marks to Q will basically delete the quote marks for all authors. 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 - text that begins with a tab character or style sheets have been used to create a wider left margin and possibly a wider right margin.
  3. Lots of emphasized text (greater than x words??@@)

Repair

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

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.
  • The whole page or large sections of a page are not marked with BLOCKQUOTE. If this is the case, it is a possible indication that the author is using BLOCKQUOTE for formatting rather than to mark a quotation.

Repair

• Allow the author to convert blocks of text to Q or BLOCKQUOTE or from Q to 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 ("" or '').
• Requirement:
  • Not allowed: nested BLOCKQUOTEs.

Repair

• Allow the author 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.

Repair

• Display the above author 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.

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 contains a potential abbreviation or acronym.

    Potential acronym:

    A collection of 2 or more capitalized characters.

    Potential abbreviation:

    A collection of 2 or more characters where the first one is capitalized, the rest are lower case, and the last character is a period.

  • Do no worry about words followed by a potential abbreviation or acronym in parentheses.

Repair

• Ask the author if the acronym or abbreviation was defined elsewhere on the page and if so do nothing, otherwise ask the author to enter a definition for the abbreviation of acronym and attach it to the first instance.

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.

Repair

• Prompt the author 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.

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.

Repair

• Allow the author to modify the table to include row headers and/or column headers.
• Allow the author to convert the top row and/or the left column to headers.
• The author should create at least one complete row or one complete column of 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

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.

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.

Repair

• Linearize the table and ask the author to verify that the result is understandable.
• Allow the author to reposition cells or reorder the table.

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.

Repair

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

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.
  • Not allowed - NULL "summary" value ("")
  • Not allowed - "summary" value of spaces (" ")
  • Suspicious - placeholder "summary" value

Repair

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

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

Evaluation

• Element: TABLE
• Requirement: @@

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

Repair

• Allow the author to enter abbreviations for table header elements.

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 an HTML/XHTML document is readable when style sheets are not applied.

Evaluation

• Elements:
  • LINK rel="stylesheet"
  • STYLE
  • At least one "style" attribute used on any element.
• Requirements: The author must verify if an HTML/XHTML page is readable without style sheets.  Generate and/or display a version of the page without styles to help the author decide.

Repair

• Display an author 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.

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?

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.

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.

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?

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. A 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. One way to check is to compare the number of links and their destinations in the NOFRAMES with the number of links and their destinations in all of the FRAMES combined.
    • Not allowed: Telling the author 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.

Repair

• Allow the author to construct a valid NOFRAMESsection.

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

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
• Requirement: The BLINK element is not valid HTML/XHTML. The author must use another method to highlight text.

Repair

• Allow the author to remove BLINK elements from the document.
• Allow the author to replace BLINK elements with any of the following elements:
  1. STRONG
  2. EM
  3. SPAN- allow the author to enter attributes for the element, such as the CSS "text-decoration: blink;".
  4. H1
  5. H2
  6. H3
  7. H4
  8. H5
  9. H6

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

Technique 7.3.1 [priority 2] Check for MARQUEE elements

Evaluation

• Element: MARQUEE.
• Requirement: The MARQUEE element is not valid HTML/XHTML. The author must use another method to highlight text.

Repair

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

Technique 7.3.2 [priority 2] 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

Repair

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

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

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

Repair

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

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

Repair

• Allow the author to remove the auto-redirect from the document and add a link to the new document.
• Suggest that the author use HTTP headers -- via web server configuration and/or server-side scripting.

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.

Repair

• Display an author 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"

Repair

• Allow the author 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

Repair

• Display an author 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()

Repair

Allow the author to add 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.
    • Must be an integer greater than or equal to zero.
  • Only useful is several links on the page. @@Do we need to set a limit?

Repair

• Display the controls and allow the author 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
  • @@Does every page require an "accesskey" or only some of them? How does the author decide which ones?
  • If accesskeys have been used, has the author identified which keys are defined and how to use them?

Repair

• Display the objects that can contain shortcut keys and allow the author to assign shortcut keys to them.
• If accesskeys are used, encourage the author to provide a description that identifies which keys are defined and how to use 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 2] 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".

Repair

• Allow the author to
  • remove the "target" attribute or
  • use an existing window as the target

Technique 10.1.2 [priority 2] 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 document.open()

Repair

• Allow the author 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.

Repair

• Allow the author 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

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.

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.
  • INPUTelements of type "radio" must have at least one that is "checked".
  • 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.

Repair

• INPUT element missing value: Allowthe author to enter placeholder text.
• TEXTAREA missing text: Allow the author to enter text.
• OPTION not selected: Display all options and allow the author 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 elements 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 including markup.

Repair

• Allow the author to insert " | " characters between sequential links. Allow the author 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.

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.

Repair

• Allow the author to replace FONT with CSS.
• Allow the author to embed IMG and APPLET within OBJECT or to replace them with an OBJECT element.
• Note. Before making these changes, the author should be made aware of the current situation of browser support of CSS and the OBJECT element.

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

Repair

• Prompt the author 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 author.

Repair

• Allow the author 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 .
  • Not allowed - NULL value ("")
  • Not allowed - spaces (" ")
  • Suspicious - placeholder title text

Repair

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

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

Technique 12.3.1 [priority 2] Check for long lists of selections

Evaluation

• Element: SELECT
• Requirement: Should have OPTGROUP elements if more than 7 OPTIONS

Repair

Display the list and allow the author to group long lists of selections into a hierarchy using OPTGROUP elements.

Technique 12.3.2 [priority 2] Check for forms with several controls that are not grouped

Evaluation

• Element: FORM
• Requirement: FIELDSET elements should be used to group controls if the FORM contains more than 7 controls (INPUT, TEXTAREA etc.)

Repair

Display the form controls and allow the author to break into groups using the FIELDSET element.

Technique 12.3.3 [priority 2] Check for lists with numerous items

Evaluation

• Element: OL or UL
• Requirement: Lists should contain 7 or less items

Repair

Display the list and help the author group list items into sub lists of fewer than 7 items. This is not always possible or desired. For example, depending on the context the author may wish to list all 50 states in the United States while other times the author may wish to group them geographically.

Technique 12.3.4 [priority 2] Check for lengthy sentences

Evaluation

• Element: P or blocks of text
• Requirement: Sentences should contain less than 3 verbs and less than 100 characters

Repair

Display the sentence and allow the author to edit and shorten.

Technique 12.3.5 [priority 2] Check for lengthy paragraphs

Evaluation

• Element: P
• Requirement: Paragraphs should contain less than 500 characters

Repair

Display the paragraph and allow the author to edit and shorten it.

Technique 12.3.6 [priority 2] Check for long stretches of text

Evaluation

• Element: P or blocks of text
• Requirements: Blocks of text or paragraphs should be less than 1000 characters.

Repair

Display the block of text and allow the author to insert headers to break up a single, long paragraph into several shorter ones.

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.

Repair

• Allow the author to set a unique "id" attribute for each INPUT element in the document then 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

Repair

• Allow the author to edit the link text and surrounding text in order to:
  • make the link text shorter,
  • make the links text meaningful.
• 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.

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 author notification?

Checkpoint 13.4 - Use navigation mechanisms in a consistent manner

@@Machine checkable? Generate author notification?

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

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

The suggested authoring technique is not widely supported by user agents.

Evaluation

Triggers

Several A elements separated by

• spaces, bullets, or other characters such as "] [" or " | "
• BR elements,
• LI elements,
• TD elements (i.e. A is the only element in a series of TDs, or A with inner IMGs are the only elements in a series of TDs)

Requirement

Links should be grouped by MAP elements. Provide information about the group in the "title" attribute.

Repair

Triggers

1. User has identified a list of links that should be grouped.
2. User has identified that they want to include a link to skip over the group of links.

Actions

If the author wants to group links:

• If the links are contained in a P element, envelope the P element in a MAP element.
• If the links are in a list, enclose the list in a MAP element.
• If the links are the only content of a table, include the table in a MAP element.
• If the links are not the only content of a table, then ??? how do you help the author separate the links into something that can be included in a MAP element???

If the author wants to bypass a group of links and wants to include a link on the page:

• Insert an A element with a "name" attribute just after the group of links. Then insert an A element just before the group of links and link to the A element just created before the group of links.

Refer to the suggested techniques from the section in the HTML Techniques for Web Content Accessibility Guidelines 1.0 called "Bypassing and Grouping Links."

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.

Repair

• Help authors to or suggest that authors provide a variety of search mechanisms to satisfy varying user skill levels and preferences. Examples:
  • Include a spell checker in the search function
  • Offer "best guess" alternatives,
  • Offer query-by-example searches or similarity searches.

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

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

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.

Repair

• Allow the author to insert a link in the document that skips over the ASCII art then use "Skip Over ASCII Art" as the link text 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

14.1.1 Check for clear and accurate headings

Evaluation

• Elements: Any Hx element.
• This is a manual check.
• Requirements: Headings should accurately reflect the content they proceed as well as be stated clearly.

14.1.2 Check that the topic of the sentence or paragraph is at the beginning of the sentence or paragraph.

Evaluation

• Elements: Any sentence within a paragraph (p element).
• This is a manual check.
• Requirements: The topic of a sentence or paragraph should be at the beginning of the sentence or paragraph.

14.1.3 Check that each paragraph has one main idea

Evaluation

• Elements: Any sentence within a paragraph (p element).
• This is a manual check.
• Requirements: Each sentence or paragraph should have one main idea.

14.1.4 Check for use of slang and jargon

Evaluation

• Elements: Any text within the document.
• This is a manual check.
• Requirements: Avoid slang and jargon. Check all words in the document against a dictionary of slang and jargon words that are in the document's primary language.

14.1.5 Check for commonly used words

Evaluation

• Elements: Any element that contains text
• This is a manual check.
• Requirements: Favor commonly used words. Check all words in the document against a dictionary of uncommonly used words that are in the document's primary language. If any uncommon words are found then inform the author and allow them to change the words.

14.1.6 Check for active rather than passive verbs.

Evaluation

• Elements: Any element that contains text
• This is a manual check.
• Requirements: Use active rather than passive verbs. For a document with a primary language of English, check for form of the verb to be (is, am, be, being, were, was, been). If the sentence contains any of these words then suggest to the author that they should check the sentence for passive verbs. (Another indicator is 'by'.) @@Does this give too many false positives? Does looking for the past participle make this more accurate?

14.1.7 Check language is appropriate for a site's content

Evaluation

• Elements: Any element that contains text
• This is a manual check.
• Requirements: Use language appropriate for a site's content.
  • For English documents - create a FOG index and ask the author if this is the level for their intended readers.
  • For Japanese documents - check for the occurrence of the core set of Japanese symbols and askuthor if this is appropriate for their intended audience.
  • @@Other languages?

14.1.8 Check for specialized meanings of familiar words

Evaluation

• Elements: Any element that contains text
• This is a manual check.
• Requirements: Avoid specialized meanings of familiar words.

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

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

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 author 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 author evaluation. The author 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 [MIMETYPES])
• the single word "Image", "Photo"
• the word "images"  (e.g. as in "turn on images").

Appendix B - Placeholder OBJECT text equivalent

• {object text goes here}

Appendix C - Placeholder NOSCRIPT text

• {NOSCRIPT text goes here}

Appendix D - Placeholder TABLE "summary" text

• Summary
• Table
• Table Summary

Appendix E - Placeholder table header "abbr" text

• @

Appendix F - Placeholder FRAME "title" text

• @@

Appendix G - Applet Executable Suffix

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

Appendix H - Bullet Identification

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

• @@

Identifying Bullets page

Appendix I - Horizontal Rule Identification

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

• @@

Identifying HRs page

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.

References

• [MILLER] The Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing Information. George A. Miller (1956) Harvard University First published in Psychological Review, 63, 81-97. reproduced with permission, by Stephen Malinowski.
• [MIMETYPES] List of registered content types (MIME types). Download a list of registered content types.
• Bobby - Accessibility evaluator tool
• Lynx Viewer - Displays a text-only view of web pages
• A-Prompt - Accessibility evaluator and repair tool