This document describes techniques that may be used by software programs in
evaluating the conformance of HTML documents to The Web Content Accessibility
Guidelines 1.0. It also describes methods that may be used in software
programs for modifying HTML documents so that they conform to these
guidelines.
This is a W3C Working Draft for review by the Evaluation and Repair Tools
Working Group and other invited parties. It has not been reviewed by the WAI
Interest Group. It is a draft document and may be updated, replaced, or
obsoleted by other documents at any time. It is inappropriate to use W3C
Working Drafts as reference material or to cite them as other than "work in
progress". A list of current W3C Recommendations and other technical documents
can be found at http://www.w3.org/TR.
Please send comments on this document to w3c-wai-er-ig@w3.org.
To do
- Finish going through Michael
Cooper's comments. I made it through Checkpoint 10.3.
- Make Len
Kasday's corrections.
- Install publishing scripts. Primary benefit is to generate the table of
contents so we don't have to manage that by hand.
- Clean up all of the @@'s (editor questions and comments).
- Use numbers rather than letters to distinguish Techniques (e.g., convert
1.1.A into 1.1.1).
- Check for consistent language usage.
- Link to WCAG Techniques where appropriate.
- Use WCAG notes or rationale as example language where possible, unless
we have something clearer.
- Inherit all of the reference info between checkpoints from WCAG (e.g.,
at the end of Checkpoint 10.1, "refer also to Checkpoint 12.4").
- Determine if we want to use "author" or "user." Then check for
consistent usage.
- Determine if we want to use "document" or "page." Then check for
consistent usage.
- Resolve open issues.
The Web Accessibility Initiative (WAI) produced a foundation document, The WAI Web Content Accessibility
Guidelines, that describes what must be done to make an HTML page
accessible to all. This document trys to make clear that the WWW should enable
everyone, especially those with disabilities.
To determine if a web site is accessible to everyone, it is important to
have functional, friendly and free tools for site evaluation and, if possible,
repair of problems that may be uncovered. This document describes techniques
that may be used by such 'evaluation and repair' tools to uncover
accessibility problems and possibly repair them. These techniques may be used
by those who create web authoring tools or by anyone interested in creating
accessible web documents.
It is important that evaluation and repair tools themselves be accessible.
Many people using these tools may be new to this technology and will require
software programs that are easy to use while not condescending in tone. Is
also important that the evaluation tool does not generate excessive warnings
or false positive accessibility errors to avoid the 'cry wolf' syndrome.
It is clear that only a limited set of the WAI Guideline's checkpoints may
be objectively tested by a software tool. There will still be a dependence on
the user's ability to use common sense to determine conformance to the
guidelines. It is imperative that any tool have features that assist in
reminding, without nagging; in helping, without demeaning; in suggesting,
without demanding. We hope that the techniques in this document, implemented
in software programs, will gently guide authors along the path to more
accessible documents.
Structure Of This Document
This document is based on The WAI Web Content Accessibility
Guidelines. It examines each checkpoint in the guidelines and provides one
or more techniques for the implementation of that checkpoint. Each
implementation technique contains the following items:
- Title:
- The WAI guidelines checkpoint
- Definition:
- A technique to check for checkpoint compliance
- Discussion Status:
- Awaiting discussion, under discussion, discussion complete
- Evaluation:
- The HTML element(s) that must be examined
- Example Language:
- Messages displayed to the author if a problem is found
- Repair Techniques:
- Methods for repairing the HTML code
- Test Files:
- Used to test evaluation tools to see if they find the accessibility
problem
- Discussion Files:
- Discussion and comments on the technique
Guideline 1. Provide equivalent alternatives to
auditory and visual content.
Checkpoint 1.1 - Provide a text equivalent for
every non-text element.
Technique 1.1.A [priority 1] Check IMG
elements for valid "alt" attribute
Discussion Status:
Evaluation:
- IMG element must have a valid ALT attribute.
Valid ALT text:
Note: We're awaiting word from GL on null and blank alt text. See
discussion at http://lists.w3.org/Archives/Public/w3c-wai-er-ig/1999Jun/0050.html
especially part about null or blank alt text for links.
- Not allowed - NULL ALT value (ALT="")
- Allowed - ALT value of 1 or more spaces (ALT=" ") but only if image is
not within an ANCHOR 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 ALT
text.
- Suspicious - ALT attribute value is longer than 150 characters. Suggest
that a LONGDESC file be created.
Example Language:
- Missing ALT text: Missing alternate text for image.
- Suspicious ALT text: Suspicious alternate text for image: [current ALT
text] - [could be file size | could be file name | could be placeholder
text | alternate text should be short, perhaps this could be a
LONGDESC].
- Invalid ALT text: Invalid alternate text for image: [alternate text can
not be empty].
Repair Techniques:
Other checks:
- After user has entered ALT text 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 ALT text, suggest that all same images without
ALT text use the new ALT text.
Test Files and Discussion Files:
Technique 1.1.B [priority 1] Verify that
valid IMG element descriptions ("longdesc" attribute or d-link) are provided
where necessary
Discussion Status:
Evaluation:
- IMG element should have a valid LONGDESC attribute and
a descriptive link if the image is complex and is not described in the
document.
Images that do not require a LONGDESC or descriptive link:
Valid LONGDESC URI:
Example Language:
- If the content of this image is complex and is not fully described in
the document in which it appears, you need to provide a descriptive text
link for it.
Repair Technique:
- If IMG element has no LONGDESC attribute and could be a complex image,
ask user if the image is complex. If the image is complex, ask if the
document adequately describes the image. If image is complex and there is
not a description in the document, allow the user to create or associate a
LONGDESC file with the IMG element.
- If IMG element could be a complex image, ask the user if the document
adequately describes the image. If the image is complex and there is not a
description in the document, allow the user to create or associate a
descriptive file and descriptive 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:
Technique 1.1.C [priority 1] Check INPUT
elements of type="image" for valid "alt" attribute
Discussion Status:
Evaluation:
- If an INPUTelement has a TYPE attribute with a value of
"image" then it must also have a valid ALT attribute.
Valid ALT text:
- Not allowed - NULL ALT value (ALT="")
- Not allowed - 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 ALT
text.
Example Language:
- Missing ALT text: Missing alternate text for this button.
- Suspicious ALT text: Suspicious alternate text for button: [current ALT
text] - [could be file size | could be file name | could be placeholder
text].
- Invalid ALT text: Invalid alternate text for button: [alternate text can
not be empty | alternate text can not contain only 'spaces'].
Repair Technique:
- Prompt the user for alternate text.
- If another document on the same site has an INPUT element with the same
TYPE value, suggest that type value.
Test Files and Discussion Files:
Technique 1.1.D [priority 1] Check APPLET
elements for valid "alt" attribute
Discussion Status:
Evaluation:
- APPLET element must have a valid ALT attribute.
Valid ALT attribute text:
- Not allowed - NULL ALT value (ALT="")
- Not allowed - 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 ALT
text.
- Suspicious - ALT attribute ends with applet
executable suffix.
Example Language:
- Missing ALT text: Missing alternate text for applet.
- Suspicious ALT text: Suspicious alternate text for applet: [current ALT
text] - [could be file size | could be image file name | could be
placeholder text | could be applet executable name].
- Invalid ALT text: Invalid alternate text for applet - [alternate text
can not be empty | alternate text can not be all 'spaces'].
Repair Technique:
- Prompt the user for alternate text.
- If the same applet is used on the same site and has ALT text, suggest
that ALT text.
Test Files and Discussion Files:
Technique 1.1.E [priority 1] Verify that
valid APPLET element descriptions are provided where necessary
Discussion Status:
Evaluation:
- Between the APPLET start element and APPLET end element
must be a valid text element or a valid link to a URI.
Valid text element:
- Must contain at least one word of text or a valid URI
- Suspicious - alternative content is placeholder ALT
text.
- Suspicious - alternative content could be file size (ends with
"bytes")
- Suspicious - ALT attribute could be applet file name (ends with applet executable suffix). The alternative content
text should not match the CODE attribute value of the APPLET.
Example Language:
- Missing alternative content: Missing alternative content for
applet.
- Suspicious alternative content: Suspicious alternative content for
applet: [current alternative content] - [could be placeholder text | could
be file size | could be applet file name].
Repair Technique:
- Prompt user for alternative context text for applet.
- If the site has a document that contains the same applet and that applet
has valid alternative content, suggest that alternative content.
Test Files and Discussion Files:
Link to test files for this technique.
Technique 1.1.F [priority 1] Check OBJECT
elements of type="<image MIME types>" for valid text equivalents and
descriptions (where necessary)
Discussion Status:
Evaluation:
- Between the 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 ALT text
Example Language:
- 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]
Repair Technique:
- Prompt user for new alternative representation.
- If the site contains a document that contains the same object and that
object contains a valid alternative representation, suggest that
alternative representation.
Test Files and Discussion Files:
Link to test files for this technique.
Technique 1.1.G [priority 1] Verify that
valid OBJECT elements of type="<audio or video MIME types>" text
equivalents are provided where necessary
Discussion Status:
Evaluation:
- If the target of an A element is a sound file then ask the user if there is an existing
text transcript file.
Example Language:
- Audio files require an associated text transcript file. Is there an
associated text file for this audio file: [audio file name]?
Repair Technique:
- Prompt user for text transcript of audio file.
Test Files and Discussion Files:
Link to test files for this technique.
Technique 1.1.H [priority 1] Check FRAME
elements for valid "longdesc" attribute
Discussion Status:
Evaluation:
- FRAME elements should have a valid LONGDESC attribute
if the frame title does not completely describe the frame content.
- If FRAME does not have a LONGDESC attribute, ask user if frame contents
are complex and requires one.
Valid LONGDESC file name:
- Must not be NULL
- Must be a valid URI
Example Language:
- Missing LONGDESC: Missing 'long description' file for this frame.
- Invalid LONGDESC file name: Invalid 'long description' file name for
this frame: [current LONGDESC file name] - [can not be empty].
Repair Technique:
- Ask user if the frame title adequately describes the frame contents. If
not, allow the user to create a LONGDESC file or associate an existing
LONGDESC file with this frame.
Test Files and Discussion Files:
Technique 1.1.I [priority 1] Check AREA
elements for valid "alt" attribute
Discussion Status:
Evaluation:
- AREA elements must have a valid ALT attribute.
Valid ALT attribute:
Example Language:
- Missing ALT text: Missing ALT text for this image map area.
- Suspicious LONGDESC: Suspicious ALT text for this image map area:
[current ALT text].
Repair Technique:
Prompt user for ALT text for the area element.
Test Files and Discussion Files:
Technique 1.1.J [priority 1] Check SCRIPT
elements for valid equivalents where necessary
Discussion Status:
Evaluation:
- Following a SCRIPT end element, there must be a
NOSCRIPT element.
- The NOSCRIPT start and end elements must contain at least one valid text
element.
Valid text element:
Example Language:
- Language for missing NOSCRIPT: Missing NOSCRIPT element for this SCRIPT
element.
Repair Technique:
- Prompt user for text description of script. Insert a NOSCRIPT section
after the SCRIPT with the script description text.
Test Files and Discussion Files:
Technique 1.1.K [priority 1] Check A elements for valid text content
No information at this time.
Technique 1.1.L [priority 1] Verify that
valid text equivalents are provided for PRE and XMP elements used to create
ASCII art.
Discussion Status:
Evaluation:
All BODY elements will generate a user notification.
Note: We are still working on methods of determining if a document
contains ASCII art. If we can't find a suitable algorithm that finds ASCII art
then all pages will get a notification.
ASCII Art Discussion Page
Example Language:
- If there is any ASCII art in this document then please give it a textual
description.
Repair Technique:
- Prompt user for descriptions of any ASCII art contained in the
document.
Test Files and Discussion Files:
Checkpoint 1.2 - Provide redundant text links
for each active region of a server-side image map.
Technique 1.2.A [priority 1] Prompt user for
text links if ISMAP used.
Discussion Status:
Evaluation:
- If an IMG element has a valid ISMAP attribute, prompt
the user for associated text links.
- If possible, check the text links against the links contained on the
server-side image map.
Valid ISMAP attribute:
Example Language:
- Server-side image maps should have associated text links in the
document.
Repair Technique:
- Prompt user for associated text links.
Test Files and Discussion Files:
Checkpoint 1.3 - Until user agents can
automatically read aloud the text equivalent of a visual track, provide an
auditory description of the important information of the visual track of a
multimedia presentation.
Technique 1.3.A [priority 1] User
Notification for audio description.
Discussion Status:
Evaluation:
- Any multimedia object will generate a user
notification
Example Language:
- Multimedia presentations should have an associated audio
description.
Repair Technique:
Test Files and Discussion Files:
Checkpoint 1.4 - For any time-based multimedia
presentation (e.g., a movie or animation), synchronize equivalent alternatives
(e.g., captions or auditory descriptions of the visual track) with the
presentation.
Technique 1.4.A [priority 1] User
Notification for synchronized alternatives.
Discussion Status:
Evaluation:
- Any multimedia object will generate a user
notification
Example Language:
- For any time-based multimedia presentation (e.g., a movie or animation),
synchronize equivalent alternatives
Repair Technique:
Test Files and Discussion Files:
Technique 1.4.B [priority 1] Check SMIL files for synchronized media
Discussion Status:
Evaluation:
- Check SMIL files for captions and auditory descriptions.
Example Language:
Repair Technique:
Test Files and Discussion Files:
Checkpoint 1.5 - Until user agents render text
equivalents for client-side image map links, provide redundant text links for
each active region of a client-side image map
Technique 1.5.A [priority 3] Prompt user for
text links if USEMAP used.
Discussion Status:
Evaluation:
- If an IMG element has a valid USEMAP attribute, prompt
the user for associated text links.
- Associated text links may be found by searching the document for anchors
with HREF values that correspond to the AREA elements in the given
USEMAP.
Valid USEMAP attribute:
Example Language:
- Client-side image maps should have associated text links.
Repair Technique:
- Ask the user if there are associated text links for this image map.
- If there are not associated text links, allow the user to create
them.
Test Files and Discussion Files:
Guideline 2. Don't rely on color alone.
Checkpoint 2.1 - Ensure that all information
conveyed with color is also available without color, for example from context
or markup.
Technique 2.1.A [priority 1] User
notification for color use
Discussion Status:
Evaluation:
Display a user notification if the document contains any of the following
elements:
- IMG
- APPLET
- OBJECT
- SCRIPT
- INPUT
- as well as the HTML elements and attributes listed in the next technique
(2.2.A).
Example Language:
- 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).
Repair Technique:
- The user notification will be displayed if any of the color-possible
elements are in the document.
Test Files and Discussion Files:
Checkpoint 2.2 - Ensure that foreground and
background color combinations provide sufficient contrast when viewed by
someone having color deficits or when viewed on a black and white screen.
Technique 2.2.A [priority 3] Test the color
attributes of the following elements for visibility:
Discussion Status:
Evaluation:
Test the following elements and attributes for color visibility
Color visibility can be determined according to the following
algorithm:
(This is a suggested algorithm that is still open to
change.)
Two colors provide good color visibility if the brightness difference and
the color difference between the two colors are greater than a set range.
Color brightness is determined by the following formula:
((Red value X 299) + (Green value X 587) + (Blue value X 114)) / 1000
Note: This algorithm is taken from a formula for converting RGB values to YIQ
values. This brightness value gives a perceived brightness for a color.
Color difference is determined by the following formula:
(maximum (Red value 1, Red value 2) - minimum (Red value 1, Red value 2)) +
(maximum (Green value 1, Green value 2) - minimum (Green value 1, Green value
2)) + (maximum (Blue value 1, Blue value 2) - minimum (Blue value 1, Blue
value 2))
The rage for color brightness difference is 125. The range for color
difference is 500.
Example Language:
- Poor visibility between text and background colors.
Repair Technique:
- Allow the user to change the offending colors.
- Store any good color combinations entered by the user and use them as
default prompts in the future.
Test Files and Discussion Files:
Guideline 3. Use markup and style sheets and do
so properly
Checkpoint 3.1 - When an appropriate markup
language exists, use markup rather than images to convey information
Technique 3.1.A [priority 2] User
notification for appropriate markup language
Discussion Status:
Evaluation:
- All BODY elements will generate a user
notification.
Example Language:
- 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.
Repair Technique:
- The user notification will be generated for each document.
Checkpoint 3.2 - Create documents that
validate to published formal grammars
Technique 3.2.A [priority 2] Check document
for public text identifier
Discussion Status:
Evaluation:
- The document must contain a valid HTML or XHTML public text identifier
if it is an HTML or XHTML document. If a text identifier is not the first
line of the document, refuse to evaluate the document.
- A list of public text
identifiers is available from the W3C.
- The document is an HTML document if there is an HTML element near the
start of the document and there is an HTML end element as the last
non-whitespace text in the document.
Example Language:
- Missing language identifier for this document.
Repair Technique:
- Prompt the user for a public text identifier.
Test Files and Discussion Files:
Checkpoint 3.3 - Use style sheets to control
layout and presentation
Technique 3.3.A [priority 2] Check document
for use of style sheets.
Discussion Status:
Evaluation:
- Check the document for presence of STYLE or LINK
rel="stylesheet" elements within the HEAD element or use of "style"
attributes throughout the document.
Example Language:
- Use style sheets to control layout and presentation. For example, use
the CSS 'font' property instead of the HTML FONT element to control font
styles
Repair Technique:
- Notify the user if the document does not use style sheets.
- Once the user has added 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.A [priority 2] Check document
for relative or absolute units.
Discussion Status:
Evaluation:
- 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 elements.
Example Language:
- This element uses absolute units of measure rather than relative units
of measure.
Repair Technique:
- Allow user to change the units of measure.
Test Files and Discussion Files:
Checkpoint 3.5 - Use header elements to convey
document structure and use them according to specification
Technique 3.5.A [priority 2] Check document
for header nesting
Discussion Status:
Evaluation:
- Header elements (H1-H6) should be checked to ensure
they are nested according to the following rules
- The first header element in the document must be H1
- There must be only one H1 element in the document
- Header levels must not increase by more than 1 level. Example: H2
following H1 is good. H3 following H1 is bad.
- Header elements can decrease by any level. Example: H2 following H5
is OK.
Example Language:
- Improper header nesting:
- First header in the document must be an H1.
- There must be only one H1 in a document.
- Header levels must not increase by more than one level per
heading.
Repair Technique:
- Allow user to modify the header numbering within the document.
Test Files and Discussion Files:
Technique 3.5.B [priority 2] Check document
for missing header markup
Discussion Status:
Evaluation:
- Text elements within a paragraph should be checked to
see if they should be headings. Potential headings can be identified by:
- Text elements occur within a paragraph and...
- The paragraph is less than 10 words and...
- The paragraph contains only text items or formatting elements
and...
- All text in the paragraph is formatted as bold and/or italics and/or
underline.
Example Language:
- Text has been identified that could possibly be a header. Is this text
used as a header: [potential header text]?
Repair Technique:
- Allow user to convert the text to a header.
Test Files and Discussion Files:
Technique 3.5.C [priority 2] User
notification of improper header use
Discussion Status:
Evaluation:
- If the document contains any Header elements (H1- H6)
that contain a text string longer than 20 words then a user notification
is presented.
Example Language:
- Header elements (H1 - H6) should be used to define headers and should
not be used for formatting text.
Repair Technique:
- Allow the user to convert any header text to another type. Possible
types are:
- Paragraph
- Blockquote
Checkpoint 3.6 - Mark up lists and list items
properly
Technique 3.6.A [priority 2] Check that list elements are within a list
container and well nested.
Discussion Status:
Evaluation:
- Not allowed: LI element used outside of an OL, UL, DIR, or MENU
element.
- Not allowed: DT or DD element used outside of a DL element
- Suspicious: excessive nesting of lists. The following example indicates
that list markup is creating a formatting effect rather than indicating a
list structure:
<UL> <UL> <UL> <UL>
<LI>
</UL> </UL> </UL> </UL>
- Suspicous: single list items within lists might indicate formatting
rather than structure. For example:
<UL><LI>
</UL>
<UL><LI>
</UL>
Example Language:
- List items should not be used for formatting text.
Repair Technique:
- Allow the user to format the text within the LI element to another
element.
Test Files and Discussion Files:
Checkpoint 3.7 - Mark up quotations. Do not
use quotation markup for formatting effects such as indentation
Technique 3.7.A [priority 2] Check document
for missing quote markup
Discussion Status:
Evaluation:
- Text elements should be tested to find text that should
be marked as Q or BLOCKQUOTE. Potential quotes can be identified by:
- Any text that is enclosed by quote marks (" " or ' ').
Example Language:
- The following text may need to be marked using Q or BLOCKQUOTE:
[potential quote text].
Repair Technique:
- Allow the user to convert blocks to text to Q or BLOCKQUOTE.
Test Files and Discussion Files:
Technique 3.7.B [priority 2] Check Q and
BLOCKQUOTE to ensure they are used properly
Discussion Status:
Evaluation:
- Q and BLOCKQUOTE elements should be
checked to ensure they enclose the correct type of quote.
- 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.
Example Language:
- 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].
Repair Technique:
- Allow the user to convert blocks of text to Q or BLOCKQUOTE.
Test Files and Discussion Files:
Technique 3.7.C [priority 2] User
notification of improper BLOCKQUOTE or Q use
Discussion Status:
Evaluation:
- If any BLOCKQUOTE elements are used in a document a
user notification will be generated.
- If the text enclosed by BLOCKQUOTE has quote marks ("" or '') then do
not present this notification.
Example Language:
BLOCKQUOTE or Q elements should be used to define quotes and should not be
used for formatting text.
Repair Technique:
- Allow the user to format blocks of text to any of the following types:
- Paragraph
Checkpoint 4.1 - Clearly identify changes in
the natural language of a document's text and any text equivalents (e.g.,
captions)
Discussion Status:
Evaluation:
- The BODY element will generate this notification if
there are 2 or more words within the body.
Example Language:
- Any words or phrases in a document that are not in the primary language
of the document should be identified.
Repair Technique:
- Display the above warning 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.A [priority 3] User
notification of abbreviation and acronym expansion.
Discussion Status:
Evaluation:
- The BODY element will generate this user
notification.
Example Language:
- Specify the expansion of each abbreviation or acronym in a document
where it first occurs.
Repair Technique:
Test Files and Discussion Files:
Technique 4.3.A [priority 3] Check the
primary language of the document
Discussion Status:
Evaluation:
- HTML element must contain a valid LANG attribute
Allowed LANG attributes:
Example Language:
- Missing LANG attribute: The primary language of this document has not
been set.
- Invalid LANG attribute: The primary language of this document is
invalid.
Repair Technique:
- Prompt the user for the primary language of the document.
- Ensure that the language entered is one of the ISO
639 language codes.
Test Files and Discussion Files:
Technique 5.1.1 Determine the purpose of the
table
Discussion Status:
The purpose of the table must be determined before performing an
accessibility evaluation. To help the page author in making this assessment,
the following language may be used:
Example Language:
- 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 the table
for row and column headers
Discussion Status:
Evaluation:
- A TABLE element will trigger this evaluation.
- If the table has one complete row of headers and one complete column of
headers then assume the table has adequate headers.
- This technique applies only to tables used for data, not to tables used
for layout purposes.
Example Language:
- 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.
Repair Technique:
- 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:
Technique 5.2.A - [Priority 1] Check tables
for multiple levels of logical row/column headers
Discussion Status:
Evaluation:
- A TABLE element will trigger this evaluation.
- The table must contain at least 4 rows or 4 columns.
- This technique applies only to tables used for data, not tables used for
layout.
- If the table contains TD or TH elements that have SCOPE, AXIS or HEADERS
attributes then assume that the page author has already dealt with this
issue.
- Ask the page author if the table has 2 or more logical levels of row or
column headers.
Example Language:
- 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.
Repair Technique:
- If the table does contain 2 or more logical levels of row or column
headers, allow the page author to markup the table TD or TH elements with
SCOPE, AXIS or HEADERS attributes.
Technique 5.3.A [priority 2] User
notification of using tables for layout
Discussion Status:
Evaluation:
- A TABLE element will trigger this evaluation.
- The table must have more than one column.
- This technique applies only to tables used for layout purposes, not to
data tables.
Example Language:
- Tables used for layout should make sense when linearized.
- When a table is 'linearized' the cells are usually read a row at a time,
starting at the left and moving to the right.
Repair Technique:
Test Files and Discussion Files:
Technique 5.4.A [priority 2] Check layout
tables for structural markup
Discussion Status:
Evaluation:
- A TABLE element will trigger this evaluation.
- This technique applies only to tables used for layout purposes, not data
tables.
- If the table is used for layout purposes, check table for any TH
elements.
Example Language:
- Tables used for layout should not use structural markup (TH
elements).
Repair Technique:
Test Files and Discussion Files:
Technique 5.5.A [priority 3] Check table for
valid SUMMARY
Discussion Status:
Evaluation:
- TABLE elements must have a valid SUMMARY
attribute.
Valid SUMMARY attributes:
- Not allowed - NULL SUMMARY value ("")
- Not allowed - SUMMARY value of spaces (" ")
- Suspicious - SUMMARY value of placeholder SUMMARY
values
Example Language:
- For missing summary - "Table is missing a summary."
- Suggested prompt to user - "In the summary, describe the purpose of the
table (either layout or data). For example - 'This layout table is used to
create 2 columns of text.' or 'This table contains data that shows the
relationship between age and income level.'"
Repair Technique:
- Allow the user to enter a summary of the table.
Test Files and Discussion Files:
Technique 5.6.A [priority 3] Check table for
header abbreviations
Discussion Status:
Evaluation:
- TH elements should have a valid ABBR attribute if the
header name is greater than 15 characters.
Valid ABBR attributes:
- Not allowed - NULL ABBR value ("")
- Not allowed - ABBR value of spaces (" ")
- Suspicious - ABBR value of placeholder ABBR
values
- ABBR values should be shorter than 15 characters.
Example Language:
- Table header is missing an abbreviation.
Repair Technique:
- Allow user to enter abbreviations for table header elements.
Test Files and Discussion Files:
Guideline 6. Ensure that pages featuring new
technologies transform gracefully
Checkpoint 6.1 - Organize documents so they
may be read without style sheets
Technique 6.1.A [priority 1] Verify that the
document is readable when style sheets are not applied.
Discussion Status:
Evaluation:
Triggers:
- LINK element with a REL attribute set to
'stylesheet,'
- STYLE element,
- At least one "style" attribute used on any element.
Example Language:
- Ensure this document can be read without stylesheets.
Repair Technique:
Test Files and Discussion Files:
Checkpoint 6.2 - Ensure that equivalents for
dynamic content are updated when the dynamic content changes
Technique 6.2.A [priority 1] Check the source
of FRAME and IFRAME elements for valid markup files.
Discussion Status:
Evaluation:
- FRAME or IFRAME "src" attribute is not a valid markup
file. In other words it must be an HTML, XHTML, SMIL, MathML, or other
valid markup.
- Valid "src" attribute values must have a suffix of ".htm," ".html,"
".shtm," ".shtml," ".cfm," ".cfml," ".asp," ".cgi," ".pl" (what are
the extensions for SMIL and MathML files?) or have a known public
identifier at the top of file.
Example Language:
- Frame source: [frame source file name] is not a valid markup file.
Repair Technique:
Test Files and Discussion Files:
Technique 6.2.B [priority 1] Verify that
equivalents of dynamic content are updated and available as often as the
dynamic content.
@@Yikes, is that really what we want to say here? This gets into
issues related to Guideline 7. I guess we could tie them together in some
way...?
Discussion Status:
Evaluation:
Triggers
- SCRIPT elements
- APPLET elements
- OBJECT elements of type = (@@what are the type attribute values for
Java, etc.?)
Example Language:
- Ensure that the descriptions of dynamic content are updated with changes
in the dynamic content.
Repair Technique:
Test Files and Discussion Files:
Checkpoint 6.3 - Ensure that pages are usable
when scripts, applets, or other programmatic objects are turned off or not
supported
Technique 6.3.A [priority 1] Verify that the
page is usable when programatic objects are disabled.
Discussion Status:
Evaluation:
Triggered by:
- SCRIPT
- OBJECT elements of type = (@@what are the type attribute values for
Java, etc.?)
- EMBED
- APPLET
Example Language:
- Ensure that pages are usable when scripts, applets, or other
programmatic objects are turned off or not supported
Repair Technique:
Test Files and Discussion Files:
Checkpoint 6.4 - For scripts and applets,
ensure that event handlers are input device-independent
Technique 6.4.A [priority 2] User
notification of device independent event handlers.
Discussion Status:
Evaluation:
- Any programatic object will generate this user
notification.
- Programatic objects are: applets, scripts, objects, or embeds
Example Language:
- For scripts and applets, ensure that event handlers are input
device-independent.
Repair Technique:
Test Files and Discussion Files:
Checkpoint 6.5 - Ensure that dynamic content
is accessible or provide an alternative presentation or page
Technique 6.5.A [priority 2] Check if there
is a NOFRAMES section after a FRAMES section.
Discussion Status:
- awaiting discussion
- @@ I'm not sure if WCAG intended FRAMEs to fit in this cateogry.
Evaluation:
- Immediately following a FRAME end element must be a
NOFRAMES element.
Example Language:
- No NOFRAMES section following a FRAME section.
Repair Technique:
- Allow user to construct a NOFRAMES version of the document.
Test Files and Discussion Files:
Technique 6.6.A [priority 2] Verify that programmatic objects are directly
accessible.
Discussion Status:
- awaiting discussion
- @@Relation to 8.1.A and 9.2??
Evaluation:
Triggered by:
- SCRIPT
- OBJECT elements of type = (@@what are the type attribute values for
Java, etc.?)
- EMBED
- APPLET
Example Language:
- Ensure that scripts, applets, or other programmatic objects are directly
accessible.
Repair Technique:
Test Files and Discussion Files:
Guideline 7. Ensure user control of
time-sensitive content changes
Checkpoint 7.1 - Until user agents allow users
to control flickering, avoid causing the screen to flicker
Technique 7.1.A [priority 1] Verify that the
page does not cause flicker.
Discussion Status:
Evaluation:
Triggered by:
- SCRIPT
- OBJECT elements of type = (@@what are the type attribute values for
Java, etc.?)
- EMBED
- APPLET
- IMG elements of the type 'animated gif'.
Example Language:
- Display flicker is distracting and may be dangerous to some users.
Please ensure this element does not cause the display to flicker.
Repair Technique:
Test Files and Discussion Files:
Checkpoint 7.2 - Until user agents allow users
to control blinking, avoid causing content to blink
Discussion Status:
Evaluation:
- Find any BLINK elements in the document.
Example Language:
- BLINK elements are not defined in any W3C HTML specification and should
not be used.
Repair Technique:
- Allow the user to remove BLINK elements from the document.
- Allow the user to change the elements from BLINK to another element.
Suggest the following elements:
- STRONG
- EM
- SPAN
- H1
- H2
- H3
- H4
- H5
- H6
If the user selects the SPAN element or enters one of their own, allow
them to enter attributes for the element.
Test Files and Discussion Files:
Checkpoint 7.3 - Until user agents allow users
to freeze moving content, avoid movement in pages
Discussion Status:
Evaluation:
- Find any MARQUEE elements in the document.
Example Language:
- MARQUEE elements are not defined in any W3C HTML specification and
should not be used.
Repair Technique:
- Allow the user to remove MARQUEE elements from the document.
- Allow the user to change the elements from MARQUEE to any of the
following elements:
- STRONG
- EM
- SPAN
- H1
- H2
- H3
- H4
- H5
- H6
If the user selects the SPAN element or enters one of their own, allow
them to enter attributes for the element.
Test Files and Discussion Files:
Discussion Status:
Evaluation:
Triggered by:
- SCRIPT - distinguished by (see
discussion)??
- OBJECT elements of type = (@@what are the type attribute values for
Java, etc.?)
- EMBED
- APPLET
Example Language:
- Moving text may be difficult to read and is inaccessible for many
viewers.
Repair Technique:
- Allow the user to remove the SCRIPT from the document or create a
mechanism to stop the movement.
Test Files and Discussion Files:
Checkpoint 7.4 - Until user agents provide the
ability to stop the refresh, do not create periodically auto-refreshing
pages
Technique 7.4.A [priority 2] Remove
auto-refresh attributes from META elements
Discussion Status:
Evaluation:
- If a META element has a HTTP-EQUIV attribute and the
value of that attribute is "refresh" then check if the element has a
'CONTENT' attribute.
- If the META element has a CONTENT attribute then check if the value of
that attribute is a URL.
- If the CONTENT attribute does not have a value of a URL (will contain
the string "URL=") then it is an auto-refresh page and the HTTP-EQUIV and
CONTENT attributes should be removed from the META element.
Example Language:
- This page uses auto-refresh which can make the page difficult to read
for some people.
Repair Technique:
- Allow user to remove the auto-refresh from the document.
Test Files and Discussion Files:
Checkpoint 7.5 - Until user agents provide the
ability to stop auto-redirect, do not use markup to redirect pages
automatically
Technique 7.5.A [priority 2] Check
auto-redirect attributes on META elements
Discussion Status:
Evaluation:
- If a META element has a HTTP-EQUIV attribute and the
value of that attribute is "refresh" then check if the element has a
'CONTENT' attribute with delay greater than 0.
- If the META element has a CONTENT attribute then check if the value of
that attribute is a URL.
- If the CONTENT attribute does have a value of a URL (will contain the
string "URL=") then it is an auto-redirect page and the HTTP-EQUIV and
CONTENT attributes should be removed from the META element.
Example Language:
- This page uses auto-redirect which can make the page difficult to read
for some people.
Repair Technique:
- Allow the user to remove the auto-redirect from the document.
Test Files and Discussion Files:
Guideline 8. Ensure direct accessibility of
embedded user interfaces
Checkpoint 8.1 - Make programmatic elements
such as scripts and applets directly accessible or compatible with assistive
technologies
Technique 8.1.A [priority 1 if functionality
is important and not presented elsewhere, otherwise Priority 2] User
notification if programmatic elements used
Discussion Status:
- awaiting discussion
- @@ relation to 6.6.A and 9.2
Evaluation:
- Search the document for any of the following elements: OBJECT,
APPLET, EMBED or SCRIPT.
Example Language:
- This element may not be accessible to all users. Please ensure there is
an accessible interface to this object.
Repair Technique:
- If any programmatic elements are found in the document, provide a user
notification:
Guideline 9. Design for device-independence
Checkpoint 9.1 - Provide client-side image
maps instead of server-side image maps except where the regions cannot be
defined with an available geometric shape
Technique 9.1.A [priority 1] Check for use of
server-side image maps
Discussion Status:
Evaluation:
- IMG element is a server-side image map if it contains
an "ismap" attribute and no "usemap" attribute.
Example Language:
- Use client-side image maps instead of server-side maps.
Repair Technique
- Allow the user to convert the server-side image map to a client-side
image map.
Test Files and Discussion Files:
Checkpoint 9.2 - Ensure that any element that
has its own interface can be operated in a device-independent manner
(Image map text links - checked in techniques 1.2.A and 1.5.A.
@@Programmatic objects check in 6.5 and 8.1.A Need clarification.
Checkpoint 9.3 - For scripts, specify logical
event handlers rather than device-dependent event handlers
Technique 9.3.A [priority 2] Check scripts
for logical event handlers
Discussion Status:
Evaluation:
The following event handlers will trigger this technique:
- onMouseDown
- onMouseUp
- onClick
- onMouseOver
- onMouseOut
- onMouseMove
Example Language:
- For scripts, specify logical event handlers rather than device-dependent
event handlers.
Repair Technique
- "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 ??
Test Files and Discussion Files:
Checkpoint 9.4 - Create a logical tab order
through links, form controls, and objects
Technique 9.4.1 [priority 3] Check for "tabindex" attribute
Discussion Status:
Evaluation:
Check the following elements for a "tabindex" attribute:
- A
- AREA
- BUTTON
- INPUT
- OBJECT
- SELECT
- TEXTAREA
Example Language:
- Create a logical tabbing order through this page. Some people like to
skip over site navigation bars that appear at the top of each page in a
site. To allow someone to tab over it, set the tab order of the page such
that the navigation bar one of the last objects.
Repair Technique:
- Show the author a list of all of the active elements and their current
tab order. Allow them to change the order either by changing the number
of the tabindex or dragging and dropping an object to where it ought to
appear in the list.
Test Files and Discussion Files:
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
Discussion Status:
Evaluation:
Check the following elements for an "accesskey" attribute:
- A
- AREA
- BUTTON
- INPUT
- LABEL
- LEGEND
- TEXTAREA
Example Language:
- Create short keys to important active elements on this page.
Repair Technique:
Test Files and Discussion Files:
Checkpoint 10.1 - Until user agents allow
users to turn off spawned windows, do not cause pop-ups or other windows to
appear and do not change the current window without informing the user
Technique 10.1.1 [priority 1] Check A and
AREA elements for valid "target" attributes
Discussion Status:
- awaiting discussion
- @@ how do we handle the "until user agents" clause?
Evaluation:
- A and AREA elements should not have "target" attributes
of "_blank" or "_new".
- A and AREA elements may have other "target" attribute values if there is
another existing window with the target name.
Example Language:
- This Anchor element [anchor text] will open a new window that can be
disorienting for some users.
Repair Technique:
- Allow the user to remove the "target" attribute or use an existing
window as the target.
Test Files and Discussion Files:
Technique 10.1.2 [priority 1] Verify that scripts do not spawn new
windows.
Discussion Status:
Evaluation:
- Check for a JavaScript call to window.open()
- @@other embedded scripting languages?
- If not found, ask the author to confirm if scripts spawn new windows or
not.
Example Language:
- This script will open a new window that can be disorienting for some
users.
Repair Technique:
- Allow the user to remove the scripting call or to replace it with
??@@
Test Files and Discussion Files:
Checkpoint 10.2 - Until user agents support
explicit associations between labels and form controls, for all form controls
with implicitly associated labels, ensure that the label is properly
positioned
Technique 10.2.1 [priority 2] Verify that label controls are properly
positioned.
Refer also to checkpoint 12.4
Discussion Status:
Evaluation:
Triggered by the following elements:
- INPUT
- LABEL
- LEGEND??
- SELECT
- TEXTAREA
Example Language:
- A label for a text area, a text input control or group of controls
(e.g., a group of checkboxes) must immediately precede its control (or
group of controls) on the same line (if there is only one control or
group) or be in the line preceding the control (or group of
controls).
Repair Technique:
- Allow the user to reposition labels associated with form controls.
Test Files and Discussion Files:
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] Generate a linear text alternative for all
TABLEs.
Discussion Status:
Evaluation:
- All TABLE elements will trigger this technique.
Example Language:
- 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.
Repair Technique:
- If it has been determined that the table is used for layout (see
Technique 5.1.1) then create a linear version of the table by: [@@insert
heuristics from table linearizer - basically replace TABLE markup with
text structural markup]. The author will then need to check that it is
readable.
- If it has been determined that the table is used for data (see Technique
5.1.1) then create a linear version of the table by: [@@table linearizer
heuristics? basically, for each cell repeat the column and row headers
associated with it]. The author will then need to check that it is
readable.
Test Files and Discussion Files:
- Table linearizer
- Trace "HelpDB"
- other examples
Checkpoint 10.4 - Until user agents handle
empty controls correctly, include default, place-holding characters in edit
boxes and text areas
Checkpoint 10.5 - Until user agents
(including assistive technologies) render adjacent links distinctly, include
non-link, printable characters (surrounded by spaces) between adjacent
links
Guideline 11. Use W3C technologies and
guidelines
Checkpoint 11.1 - Use W3C technologies when
they are available and appropriate for a task and use the latest versions when
supported
Checkpoint 11.2 - Avoid deprecated features
of W3C technologies
(This looks like something that the editor should check for.)
Checkpoint 11.3 - Provide information so that
users may receive documents according to their preferences
(We're doing all we can by prompting user to specify language of document
in technique 4.3.A.)
Checkpoint 11.4 - If, after best efforts, you
cannot create an accessible page, provide a link to an alternative page that
uses W3C technologies, is accessible, has equivalent information (or
functionality), and is updated as often as the inaccessible (original)
page
(Should we notify user of this? For every page?)
Guideline 12. Provide context and orientation
information
Checkpoint 12.1 - Title each frame to
facilitate frame identification and navigation
Technique 12.1.A [priority 1] Check frames
for title
Discussion Status:
Evaluation:
- FRAME element must have a valid TITLE attribute
Valid title text for frame:
Example Language:
- Missing title for this frame: [frame file name].
Repair Technique:
- Prompt user for frame title.
Test Files and Discussion Files:
Checkpoint 12.2 - Describe the purpose of
frames and how frames relate to each other if it is not obvious by frame
titles alone
(Suggest that if the frame title does not describe the frame that a
LONGDESC is needed?)
Checkpoint 12.3 - Divide large blocks of
information into more manageable groups where natural and appropriate
(Any suggestions??)
Checkpoint 12.4 - Associate labels explicitly
with their controls
(Check for the presence of a validated LABEL element?)
Guideline 13. Provide clear navigation
mechanisms
Checkpoint 13.1 - Clearly identify the target
of each link
(Search for text string 'click here'? Perhaps display all the anchor text
and ask user if they are all clear?)
Checkpoint 13.2 - Provide metadata to add
semantic information to pages and sites
(Suggestions??)
Checkpoint 13.3 - Provide information about
the general layout of a site
(Can't be machine checked. User notification?)
Checkpoint 13.4 - Use navigation mechanisms
in a consistent manner
(Can't be machine checked. User notification?)
Checkpoint 13.5 - Provide navigation bars to
highlight and give access to the navigation mechanism
(Can't be machine checked. User notification?)
Checkpoint 13.6 - Group related links,
identify the group (for user agents), and, until user agents do so, provide a
way to bypass the group
(Can't be machine checked. User notification?)
Checkpoint 13.7 - If search functions are
provided, enable different types of searches for different skill levels and
preferences
(Can't be machine checked. User notification?)
Checkpoint 13.8 - Place distinguishing
information at the beginning of headings, paragraphs, lists, etc
(Can't be machine checked. User notification?)
Checkpoint 13.9 - Provide information about
document collections
(Can't be machine checked. User notification?)
Checkpoint 13.10 - Provide a means to skip
over multi-line ASCII art
(Can't be machine checked - this sort of ASCII art is larger than just
emoticons. User notification?)
Guideline 14. Ensure that documents are clear
and simple
Checkpoint 14.1 - Use the clearest and
simplest language appropriate for a site's content
(Check document using fog index? User notification?)
Checkpoint 14.2 - Supplement text with
graphic or auditory presentations where they will facilitate comprehension of
the page
(Can't be machine checked. User notification?)
Checkpoint 14.3 - Create a style of
presentation that is consistent across pages
(Can't be machine checked. User notification?)
After evaluating a document, an evaluation and/or repair tool should
provide the user with a document rating. The rating is based on conformance to
the WAI Page
Authoring Guidelines and will be:
- 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.
Appendix A - Placeholder ALT text
- {short description of image}
Appendix B - Image File Suffixes
Appendix C - Placeholder OBJECT ALT text
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
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