This document describes techniques that may be used by software programs
in evaluating the conformance of HTML documents to
The WAI Web Content
Accessibility Guidelines. 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 work in progress and will be under constant revision. We are
endeavoring to complete the document in the first quarter of 2000. Once we have
user comments and suggestions we can return to this document for revisions and
updates.
A list of current W3C Recommendations and other technical documents can
be found at http://www.w3.org/TR.
This document has been produced as part of the W3C
Web Accessibility Initiative. The goal of
the Web Content Guidelines Working Group
is discussed in the
Working Group charter.
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 Images
for ALT text
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] Check images
for LONGDESC and descriptive link
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
buttons that use an image for ALT text
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 applets
for ALT text
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] Check Applets
for alternative content
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 objects
for alternative representation
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] Check frames
for an associated LONGDESC file
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.H [priority 1] Check AREA
elements for ALT text
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.I [priority 1] Check if
audio files have an associated text transcript
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.J [priority 1] Check SCRIPT
element for associated NOSCRIPT element
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 3] User
notification for 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:
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
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
- BODY
- BGCOLOR
- TEXT
- ALINK
- LINK
- TABLE
- BORDERCOLOR
- BGCOLOR
- TD
- TH
- HR
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 first line of the document must be a valid
public text identifier if the document being validated is an HTML
document.
- A valid public text identifier is... (Haven't got precise definition.
Anybody know for sure?)
- 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. Notify user if they are not used.
Discussion Status:
Evaluation:
- Check document for the presence of STYLE elements.
If there are no STYLE elements then provide a user notification.
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.
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:
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
Discussion Status:
Evaluation:
(I think the idea behind this checkpoint is that ordered lists should be
used for nested lists and that each item should contain information about the
nesting. Example list items: 1, 1.2, 1.2, 1.3. But how can this be done? The
following example shows that browsers don't display nested list numbers very
well.)
The nested list:
<![CDATA[ <OL>
<LI>item 1<OL>
<LI>1 Item 1.1</LI>
<LI>2 Item 1.2</LI>
<LI>3 Item 1.3</LI>
</OL>
</LI>
<LI>item 2</LI>
</OL>
]]>
Displays as:
- item 1
- 1 Item 1.1
- 2 Item 1.2
- 3 Item 1.3
- item 2
LI elements should not occur outside of UL of OL
elements.
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.A [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.1.B 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.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] User
notification of style sheet use.
Discussion Status:
Evaluation:
- A LINK element with a REL attribute set to
'stylesheet' will generate this notification.
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] User
notification if FRAME source is not an HTML document.
Discussion Status:
Evaluation:
- FRAME SRC attribute must have a value of an HTML
document to generate this notification
- Valid SRC attribute values must have a suffix of ".html" ".shtml" or
."htm".
Example Language:
- Frame source: [frame source file name] is not an HTML document.
Repair Technique:
Test Files and Discussion Files:
Technique 6.2.B [priority 1] User
notification of dynamic content changes
Discussion Status:
Evaluation:
- SCRIPT elements will generate this user
notification
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] User
notification of usability when programatic objects are disabled.
Discussion Status:
Evaluation:
- Any programatic object will generate this user
notification.
- Programatic objects are: scripts, objects, or embeds
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:
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:
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] User
notification of potential screen flicker
Discussion Status:
Evaluation:
- Any of the following elements will generate this user notice:
- APPLET
- OBJECT
- SCRIPT
- EMBED
- IMG elements will generate this user notice if they
are 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:
- Find any SCRIPTS that cause text to scroll. These
scripts can be distinguished by (see
discussion)??
Example Language:
- Scrolling text is difficult to read and is inaccessible for many
viewers.
Repair Technique:
- Allow the user to remove the SCRIPT from the document.
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] Remove
auto-redirect 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 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:
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] User
notification of server-side image map use
Discussion Status:
Evaluation:
- IMG element is a server-side image map if it
contains an ISMAP 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.
Checkpoint 9.3 - For scripts, specify
logical event handlers rather than device-dependent event handlers
Technique 9.3.A [priority 2] User
notification of logical event handlers for scripts
Discussion Status:
Evaluation:
- Any SCRIPT element will generate this user
notification
Example Language:
- For scripts, specify logical event handlers rather than
device-dependent event handlers.
Repair Technique
Test Files and Discussion Files:
Checkpoint 9.4 - Create a logical tab order
through links, form controls, and objects
Checkpoint 9.5 - Provide keyboard shortcuts
to important 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.A [priority 1] Check
anchors for 'new window' attributes
Discussion Status:
Evaluation:
- A element opens a new window if it has a TARGET
attribute with a value of "_blank" or "_new".
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 'new window' attribute from the
anchor.
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
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
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