NOTES ABOUT THIS DRAFT:
- Intro, references, etc. have been removed for clarity. They will of course be replaced
for publishing.
- In the introduction we emphasize the new techniques structures: i.e. the break-out
documents for each language, the required/suggested breakdown, the concept of Crossover's
(practices that go towards satisfying multiple checkpoints), references, and screenshot
samples.
- Perhaps we can produce a top-10 access upgrade suggestions (including reference to
checkpoints that will be satisfied).
- I see a tighter relationship between the guidelines and the techniques - so no need to
repeat ourselves (guideline intros , etc.)
2 Techniques by ATAG Guideline
- ATAG 1.1 Ensure that the author can produce accessible content in the markup language(s) supported by the tool. [Priority 1] (Checkpoint 1.1)
Required:
- Allow direct source editing as a minimal measure for meeting this checkpoint.
- It is highly recommended that all structural features available in supported languages
be available within the tool. See Reference section for links to accessibility features of
select tools.
- New markup languages are constantly being developed, and can offer improvements to the
structure and utility of Web content. In implementing a new or extended markup language,
ensure that the tool does not remove access to information that had been inherent in the
base markup language.
- The same applies to formats that simplify an existing format. For example, producing a
modified HTML DTD that did not include the
"alt"
attribute for the IMG
element, or effectively working to such a DTD by not allowing the attribute to be
included, compromises the accessibility of any included IMG
elements.
Suggested:
- Include equivalent alternatives for all supported image formats that allow text content
(ex. PNG, SVG, WebCGM, JPEG, and GIF) [Crossover: ATAG Checkpoint 3.1, P1].
- When converting documents, allow authors to edit conversion templates to include
structure information derived from presentation conventions. For example, a document may
use a particular font convention to identify the major heading in a language that lacks
markup of structured information. When converting the document to a language which does
allow structure, allow the author to specify which presentation conventions correspond to
which structural markup.
Reference:
- Web Content Accessibility Guidelines 1.0 [WCAG10] and Techniques for Web Content
Accessibility Guidelines 1.0 [WCAG10-TECHS]
- The Web Accessibility Initiative has published a number of documents on the
accessibility features of different W3C specifications.
- In addition, many language specifications provide information about accessibility
features available.
- The Web Accessibility Initiative's Protocols and Formats group have a draft set of notes
about creating accessible markup languages [XMLGL].
- ATAG 1.2 Ensure that the tool preserves all accessibility information during authoring, transformations, and conversions. [Priority 1]
(Checkpoint
1.2)
Required:
- Ensure that the tool preserves elements that are defined in the relevant
specification(s) even if it is unable to render them in a publishing view or preview mode.
See Reference section for links to accessibility features of select tools.
- When transforming a table to a list or list of lists, ensure that table headings are
transformed into headings and that summary or caption information is retained as rendered
content. This transformation may not be reversible.
- When importing images with associated descriptions to an HTML document make the
descriptions available through appropriate markup. For instance, in HTML use
"longdesc"
or "alt"
.
- When converting from a word-processor format to HTML, ensure that headings and list
items are transformed into appropriate headings of the appropriate level, and list items
in the appropriate type of list (rather than as plain text with font formatting).
- Avoid transforming text into images. Use style sheets for presentation control, or an
XML application such as Scalable Vector Graphics [SVG] that keeps the text as text. If this is not
possible, ensure that the text that is converted is available as equivalent text for the
image.
Suggested:
- In general allow the author decide whether or not to preserve unrecognized markup (since
it might be accessibility related). See ATAG 4.3.
- Ensure that the tool recognizes elements that are defined in the relevant
specification(s) even if it is unable to render them in a publishing view or preview mode.
This is relevant for WYSIWYG page authoring tools, tools that handle image formats which
allow the incorporation of equivalent text or data, and tools for multimedia and
data-processing.
- Even when a document's graphical layout has been rearranged, ensure that the document
makes sense when rendered serially. For example, prompt the author to confirm the
linearized reading order after the graphical layout has changed. Desktop publishing
software often has such a feature.
- When converting linked elements such as footnotes or endnotes either provide them as
inline content or maintain two-way linking. In HTML, this should be hypertext links rather
than plain-text references.
Reference:
- See References for ATAG 1.1.
- ATAG 1.3 Ensure that when the tool automatically
generates markup it conforms to the W3C's Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority] (Checkpoint 1.3)
Relative Priority to WCAG 1.0:
- * REMEMBER: The equivalent alternatives themselves
may not be automatically generated unless the function of the non-text element is known
with certainty (see ATAG 3.4). If the function of the non-text element is
not known with certainty, then author input will be required, at some point, to approve or
create a new equivalent alternative.
- (WCAG 1.1, P1, Techniques) Provide a text equivalent* for every
generated non-text element. This includes images, graphical representations of text
(including symbols), image map regions, animations (e.g., animated GIFs), applets and
programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers,
graphical buttons, sounds (played with or without user interaction), stand-alone audio
files, audio tracks of video, and video.
- (WCAG 1.2, P1, Techniques) Provide redundant text links* for each
active region of a generated server-side image map.
- (WCAG 1.3, P1, Techniques) 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 generated multimedia presentation.
- (WCAG 1.4, P1, Techniques) For tools that generate time-based
multimedia presentations (e.g., a movie or animation), ensure synchronized equivalent
alternatives* are provided. (e.g., captions or auditory descriptions of the visual track)
- (WCAG 1.5, P3, Techniques) Until user agents render text equivalents
for client-side image map links, provide redundant text links* for each active region of a
generated client-side image map.
- (WCAG 2.1, P1, Techniques) Ensure that all generated information
conveyed with color is also available without color.
- (WCAG 2.2, Images: P2, Text: P3, Techniques) Ensure that foreground and
background color combinations of generated images and text provide sufficient contrast
when viewed by someone having color deficits or when viewed on a black and white screen.
- (WCAG 3.1, P2, Techniques) When an appropriate markup language exists,
generate markup rather than images to convey information.
- (WCAG 3.2, P2, Techniques) Generate documents that validate to
published formal grammars.
- (WCAG 3.3, P2, Techniques) Generate style sheets to control layout and
presentation.
- (WCAG 3.4, P2, Techniques) Use relative rather than absolute units in
generated markup language attribute values and style sheet property values.
- (WCAG 3.5, P2, Techniques) Use header elements to convey generated
document structure and use them according to specification.
- (WCAG 3.6, P2, Techniques) Generate markup for lists and list items
properly.
- (WCAG 3.7, P2, Techniques) Generate markup for quotations in templates.
Do not use quotation markup for formatting effects such as indentation.
- (WCAG 4.1, P1, Techniques) Clearly identify changes in the natural
language of generated text.
- (WCAG 4.2, P3, Techniques) Specify the expansion of each abbreviation
or acronym in a generated document where it first occurs.
- (WCAG 4.3, P3, Techniques) Identify the primary natural language of a
generated document.
- (WCAG 5.1, P1, Techniques) For generated data tables, identify row and
column headers.
- (WCAG 5.2, P1, Techniques) For generated data tables that have two or
more logical levels of row or column headers, use markup to associate data cells and
header cells.
- (WCAG 5.3, P2, Techniques) Do not generate tables for layout unless the
table makes sense when linearized. Otherwise, if the generated table does not make sense,
provide an alternative equivalent* (which may be a linearized version).
- (WCAG 5.4, P2, Techniques) If a generated table is used for layout, do
not use any structural markup for the purpose of visual formatting.
- (WCAG 5.5, P3, Techniques) Provide summaries* for generated tables.
- (WCAG 5.6, P3, Techniques) Provide abbreviations* for header labels of
generated tables.
- (WCAG 6.1, P1, Techniques) Organize generated documents so they may be
read without style sheets.
- (WCAG 6.2, P1, Techniques) Ensure that equivalents* for generated
dynamic content are updated when the dynamic content changes.
- (WCAG 6.3, P1, Techniques) Ensure that generated pages are usable when
scripts, applets, or other programmatic objects are turned off or not supported. If this
is not possible, provide equivalent information* on an alternative accessible page.
- (WCAG 6.4, P2, Techniques) For generated scripts and applets, ensure
that event handlers are input device-independent.
- (WCAG 6.5, P2, Techniques) Ensure that generated dynamic content is
accessible or provide an alternative presentation* or page.
- (WCAG 7.1, P1, Techniques) Until user agents allow users to control
flickering, avoid generating markup that causes the screen to flicker.
- (WCAG 7.2, P2, Techniques) Until user agents allow users to control
blinking, avoid generating markup that causes content to blink.
- (WCAG 7.3, P2, Techniques) Until user agents allow users to freeze
moving content, avoid generating markup that causes movement.
- (WCAG 7.4, P2, Techniques) Until user agents provide the ability to
stop the refresh, do not generate periodically auto-refreshing pages.
- (WCAG 7.5, P2, Techniques) Until user agents provide the ability to
stop auto-redirect, do not use generated markup to redirect pages automatically. Instead,
configure the server to perform redirects.
- (WCAG 8.1, Important and not elsewhere: P1, Otherwise: P2, Techniques)
Make generated programmatic elements such as scripts and applets directly accessible or
compatible with assistive technologies.
- (WCAG 9.1, P1, Techniques) Generate client-side image maps instead of
server-side image maps except where the regions cannot be defined with an available
geometric shape.
- (WCAG 9.2, P2, Techniques) Ensure that any generated element that has
its own interface can be operated in a device-independent manner.
- (WCAG 9.3, P2, Techniques) For generated scripts, specify logical event
handlers rather than device-dependent event handlers.
- (WCAG 9.4, P3, Techniques) Create a logical tab order through generated
links, form controls, and objects.
- (WCAG 9.5, P3, Techniques) Provide keyboard shortcuts to important
generated links (including those in client-side image maps), form controls, and groups of
form controls.
- (WCAG 10.1, P2, Techniques) Until user agents allow users to turn off
spawned windows, do not generate markup that cause pop-ups or other windows to appear or
change the current window without informing the user.
- (WCAG 10.2, P2, Techniques) Until user agents support explicit
associations between labels and form controls, for all generated form controls with
implicitly associated labels*, ensure that the label is properly positioned.
- (WCAG 10.3, P3, Techniques) Until user agents render side-by-side text
correctly, provide a linear text alternative (on the current page or some other) for all
generated tables that lay out text in parallel, word-wrapped columns.
- (WCAG 10.4, P3, Techniques) Until user agents handle empty controls
correctly, include default, place-holding characters in generated edit boxes and text
areas.
- (WCAG 10.5, P3, Techniques) Until user agents render adjacent links
distinctly, include non-link, printable characters (surrounded by spaces) between
generated adjacent links.
- (WCAG 11.1, P2, Techniques) Generate markup using W3C technologies when
they are available and appropriate for a task and use the latest versions when supported.
- (WCAG 11.2, P2, Techniques) Avoid generating deprecated features of W3C
technologies.
- (WCAG 11.3, P3, Techniques) Generate information so that users may
receive documents according to their preferences (e.g., language, content type, etc.)
- (WCAG 11.4, P1, Techniques) If, after best efforts, a generated
alternative page is necessary, ensure that it includes equivalent information (or
functionality), and is updated as often as the inaccessible (original) page.
- (WCAG 12.1, P1, Techniques) Title* each generated frame to facilitate
frame identification and navigation.
- (WCAG 12.2, P2, Techniques) Describe* the purpose of generated frames
and how frames relate to each other if it is not obvious by frame titles alone.
- (WCAG 12.3, P2, Techniques) Divide large blocks of generated
information into more manageable groups where natural and appropriate.
- (WCAG 12.4, P2, Techniques) Associate generated labels* explicitly with
their controls.
- (WCAG 13.1, P2, Techniques) Clearly identify the target* of each
generated link.
- (WCAG 13.2, P2, Techniques) Provide metadata* to add semantic
information to generated pages and sites.
- (WCAG 13.3, P2, Techniques) Provide information* about the general
layout of a generated site (e.g., a site map or table of contents).
- Produce accessible representations for site maps generated by the authoring tool.
- (WCAG 13.4, P2, Techniques) Generate navigation mechanisms in a
consistent manner.
- For a tool that does site-wide management, ensure that all pages on the site make use of
consistent and clear navigation systems.
- (WCAG 13.5, P3, Techniques) Generate navigation bars to highlight and
give access to the navigation mechanism.
- (WCAG 13.6, P3, Techniques) When generating links, group related links,
identify the group (for user agents), and, until user agents do so, provide a way to
bypass the group.
- (WCAG 13.7, P3, Techniques) If search functions are generated, enable
different types of searches for different skill levels and preferences.
- (WCAG 13.8, P3, Techniques) Generate distinguishing information* at the
beginning of headings, paragraphs, lists, etc.
- (WCAG 13.9, P3, Techniques) Generate information* about document
collections (i.e., documents comprising multiple pages.).
- (WCAG 13.10, P3, Techniques) Generate a means to skip over multi-line
ASCII art.
- (WCAG 14.1, P1, Techniques) Generate the clearest and simplest language
appropriate for a site's content.
- (WCAG 14.2, P3, Techniques) Supplement generated text with graphic or
auditory presentations where they will facilitate comprehension of the page.
- (WCAG 14.3, P3, Techniques) Generate a style of presentation that is
consistent across pages.
Reference:
- Web Content Accessibility Guidelines 1.0 [WCAG10] and Techniques for Web Content
Accessibility Guidelines 1.0 [WCAG10-TECHS]
- ATAG 1.4 Ensure that templates provided by the
tool conform to the Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority]
(Checkpoint
1.4)
Relative Priority to WCAG 1.0:
- * REMEMBER: The equivalent alternatives themselves
must not be automatically generated unless the function of the non-text element was known
with certainty (ATAG 3.4). If the function of the non-text element was not known with
certainty, then the equivalent alternative must be created "by hand" by the
template developer.
- (WCAG 1.1, P1, Techniques) Provide a text equivalent* for every
non-text element in a template. This includes images, graphical representations of text
(including symbols), image map regions, animations (e.g., animated GIFs), applets and
programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers,
graphical buttons, sounds (played with or without user interaction), stand-alone audio
files, audio tracks of video, and video.
- (WCAG 1.2, P1, Techniques) Provide redundant text links* for each
active region of a server-side image map in a template.
- (WCAG 1.3, P1, Techniques) 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 template.
- (WCAG 1.4, P1, Techniques) For templates of time-based multimedia
presentations (e.g., a movie or animation), ensure synchronized equivalent alternatives*
are provided. (e.g., captions or auditory descriptions of the visual track)
- (WCAG 1.5, P3, Techniques) 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 in a template.
- (WCAG 2.1, P1, Techniques) Ensure that all information conveyed with
color in a template is also available without color.
- (WCAG 2.2, Images: P2, Text: P3, Techniques) Ensure that template
foreground and background color combinations of images and text provide sufficient
contrast when viewed by someone having color deficits or when viewed on a black and white
screen.
- (WCAG 3.1, P2, Techniques) When an appropriate markup language exists,
use markup rather than images in templates to convey information.
- (WCAG 3.2, P2, Techniques) Create templates that validate to published
formal grammars.
- (WCAG 3.3, P2, Techniques) Use style sheets to control layout and
presentation in templates.
- (WCAG 3.4, P2, Techniques) Use relative rather than absolute units in
markup language attribute values and style sheet property values for templates.
- (WCAG 3.5, P2, Techniques) Use header elements to convey template
structure and use them according to specification.
- (WCAG 3.6, P2, Techniques) Mark up lists and list items properly in
templates.
- (WCAG 3.7, P2, Techniques) Mark up quotations in templates. Do not use
quotation markup for formatting effects such as indentation.
- (WCAG 4.1, P1, Techniques) Clearly identify changes in the natural
language of text in a template.
- (WCAG 4.2, P3, Techniques) Specify the expansion of each abbreviation
or acronym in a template where it first occurs.
- (WCAG 4.3, P3, Techniques) Identify the primary natural language of a
template.
- (WCAG 5.1, P1, Techniques) For data tables in a template, identify row
and column headers.
- (WCAG 5.2, P1, Techniques) For data tables in a template that have two
or more logical levels of row or column headers, use markup to associate data cells and
header cells.
- (WCAG 5.3, P2, Techniques) Do not include tables for layout in a
template unless the table makes sense when linearized.
- (WCAG 5.4, P2, Techniques) If a table is used for layout in a template,
do not use any structural markup for the purpose of visual formatting.
- (WCAG 5.5, P3, Techniques) Provide summaries* for tables in a template.
- (WCAG 5.6, P3, Techniques) Provide abbreviations* for header labels of
tables in templates.
- (WCAG 6.1, P1, Techniques) Organize templates so they may be read
without style sheets.
- (WCAG 6.2, P1, Techniques) Ensure that equivalents* for dynamic content
in a template are updated when the dynamic content changes.
- (WCAG 6.3, P1, Techniques) Ensure that page templates are usable when
scripts, applets, or other programmatic objects are turned off or not supported. If this
is not possible, provide equivalent information* on an alternative accessible page.
- (WCAG 6.4, P2, Techniques) For template scripts and applets, ensure
that event handlers are input device-independent.
- (WCAG 6.5, P2, Techniques) Ensure that dynamic content in a template is
accessible or provide an alternative presentation* or page.
- (WCAG 7.1, P1, Techniques) Until user agents allow users to control
flickering, avoid templates that causes the screen to flicker.
- (WCAG 7.2, P2, Techniques) Until user agents allow users to control
blinking, avoid templates that causes content to blink.
- (WCAG 7.3, P2, Techniques) Until user agents allow users to freeze
moving content, avoid templates generating markup that causes movement.
- (WCAG 7.4, P2, Techniques) Until user agents provide the ability to
stop the refresh, do not produce auto-refreshing templates.
- (WCAG 7.5, P2, Techniques) Until user agents provide the ability to
stop auto-redirect, do not redirect pages automatically from a template. Instead,
configure the server to perform redirects.
- (WCAG 8.1, Important and not elsewhere: P1, Otherwise: P2, Techniques)
Make programmatic element templates, such as scripts and applets, and templates directly
accessible or compatible with assistive technologies.
- (WCAG 9.1, P1, Techniques) Use client-side image maps in templates
instead of server-side image maps except where the regions cannot be defined with an
available geometric shape.
- (WCAG 9.2, P2, Techniques) Ensure that any element in a template that
has its own interface can be operated in a device-independent manner.
- (WCAG 9.3, P2, Techniques) For scripts in a template, specify logical
event handlers rather than device-dependent event handlers.
- (WCAG 9.4, P3, Techniques) Create a logical tab order through links,
form controls, and objects in a template.
- (WCAG 9.5, P3, Techniques) Provide keyboard shortcuts to important
links (including those in client-side image maps), form controls, and groups of form
controls in a template.
- (WCAG 10.1, P2, Techniques) Until user agents allow users to turn off
spawned windows, do not produce templates that cause pop-ups or other windows to appear or
change the current window without informing the user.
- (WCAG 10.2, P2, Techniques) Until user agents support explicit
associations between labels and form controls, for all form controls with implicitly
associated labels* in a template, ensure that the label is properly positioned .
- (WCAG 10.3, P3, Techniques) Until user agents render side-by-side text
correctly, provide a linear text alternative (on the current page or some other) for all
tables in a template that lay out text in parallel, word-wrapped columns.
- (WCAG 10.4, P3, Techniques) Until user agents handle empty controls
correctly, include default, place-holding characters in edit boxes and text areas in a
template.
- (WCAG 10.5, P3, Techniques) Until user agents render adjacent links
distinctly, include non-link, printable characters (surrounded by spaces) between adjacent
links in a template.
- (WCAG 11.1, P2, Techniques) Produce templates using W3C technologies
when they are available and appropriate for a task and use the latest versions when
supported.
- (WCAG 11.2, P2, Techniques) Avoid using deprecated features of W3C
technologies in templates.
- (WCAG 11.3, P3, Techniques) Provide information in a template so that
users may receive documents according to their preferences (e.g., language, content type,
etc.)
- (WCAG 12.1, P1, Techniques) Title* each frame in a template to
facilitate frame identification and navigation.
- (WCAG 12.2, P2, Techniques) Describe* the purpose of frames in a
template and how frames relate to each other if it is not obvious by frame titles alone.
- (WCAG 12.3, P2, Techniques) Divide large blocks of information in a
template into more manageable groups where natural and appropriate.
- (WCAG 12.4, P2, Techniques) Associate labels* explicitly with their
controls in a template.
- (WCAG 13.1, P2, Techniques) Clearly identify the target* of each link
in a template.
- (WCAG 13.2, P2, Techniques) Provide metadata* to add semantic
information to templates.
- (WCAG 13.3, P2, Techniques) Provide information* about the general
layout of a template page or site (e.g., a site map or table of contents).
- (WCAG 13.4, P2, Techniques) Use navigation mechanisms in a consistent
manner in templates.
- (WCAG 13.5, P3, Techniques) Provide navigation bars to highlight and
give access to the navigation mechanism in templates.
- (WCAG 13.6, P3, Techniques) Group related links, identify the group
(for user agents), and, until user agents do so, provide a way to bypass the group in
templates.
- (WCAG 13.7, P3, Techniques) If search functions are provided in a
template, enable different types of searches for different skill levels and preferences.
- (WCAG 13.8, P3, Techniques) Place distinguishing information* at the
beginning of headings, paragraphs, lists, etc. in templates.
- (WCAG 13.9, P3, Techniques) Provide information* about template
collections (i.e., templates comprising multiple pages.).
- (WCAG 13.10, P3, Techniques) Provide a means to skip over multi-line
ASCII art in templates.
- (WCAG 14.1, P1, Techniques) Use the clearest and simplest language
appropriate for template content.
- (WCAG 14.2, P3, Techniques) Supplement text with graphic or auditory
presentations where they will facilitate comprehension of the template.
- (WCAG 14.3, P3, Techniques) Create a style of presentation that is
consistent across templates for a site.
- Not Applicable: WCAG 11.4
Suggested:
- For tools that allow author's to create their own templates, advise the author that
templates should be held to a high accessibility standard, since they will be repeatedly
re-used. Help the author reach this goal by making an accessibility check mandatory before
saving as a template.
Reference:
- Web Content Accessibility Guidelines 1.0 [WCAG10] and Techniques for Web Content
Accessibility Guidelines 1.0 [WCAG10-TECHS]
Samples:
- 2.1 Use the latest versions of W3C Recommendations when
they are available and appropriate for a task. [Priority 2]
(Checkpoint 2.1)
Required:
- When creating documents or markup languages, make full use of W3C
Recommendations (see WCAG 11.1, P2). For example, when creating
mathematical content for the Web use MathML [MATHML] rather than another markup language.
Use applicable HTML 4 [HTML4]
structures.
- Do not publish Web content in markup languages that do not allow for equivalent
alternative information to be included for media-specific presentations (such as images or
video, sound, etc). Where this cannot be avoided, make the information directly available
from the content generated. For example, convert the text equivalent of an image to a
caption for the image, or provide a "base" page that includes links to
alternative versions of content.
- When inserting objects such as spreadsheets or word processor documents, offer the
option of providing a Web-formatted version. For example, a spreadsheet or a word
processor document in a proprietary format could also be published as an HTML document.
Tools that dynamically generate Web content may use HTTP content negotiation to facilitate
this.
Suggested:
- A modular design that allows for the inclusion of languages will permit tools to have a
language "available" later in their development cycle, or may allow tools to use
languages which are not specified at the time of development. Specifications that become
W3C Recommendations after an authoring tool's development cycles permit input are not
considered "available" in time.
Reference:
- As of the date of this draft (18 September 2000) the following languages are W3C
Recommendations (latest versions given):
- 2.2 Ensure that the tool automatically
generates valid markup. [Priority 1] (Checkpoint 2.2)
Required:
- Ensure that the markup produced by the tool, in any of its supported languages, is
valid.
- Publish proprietary language specifications or DTDs on the Web, to allow documents to be
validated.
- Use namespaces and schemas to make documents that can be automatically transformed to a
known markup language.
Reference:
- Validation tools are available. For example, [HTML-XML-VALIDATOR].
- The Web Accessibility Initiative's Protocols and Formats group have a draft set of notes
about creating accessible markup languages [XMLGL].
- 2.3 If markup produced by the tool does not
conform to W3C specifications, inform the
author. [Priority 3] (Checkpoint 2.3)
Required:
- To minimally meet this checkpoint, a tool must somehow inform the author that the markup
produced does not conform to W3C specifications. This might be done with a statement on
the saving dialog or with an alert that is displayed following a save.
Suggested:
- Invalid markup can be highlighted through the use of style sheets.
- If the tool produces inaccessible markup, whether it is valid or not, see ATAG 4.1 for checking techniques.
Samples:
- If Amaya imports or generates markup that does not conform to W3C specifications it is
highlighted in the structure view. This occurs when Amaya tries to repair invalid markup
and cannot successfully do so.
[needs screenshot]
- ATAG 3.1 Prompt
the author to provide equivalent alternative
information (e.g., captions, auditory descriptions, and collated text transcripts for video). [Relative Priority] (Checkpoint 3.1)
Relative Priority to WCAG 1.0:
- (WCAG 1.1, P1, Techniques) Provide a text equivalent for every non-text
element (e.g., via "alt", "longdesc", or in element content). This
includes: images, graphical representations of text (including symbols), image map
regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art,
frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played
with or without user interaction), stand-alone audio files, audio tracks of video, and
video.
- Require: When a multimedia object is inserted, prompt the author for relevant
alternatives: functional replacement and long description for images, text captions (as
text or as a URI), video of signed translations for audio, and audio descriptions for
video (as well as alternatives for its audio components).
- Require: In Japanese, Chinese, and other appropriate languages, prompt the author
for text that can be used as a ruby for unusual ideographs or ideographic groups. Refer to
[RUBY].
- Suggest: When video is inserted, prompt the author for a still image as part of
the alternative information.
- Suggest: Provide an author with the option of specifying alternative information,
or electing to insert null alternative information for images, audio, video.
- Suggest: Prompt the author to identify the type of image (decorative, a
navigation icon, etc.).
- Suggest: Satisfying checkpoint
3.5 would provide much of the required functionality for images.
- Suggest: Identify the natural language of text equivalents. (WCAG 4.1, P1)
- (WCAG 1.2, P1, Techniques) Provide redundant text links for each active
region of a server-side image map.
- Suggest: Ask the author to identify regions in an image map, or to describe how
the coordinates will be used so that a form-based input method can be generated.
- (WCAG 1.3, P1, Techniques) 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.
- (WCAG 1.4, P1, Techniques) For any time-based multimedia presentation
(e.g., a movie or animation), synchronized equivalent alternatives (e.g., captions or
auditory descriptions of the visual track) with the presentation.
- (WCAG 1.5, P3, Techniques) 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.
- Use the same User interface for server and client side image map creations, including
prompting for alternatives for each region. Use alternatives provided to generate
redundant text-based links for server-side maps.
- (WCAG 6.2, P1, Techniques) Ensure that equivalents for dynamic content
are updated when the dynamic content changes.
- (WCAG 6.3, P1, Techniques) Ensure that pages are usable when scripts,
applets, or other programmatic objects are turned off or not supported. If this is not
possible, provide equivalent information on an alternative accessible page.
- (WCAG 6.5, P2, Techniques) Ensure that dynamic content is accessible or
provide an alternative presentation or page.
- (WCAG 10.3, P3, Techniques) Until user agents 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.
- (WCAG 10.4, P3, Techniques) Until user agents handle empty controls
correctly, include default, place-holding characters in edit boxes and text areas.
- (WCAG 11.4, P1, Techniques) If, after best efforts, an alternative page
is necessary, ensure that it includes equivalent information (or functionality), and is
updated as often as the inaccessible (original) page.
- (WCAG 12.1, P1, Techniques) Title each frame to facilitate frame
identification and navigation.
- (WCAG 12.2, P2, Techniques) Describe the purpose of frames and how
frames relate to each other if it is not obvious by frame titles alone.
- (WCAG 13.1, P2, Techniques) Clearly identify the target of each link.
- Prompt the author to provide text which can be used as a title for a link.
- (WCAG 13.2, P2, Techniques) Provide metadata* to add semantic
information to templates.
- Ask authors for information about a page or site. If its function is known (see also
WCAG checkpoint 13.9) add this information as metadata.
- (WCAG 13.3, P2, Techniques) Provide information* about the general
layout of a page or site (e.g., a site map or table of contents).
- Prompt the author to provide a link or content describing the structure of the site, and
its accessibility features.
- (WCAG 13.9, P3, Techniques) Provide information* about document
collections (i.e.,documents comprising multiple pages.).
- Pattern-matching - ask authors to specify the role of pages linked from a navigation
bar.
- Where common names are used (search, home, map) as links, ask the author to confirm
these functions for use in linking.
- Not Applicable: WCAG 2.1, 2.2, 3.1 - 3.7, 4.1 - 4.3, 5.1 - 5.6, 6.1, 6.4,
7.1 - 7.5, 8.1, 9.1 - 9.5, 10.1, 10.2, 10.5, 11.1 - 11.3, 12.3, 12.4, 13.4 - 13.10, 14.1 -
14.3.
Suggested:
- Provide a preview mode that uses alternative content. Although this can give authors a
clear understanding of some problems very easily, it should be made clear that there are
many ways in which a page may be presented (aurally, text-only, text with pictures
separately, on a small screen, on a large screen, etc.). A view that renders the document
as it might appear without technologies such as style sheets and images enabled, or the
ability to turn those features off and on in the editing view, will also give an author
some idea of whether a document's logical order has been correctly preserved, whether
alternative text is appropriate, etc.
Reference:
- For more information on prompting, see Appendix A.
- ATAG 3.2 Help the author create structured
content and separate information from its presentation. [Relative Priority]
(Checkpoint
3.2)
Relative Priority to WCAG 1.0:
- (WCAG 1.1 - 1.5) Covered by ATAG 3.1.
- (WCAG 2.1, P1, Techniques) Ensure that all information conveyed with
color is also available without color.
- Prompt the author to identify a class, or markup element for uses of color.
- (WCAG 2.2, Images: P2, Text: P3, Techniques) Ensure that template
foreground and background color combinations of images and text provide sufficient
contrast when viewed by someone having color deficits or when viewed on a black and white
screen.
- Suggest: Provide a monochrome preview for the author to test themselves.
- (WCAG 3.1, P2, Techniques) When an appropriate markup language exists,
use markup rather than images to convey information.
- (WCAG 3.2, P2, Techniques) Create documents that validate to published
formal grammars.
- (WCAG 3.3, P2, Techniques) Use style sheets to control layout and
presentation.
- Require: Prompt the author to identify the structural role of content that has
been emphasized through styling.
- Suggest: Provide a view which allows the author to edit the layout and styling
effects independently of the text content.
- Suggest: Recognize formatting patterns and convert them to style rules.
- (WCAG 3.4, P2, Techniques) Use relative rather than absolute units in
markup language attribute values and style sheet property values.
- (WCAG 3.5, P2, Techniques) Use header elements to convey document
structure and use them according to specification.
- Suggest: Prompt the author to identify headings and subheadings.
- Suggest: Provide an "outline" or "structure" view which
allows the author to easily grasp the heading structure, and edit it.
- (WCAG 3.6, P2, Techniques) Mark up lists and list items properly.
- Suggest: Recognize formatting conventions such as a number of consecutive
paragraphs beginning with a bullet character (this may be a "bullet" or another
punctuation character like asterisk or dash "-") being used to identify a list.
- Suggest: Include lists (marked as lists) in a collapsible structure view
- (WCAG 3.7, P2, Techniques) Mark up quotations. Do not use quotation
markup for formatting effects such as indentation.
- Suggest: Where material appears within quote marks ask the author if this is a
quotation.
- (WCAG 4.1, P1, Techniques) Clearly identify changes in the natural
language of a document's text and any text equivalents (e.g., captions).
- Use a dictionary lookup system to recognize changes of language, or use of abbreviations
and acronym.
- (WCAG 4.2, P3, Techniques) Specify the expansion of each abbreviation
or acronym where it first occurs.
- Recognize collections of uppercase letters as likely abbreviations (in languages that
have case) and prompt the author for an expansion, to be provided in markup (e.g., in
HTML, with
abbr
or acronym
).
- (WCAG 4.3, P3, Techniques) Identify the primary natural language of a
document
- Prompt the author (and allow them to specify a default suggestion) for the language of a
document.
- (WCAG 5.1, P1, Techniques) For data tables, identify row and column
headers.
- Prompt the author to provide header information for tabular data.
- (WCAG 5.2, P1, Techniques) For data tables that have two or more
logical levels of row or column headers, use markup to associate data cells and header
cells.
- Ask the author to group columns, rows, or blocks of cells that are related.
- (WCAG 5.3, P2, Techniques) Do not use tables for layout unless the
table makes sense when linearized. Otherwise, if the table does not make sense, provide an
alternative equivalent (which may be a linearized version).
- Suggest: Prompt the author to identify tables which are used as layout devices.
- Suggest: For layout tables, provide a linearized version, and offer it as a link
from the table or as a replacement.
- Reference: An example tool which linearizes tables is tablin.
- (WCAG 5.4, P2, Techniques) If a table is used for layout, do not use
any structural markup for the purpose of visual formatting.
- (WCAG 5.5, P3, Techniques) Provide summaries for tables.
- In a table creation wizard, include a summary or caption dialog.
- (WCAG 6.1, P1, Techniques) Organize documents so they may be read
without style sheets.
- Provide a "draft" view which does not apply styling.
- (WCAG 6.3, P1, Techniques) Ensure that pages are usable when scripts,
applets, or other programmatic objects are turned off or not supported. If this is not
possible, provide equivalent information on an alternative accessible page.
- Required: Prompt for alternative content for applets and programmatic objects.
- Suggested: Prompt for server-side alternatives for scripts and applets.
- (WCAG 6.4, P2, Techniques) For scripts and applets, ensure that event
handlers are input device-independent.
- Required: During applet development, prompt the author to include
device-independent means of activation.
- (WCAG 6.5, P2, Techniques) Ensure that dynamic content is accessible or
provide an alternative presentation or page.
- (WCAG 7.1, P1, Techniques) Until user agents allow users to control
flickering, avoid causing the screen to flicker.
- (WCAG 7.2, P2, Techniques) Until user agents allow users to control
blinking, avoid causing content to blink.
- (WCAG 7.3, P2, Techniques) Until user agents allow users to freeze
moving content, avoid movement in pages.
- (WCAG 7.4, P2, Techniques) Until user agents provide the ability to
stop the refresh, do not create periodically auto-refreshing pages.
- (WCAG 7.5, P2, Techniques) Until user agents provide the ability to
stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure
the server to perform redirects.
- (WCAG 9.1, P1, Techniques) Use client-side image maps instead of
server-side image maps except where the regions cannot be defined with an available
geometric shape.
- Where regions are not easily defined, ask the author to provide information that can be
used to generate a form-based input method and explains how the coordinates input will be
used. For example, for a geographic map the input might be used to lookup latitude and
longitude of a point and then give information about that point.
- (WCAG 9.2, P2, Techniques) Ensure that any element that has its own
interface can be operated in a device-independent manner.
- (WCAG 9.3, P2, Techniques) For scripts, specify logical event handlers
rather than device-dependent event handlers.
- (WCAG 9.4, P3, Techniques) Create a logical tab order through links,
form controls, and objects.
- Where there are only a few links that change in each page of a collection, ask the
author if they should receive focus first. If so, then give them a tabindex, leaving the
rest to after the tabindexed links have been focused.
- (WCAG 9.5, P3, Techniques) Provide keyboard shortcuts to important
links (including those in client-side image maps), form controls, and groups of form
controls.
- Ask authors to specify an accesskey for links that appear common to a number of pages
- (WCAG 10.1, P2, Techniques) Until user agents allow users to turn off
spawned windows, do not cause pop-ups or other windows to appear or change the current
window without informing the user.
- (WCAG 10.4, P3, Techniques) Until user agents handle empty controls
correctly, include default, place-holding characters in edit boxes and text areas in a
template.
- Prompt the author for default place-holder text.
- (WCAG 11.2, P2, Techniques) Avoid deprecated features of W3C
technologies.
- (WCAG 11.3, P3, Techniques) Provide information so that users may
receive documents according to their preferences (e.g., language, content type, etc.)
- (WCAG 12.1, P1, Techniques) Title each frame to facilitate frame
identification and navigation.
- Prompt the author for a short, human-readable title for each frame.
- (WCAG 12.2, P2, Techniques) Describe the purpose of frames and how
frames relate to each other if it is not obvious by frame titles alone.
- Prompt the author for a
longdesc
for each frame in a frameset.
- Prompt the author to add a
noframes
section to the frameset. Encourage the
author to include sufficient links to navigate the site, and relevant information. For
example, where a frameset defines a navigation frame and a welcome page, include the
content of each of these frames in the noframes
.
- (WCAG 12.3, P2, Techniques) Divide large blocks of information into
more manageable groups where natural and appropriate.
- Where there are more than 10 choices in a list (
select
, checkbox
or radio
boxes) ask the author to identify subgroups
- (WCAG 12.4, P2, Techniques) Associate labels explicitly with their
controls.
- Ask authors to mark explicitly the labels for form inputs (
input
and textarea
elements)
- (WCAG 13.6, P3, Techniques) Group related links, identify the group
(for user agents), and, until user agents do so, provide a way to bypass the group.
- Ask authors if lists of links are a group and should be a map.
- (WCAG 14.1, P1, Techniques) Use the clearest and simplest language
appropriate for a site's content.
- Provide readability ratings for text.
- Provide a thesaurus function
- Provide a grammar-checking function
- Not applicable: WCAG 5.6, 6.2, 8.1, 10.2 - 10.3, 10.5, 11.1, 11.4, 13-1 -
13.5, 13.7 - 13.10, 14.2, 14.3.
Reference:
- The WAI Evaluation and Repair group [WAI-ER] is developing a document that
discusses detailed techniques for testing the accessibility of content according to the
Web Content Accessibility Guidelines, and methods of repairing it. A draft of that
document is available [AUTO-TOOL].
- Provide an outline view that lets the author clearly see the structure of the document
independently of the specified presentation
Samples:
- Tables: In Amaya, when the author creates a table, a dialog is
generated which asks for number of rows, columns, border width. The author selects the
appropriate information and a table is created. The cursor is placed at the position of
the table caption. The status line, which appears at the bottom of the image, shows that
the position is in the caption element of the table.
- ATAG 3.3 Ensure that prepackaged content conforms to
the Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority]
(Checkpoint 3.3)
Required:
- Use formats that allow for accessible annotation to be included in the files, such as
SMIL, PNG, and SVG.
- Provide long descriptions, and associated text files with appropriate text equivalent in clip-art collections.
- Provide video description files with prepackaged video.
Suggested:
- Provide text caption files for prepackaged audio, or video with auditory track(s).
- Including pre-written descriptions for all multimedia files (e.g., clip-art) packaged
with the tool will save authors time and effort, cause a significant number of
professionally written descriptions to circulate on the Web, provide authors with
convenient models to emulate when they write their own descriptions, and show authors the
importance of description writing.
- Refer also to checkpoint 3.5.
Sample
- 3.4 Do not automatically generate equivalent alternatives. Do not reuse previously
authored alternatives without author confirmation, except when the function is known with
certainty. [Priority 1] (Checkpoint 3.4)
Required:
- If the author has not specified alternative text for an
IMG
, or specified
that none is required, default to having no "alt"
attribute, so
that an accessibility problem will be noted. Refer also to checkpoint 4.1.
Suggested:
- Human-authored equivalent alternatives may be available for an object (for example,
through checkpoint 3.5 and/or checkpoint 3.3). It is appropriate for
the tool to offer these to the author as defaults.
- Items used throughout a Website, such as graphical navigation bars, should have standard
alternative information. However the author should be prompted to edit or approve this the
first time it is used in a site, and when the destination of the links is changed by the
author.
- Where an object has already been used in a document, the tool should offer the
alternative content that was supplied for the first or most recent use as a default.
- 3.5 Provide functionality for managing, editing,
and reusing alternative equivalents for
multimedia objects. [Priority 3] (Checkpoint 3.5)
-
- Note: This checkpoint is priority 3, so it does not
have a critical effect on an authoring tool's likelihood of producing accessible mark-up.
However, implementing this checkpoint has the potential to simultaneously satisfy several
higher priority checkpoints (ATAG 3.1, ATAG 3.2, and ATAG 3.4) and dramatically improve
the usability of an authoring tool.
Suggested:
- Maintain a database registry that associates object identity information with
alternative information. Whenever an object is used and an equivalent alternative is
collected (as per checkpoint 3.1)
add the object (or identifying information) and the alternative information to the
database. In the case of a text equivalent, the alternate
information may be stored in the document source. For more substantial information (such
as video captions or audio descriptions), the information may be stored externally and
linked from the document source. Allow different alternative information to be associated
with a single object.
- If such a database is maintained, the pre-written descriptions can be presented to the
author as default text in the appropriate field, whenever one of the associated files is
inserted into the author's document. This satisfies ATAG 3.4 because the equivalent
alternatives are not automatically generated and they are only reused with author
confirmation.
- If no previous association is found, the field should be left empty (i.e., no purely
rule-generated alternative information should be used). Note: The term
"default" implies that the alternative information is offered for the author's
approval. The term does not imply that the default alternative information is
automatically placed without the author's approval. Such automatic placement may only
occur when in situations where the function of the object is known with certainty, per checkpoint 3.4. Such a situation might
arise in the case of a "navigation bar builder" that places a navigation bar at
the bottom of every page on a site. In this case, it would be appropriate to use the same
"alt"-text automatically for every instance of a particular image (with the same
target) on every page.
- The pre-written alternative information provided for all packaged multimedia files (per checkpoint 3.3) should be included in
the database. This would allow the alternative information to be automatically retrieved
whenever the author selected one of the packaged objects for insertion. An important
benefit of the system would be the ease of adding a keyword search capability that would
allow efficient location of multimedia based on its alternative information.
References:
Checkpoints:
- 4.1 Check
for and inform the author of accessibility problems. [Relative Priority] (Checkpoint 4.1)
- Note: Accessibility problems should be detected
automatically where possible. Where this is not possible, the tool may need to prompt the author to make decisions or to manually check for
certain types of problems. In the section below, the evaluation (ATAG 4.1) and repair
(ATAG 4.2) techniques for each WCAG checkpoint have been grouped together.
Relative
Priority to WCAG 1.0:
- (WCAG 1.1, P1, Techniques) Provide a text equivalent for every
non-text element. This includes images, graphical representations of text (including
symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic
objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical
buttons, sounds (played with or without user interaction), stand-alone audio files, audio
tracks of video, and video.
- (AERT 1.1.1) HTML 4.0: Check
IMG
element for valid alt
attribute
- Suggested Check:
- Valid
alt
attribute must exist
- Valid:
alt
value of 1 or more spaces (alt=" "
)
but only if image is not within an A
element.
- Invalid: NULL
alt
value (alt=""
)
- Suspicious:
alt
attribute value could be file size (ends with
"bytes")
- Suspicious:
alt
attribute value ends with image
file suffix.
- Suspicious:
alt
attribute value is placeholder
text.
- Suspicious:
alt
attribute value is longer than 150 characters.
Suggest that a description file be created.
- Suggested Messages:
- "Missing text equivalent: Missing text equivalent for image."
- "Invalid
alt
attribute: Invalid text equivalent for image: [text
equivalents can not be empty]."
- "Suspicious
alt
attribute: Suspicious text equivalent for image:
[current alt
text] - [could be file size | could be file name | could be
placeholder text | text equivalent should be short, perhaps this could be a longdesc
]."
- Suggested Repairs:
- Prompt the user for a text equivalent for the image.
- If the document contains another instance of the image that is missing an
alt
attribute, suggest the new alt
attribute value.
- If the image is assumed to be a bullet, suggested text should
be "bullet".
- If the image is assumed to be a horizontal rule, suggested text
should be "horizontal rule".
- Suggestions by Daniel Dardailler
- Suggestions by Michael
Vorburger
- If another document on the same site uses the same image and does not have a text
equivalent, suggest that all same images without an
alt
attribute use the new
alt
attribute value.
- Test Files and Discussion Files:
- (AERT 1.1.2) HTML 4.0: Verify that valid
IMG
element descriptions (longdesc
attribute or d-link) are provided where necessary.
- Suggested Check:
- Valid
longdesc
attribute or a d-link required if describing the image will
add information not given in the text of the page. The amount of information in the image
and the context in which it is used will determine how detailed the description should be.
Note: d-link now deprecated.
- Cases where a description is not required:
- Suggested Message:
- "If describing the image will add information not given in the text of the page,
you need to provide a description of the image. The amount of information in the image and
the context in which it is used will determine how detailed the description should
be."
- Suggested Repair:
- Ask user if the image presents information that is not included in the page or in the
text equivalent for the image. Allow the user to create or associate a description with
the
longdesc
attribute on an IMG
element or via a D-link.
- If another document on the same site uses the same image and is missing a
longdesc
,
suggest that longdesc
file.
- Test Files and Discussion Files:
- (AERT 1.1.3) HTML 4.0: Check
INPUT
elements of type="image"
for valid alt
attribute.
- Suggested Check:
- Valid
alt
attribute must exist
- Invalid: NULL
alt
value (alt=""
)
- Invalid:
alt
value of 1 or more spaces (alt=" "
)
- Suspicious:
alt
attribute value could be file size (ends with
"bytes")
- Suspicious:
alt
attribute value ends with image
file suffix.
- Suspicious:
alt
attribute value is placeholder
text.
- Suggested Message:
- Missing text equivalent: Missing text equivalent for this button.
- Suspicious text equivalent: Suspicious text equivalent for button: [current
alt
attribute] - [could be file size | could be file name | could be placeholder text].
- Invalid text equivalent: Invalid text equivalent for button: [
alt
attribute can not be empty | text equivalent can not contain only 'spaces'].
- Suggested Repair:
- Prompt the user for text equivalent.
- If another document on the same site has an INPUT element with the same TYPE value,
suggest that type value.
- (AERT 1.1.4) HTML 4.0: Check
APPLET
elements for valid HTML
equivalent.
- Suggested Checking:
- Accessible HTML within
APPLET
element OR
- Valid
alt
attribute
- Valid: no
alt
attribute if text is provided within the content of
the APPLET
element.
- Invalid: NULL
alt
attribute value (alt=""
)
- Invalid:
alt
attribute value of 1 or more spaces (alt="
"
)
- Suspicious:
alt
attribute value could be file size (ends with
"bytes")
- Suspicious:
alt
attribute value ends with image
file suffix.
- Suspicious:
alt
attribute value is placeholder
alt-text text.
- Suspicious:
alt
attribute ends with applet
executable suffix.
- Suggested Message:
- "Missing text equivalent: Applet must have valid a valid
alt
attribute
or accessible HTML content."
- "Suspicious text equivalent: Suspicious text equivalent for applet: [current
alt
attribute value] - [could be file size | could be image file name | could be placeholder
text | could be applet executable name]."
- "Invalid text equivalent: Invalid
alt
attribute for applet - [text
equivalent can not be empty | text equivalent can not be all spaces]."
- Suggested Repair:
- Prompt the user for text equivalent.
- If the same applet is used on the same site and has an
alt
attribute,
suggest that alt
attribute value.
- Test Files and Discussion Files:
- (AERT 1.1.5) HTML 4.0: Check
OBJECT
elements of type="image_MIME_types"
for valid text equivalents and descriptions (where necessary) (OPEN ISSUES: This
only covers text equivalents. Where is non-text covered if not here?)
- Suggested Check:
- Between
OBJECT
start element and OBJECT
end element must be a
valid alternative representation element.
- Valid: A text element with at least one word of text.
- Valid: An
IMG
element with valid alt-text
- Valid: A valid URI
- Suspicious: "
alt
" attribute value is placeholder OBJECT
text equivalent
- Suggested Message:
- "Missing alternative representation: Missing alternative representation for this
object."
- "Suspicious alternative representation: Suspicious alternative representation for
this object: [current alternative representation] - [could be placeholder text]"
- Suggested Repair:
- Prompt user for new alternative representation.
- If the site contains a document that contains the same object and that object contains a
valid alternative representation, suggest that alternative representation.
- Test Files and Discussion Files:
- (AERT 1.1.6) HTML 4.0: Verify that text equivalents are provided for linked
audio files where necessary
- Suggested Check (
href=soundFile
):
- Audio file must be described within the document or document must contain a link
to a text equivalent file.
- Suggested Message:
- "Audio files require a text equivalent. Is there an associated text equivalent for
this audio file: [audio file name]?"
- Suggested Repair:
- Prompt user for text transcript of audio file.
- Test Files and Discussion Files:
- (AERT 1.1.7) HTML 4.0: Verify that text equivalents are provided for embedded
audio files where necessary
- Suggested Check (
OBJECT type=Audio_or_Video_MIME_type
):
- Audio file must be described within the document or document must contain a link to a
text equivalent file.
- Suggested Message:
- "Audio and video files require a text equivalent. Is there an associated text
equivalent for this audio/video file: [audio/video file name]?"
- Suggested Repair:
- Prompt user for text transcript of audio/video file and embed it between start and end
tag.
- (AERT 1.1.8) HTML 4.0: Check
FRAME
elements for valid "longdesc
"
attribute
- Suggested Check:
- Valid
longdesc
attribute (refer to checkpoint 12.1 for information about
titling frames).
- Invalid: Must not be NULL
- Valid: Must be a valid URI
- Valid: The file pointed to by the URI must be accessible HTML
- If a
FRAMESET
has three or more frames and at least one of the frames does
not have a "longdesc
" attribute, ask the user if the relationships
between frames are not apparent in the titles for each frame.
- Suggested Message:
- "Missing
longdesc
: Missing description for this frame."
- "Invalid
longdesc
URI: Invalid 'long description' file name for this
frameset: [current longdesc
URI] - [can not be empty]."
- Suggested Repair:
- If the relationships between frames are not obvious then ask that they provide a
description of the relationships. Allow the user to create a
longdesc
file or
associate an existing longdesc
file. It is suggested that each FRAME
in the reference the same longdesc
as the description of the relationships
should be available from each FRAME
.
- Test Files and Discussion Files:
- (AERT 1.1.9) HTML 4.0: Check
AREA
elements for valid alt
attribute
- Suggested Check (
AREA
):
- Must have a valid
alt
attribute.
- Invalid: NULL
alt
value (alt=""
)
- Suspicious:
alt
attribute value is placeholder
text.
- @@is this complete?
- Suggested Message:
- "Missing text equivalent: Missing text equivalent for this image map area."
- "Suspicious
alt
: Suspicious alt
attribute for this image
map area: [current alt text]."
- Suggested Repair:
- Prompt user for
alt
text for the AREA
element.
- Test Files and Discussion Files:
- (AERT 1.1.10) HTML 4.0: Check
SCRIPT
elements for valid equivalents
where necessary
- Suggested Check (
SCRIPT
):
NOSCRIPT
section must follow the SCRIPT
end element AND
NOSCRIPT
section must contain Accessible HTML
NOSCRIPT
section must not contain placeholder text
- Suggested Message:
- "Language for missing
NOSCRIPT
: Missing NOSCRIPT
element
for this SCRIPT
element."
- "If contained HTML not accessible:
NOSCRIPT
section contains
inaccessible HTML: [description of problems]."
- Suggested Repair:
- Insert
NOSCRIPT
section
- Allow user to insert text or link to text equivalent file that describes the
SCRIPT
- Test Files and Discussion Files:
- (AERT 1.1.11) HTML 4.0: Check
A
elements for valid text content
- @@handled by technique 13.1.1 - verify that targets are clearly identified? What else do
we need to check for?
- (AERT 1.1.12) HTML 4.0: Verify that valid text equivalents are provided for
PRE
and XMP
elements used to create ASCII art. (OPEN ISSUES: A-Prompt
has been using an algorithm to detect ASCII art (There must be 5 or more lines of text and
there must be 5 or more same characters in a sequence). This works quite well but detects
things such as code samples (don't require text equiv.) and guitar tabulature (do require
text equiv.) Should we suggest this algorithm in the evaluation? AND What about ASCII art
that is interspersed in text, such as in P
elements? AND Bill Shackleton
suggested that a tool use a library of well-known ascii art to detect some ascii art such
as emoticons. Yahoo maintains
a list of ascii art one list is specifically about smileys.)
- Suggested Check (
PRE
and XMP
):
- ASCII art has an associated text equivalent.
- Suggested Message:
- "Character based artwork (ASCII art) requires a textual description."
- Suggested Repair:
- Ask user for a description of the ASCII art or allow them to add a link to a text
equivalent file.
- Test Files and Discussion Files:
- (WCAG 1.2, P1, Techniques) Provide redundant text links for each active
region of a server-side image map.
- (AERT 1.2.1) HTML 4.0: Verify that a server-side image map has associated text
links. (OPEN ISSUES: WCAG issue: text links are a priority 3 if the same image
also has a client side map (images can have both a client-side and a server-side).)
- Suggested Check (
IMG ISMAP
):
- Text link for each active area of the image map
- Suggested Message:
- "Server-side image maps should have associated text links in the document."
- Suggested Repair:
- Prompt the user for associated text links OR
- Help the user convert the server-side image map to a client-side image map and provide
text-equivalents for each link in the client-side image map.
- If possible, check the text links against the links contained on the server-side image
map by asking user to upload the server side definition file if it's a standard format or
pinging the image map with random coordinates and seeing if all returned pages correspond
to the links.
- Test Files and Discussion Files:
- (WCAG 1.3, P1, Techniques) 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.
- (AERT 1.3.1) HTML 4.0: Verify that multimedia have audio descriptions.
- Suggested Check (
any_tag any_attribute=multimedia_uri
, OBJECT
type=any_multimedia_type
):
- Multimedia presentations should have an associated audio description.
- Suggested Repair:
- Display the multimedia file and allow the user to create an audio description of the
important information.
- Allow the user to add a link to an existing audio description file.
- (WCAG 1.4, P1, Techniques) For tools that create time-based multimedia
presentations (e.g., a movie or animation), ensure synchronized equivalent alternatives
are provided. (e.g., captions or auditory descriptions of the visual track)
- (AERT 1.4.1) HTML 4.0: Verify that multimedia have synchronized equivalents.
- Suggested Check (
any_tag any_attribute=multimedia_uri
, OBJECT
type=any_multimedia_type
):
- Multimedia presentations should have synchronized equivalents.
- Suggested Message:
- "For any time-based multimedia presentation (e.g., a movie or animation),
synchronize equivalent alternatives."
- Suggested Repair:
- Give user option to edit option with editor of their choice (e.g. the default editor on
their system)
- (AERT 1.4.2) SMIL: Check SMIL files for synchronized media. (OPEN
ISSUES: This technique is a specific example of 1.4.1. Should it stand on its own or be
incorporated into 1.4.1? and This technique is also SMIL specific while the majority of
techniques are HTML specific. Should we include a SMIL specific technique?)
- Suggested Check:
- SMIL files should have the
system-captions
flag for at least one text
stream and one auditory stream.
- (WCAG 1.5, P3, Techniques) 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.
- (AERT 1.5.1) HTML 4.0: Verify that text links are provided for client-side image
maps.
- Suggested Check (
IMG usemap
):
- Document must contain text links for each active area of the image map.
- Associated text links may be found by searching the document for anchors with
href
attribute values that correspond to the AREA
elements in the given usemap
.
- Suggested Message:
- "Client-side image maps should have associated text links."
- Suggested Repair:
- Allow the user to create associated text links for each active area in the image map.
- Test Files and Discussion Files:
- (WCAG 2.1, P1, Techniques) Ensure that all information conveyed with
color is also available without color.
- (AERT 2.1.1) HTML 4.0: Verify that information conveyed with color is available
without color.
- Suggested Check:
- Elements:
IMG | APPLET | OBJECT | SCRIPT | INPUT |
as well as the HTML
elements and attributes listed in the technique for WCAG 2.2.
- Suggested Message:
- "Ensure that information is not conveyed through color alone. For example, when
asking for input from users, do not write 'Please select an item from those listed in
green.' Instead, ensure that information is available through other style effects (e.g., a
font effect) and through context (e.g,. comprehensive text links)."
- Suggested Repair:
- Display a user notification if any of the color-possible elements are in the document.
- (WCAG 2.2, Images: P2, Text: P3, Techniques) Ensure that foreground and
background color combinations of images and text provide sufficient contrast when viewed
by someone having color deficits or when viewed on a black and white screen.
- (AERT 2.2.1) HTML 4.0/CSS: Test the color attributes of the following
elements for visibility.
- Suggested Check:
BODY bgcolor | text | alink | link | vlink | background =anything
OR
TABLE bordercolor | bgcolor =anything OR
TD | TH bgcolor =anything OR
HR color =anything OR
any_element style="any_color_specification"
STYLE "any_color_specification"... STYLE
- Where any_color_specification is defined as any CSS specification which
contains:
color | background-color | background-image | background
- Suggested Message:
- "Poor visibility between text and background colors."
- Suggested Repair:
- Algorithm: Two colors provide good color visibility if the brightness difference and the
color difference between the two colors are greater than a set range:
Brightness difference is acceptable if:
((Red RGB value * 299) + (Green RGB value * 587) + (Blue RGB value * 114)) / 1000 > 125
Color difference is acceptable if:
|Red RGB_1 - Red RGB 2| + |Green RGB 1, Green RGB 2| + |Blue RGB 1 - Blue RGB 2| > 500
- Allow the user to change the poor color combinations.
- Store any good color combinations entered by the user and use them as default prompts in
the future.
- Test Files and Discussion Files:
- (WCAG 3.1, P2, Techniques) When an appropriate markup language exists,
use markup rather than images to convey information.
- (AERT 3.1.1) HTML 4.0: Verify that elements do not need to be converted to an
appropriate markup language.
- Suggested Check:
- Elements:
PRE | IMG | OBJECT | APPLET
- Suggested Message:
- "When an appropriate markup language exists, use markup rather than images to
convey information. For example, use MathML to mark up mathematical equations, and style
sheets to format text and control layout"
- Suggested Repair:
- Display a user notification if any of these possible conversion elements are in the
document.
- Help authors convert decorative ASCII art in
PRE
elements to SVG or an
image format.
- Help authors convert ASCII art representing tables of data in PRE elements to TABLE
elements.
- Help authors convert images (
IMG
or OBJECT
) used to format
text to XHTML/XML with style sheets.
- Help authors convert images (
IMG
or OBJECT
) used to format
mathematical equations to MathML.
- (WCAG 3.2, P2, Techniques) Create documents that validate to published
formal grammars.
- (AERT 3.2.1) HTML 4.0: Check document for public text identifier. (OPEN
ISSUE: Reference BizTalk and OASIS catalogs?)
- Suggested Check:
- Element: none (i.e. applies to all documents)
- Requirements:
- Suggested Message:
- "If no
!DOCTYPE
at all: Missing language identifier for this
document."
- "If document type is defined in HTML element: "Document type should be in the
document type definition. It's use in the HTML element is deprecated."
- Suggested Repair:
- If the document type is in the HTML element: move to the
!DOCTYPE
declaration.
- If no valid document type at all: Prompt the user for a public text identifier,
preferably by offering a menu of choices and explanations
- Test Files and Discussion Files:
- (WCAG 3.3, P2, Techniques) Use style sheets to control layout and
presentation.
- (AERT 3.3.1) HTML 4.0: Check document for use of style sheets.
- Suggested Check:
- Elements: none (i.e. applies to all documents)
- Requirements: Document should contain at least one of the following:
STYLE
or LINK rel="stylesheet"
elements within the HEAD
element | "style
" attributes on any element | FONT
| BASEFONT
| "text," "vlink," "link," and "alink"
attributes on BODY
.
- If layout tables are identified (see technique 5.1.1), trigger this check as well. We
will inform user that style sheets can be used instead of layout tables in 5.1.1.
- Suggested Message:
- "Use style sheets to control layout and presentation. For example, use the CSS '
font
'
property instead of the HTML FONT
and BASEFONT
elements to
control font styles"
- Suggested Repair:
- If style sheets are not used, verify that the author has chosen not to modify the
presentation in any way.
- If
FONT
or BASEFONT
elements or "text,"
"vlink," "link," and "alink"
attributes on BODY
,
suggest or help the author convert the presentation properties to style sheets.
- If the author chooses to convert deprecated markup to style sheets or add style sheets,
trigger technique 6.1 to verify that the document is readable when style sheets are not
applied.
- (WCAG 3.4, P2, Techniques) Use relative rather than absolute units for
markup language attribute values and style sheet property values.
- (AERT 3.4.1) HTML 4.0: Check document for relative units of measure.
- Suggested Check:
- Elements:
- "
style
" attribute on any element OR
STYLE
- Requirements For any HTML or CSS element defined to take a
%LENGTH, %PIXELS,
%MULTILENGTH
, or %MULTILENGTHS
, a validated value should either end
with "%" or begin with "+" or "-" or use the "em"
or "ex" units.
- Exception: "
width
" and "height
" attributes
of IMG, OBJECT, and APPLET
elements.
- Suggested Message:
- "This element uses absolute units of measure rather than relative units of
measure."
- Suggested Repair:
- Allow user to change the units of measure as follows: 1. Allow user to specify which of
the absolute sizes is the default, 2. Automatically compute all others in terms of the
default, with choice of %, +/-, or em/ex
- (WCAG 3.5, P2, Techniques) Use header elements to convey document
structure and use them according to specification.
- (AERT 3.5.1) HTML 4.0: Check document for header nesting.
- Suggested Check:
- Elements:
Header
elements (H1-H6)
- Requirements: Header elements should nest according to the following rules
- 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.
- Suggested Message:
- "Improper header nesting: Header levels must not increase by more than one level
per heading. Do not use headings to create font effects; use style sheets to change font
styles."
- Suggested Repair:
- Allow user to modify the header numbering within the document.
- (AERT 3.5.2) HTML 4.0: Check document for missing header markup.
- Suggested Check:
- Element:
P
- Requirement: Paragraphs should be verified that they are not 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.
- Suggested Message:
- "Text has been identified that could possibly be a header. Is this text used as a
header: [potential header text]?"
- Suggested Repair:
- Allow user to convert the text to a header.
- Test Files and Discussion Files:
- (AERT 3.5.3) HTML 4.0: Verify that header elements are not used for formatting.
- Suggested Check:
- Elements:
Header
elements (H1- H6)
- Requirement: If a header element's text content is longer than 20 words, query the user.
- Suggested Message:
- "Header elements (H1 - H6) should be used to define headers and should not be used
for formatting text."
- Suggested Repair:
- Allow the user to convert any header text to another type. Possible types are:
- (WCAG 3.6, P2, Techniques) Mark up for lists and list items properly.
- (AERT 3.6.1) HTML 4.0: Check that list elements are within a list container and
well nested.
- Suggested Check:
UL
, OL
, DL
- Requirements
- Each
UL/OL/DL
tag must be followed by at least one LI
. (This
avoids the use of lists to create formatting e.g. via UL UL UL...
)
- Suspicious: a single
LI
, which may be used merely for formatting
- Suggested Message:
- "List items should not be used for formatting text. Use Style sheets or tables for
formatting text."
- Suggested Repair:
- Allow the user to format the text within the LI element to another element via a
choice of style sheets or tables.
- (WCAG 3.7, P2, Techniques) Mark up for quotations in templates. Do not
use quotation markup for formatting effects such as indentation.
- (AERT 3.7.1) HTML 4.0: Verify instances where quote markup should be used.
(OPEN ISSUE:
Q
is not supported in today's browsers, thus converting quotes
marks to Q
will basically delete the quote marks for all users. what do we
suggest in the meantime?)
- Suggested Check:
- Element:
P
[list of others?] elements
- Requirement: quote should be marked up with
Q
or BLOCKQUOTE
.
Potential quotes can be identified by:
- Any text that is enclosed by quote marks (" " or ' ').
- Indented text.
- Lots of emphasized text (greater than x words??@@)
- Suggested Message:
- "The following text may need to be marked using
Q
or BLOCKQUOTE
:
[potential quote text]."
- Suggested Repair:
- Allow the user to convert blocks of text to
Q
or BLOCKQUOTE
.
- Test Files and Discussion Files:
- (AERT 3.7.2) HTML 4.0: Verify that
Q
and BLOCKQUOTE
are used properly.
- Suggested Check:
- Elements:
Q
and BLOCKQUOTE
- Requirement:
- Inline quotes (marked with
Q
) have at least one word in front of, or
behind, the quote text and are less than 10 words
- Long quotes (marked with
BLOCKQUOTE
) are greater than 10 words.
- Suggested Message:
- "If a block of text is marked as
BLOCKQUOTE
when it should be marked
as Q
: This text should be marked as Q
not BLOCKQUOTE
:
[quote text]."
- "If a block of text is marked as
Q
when it should be marked as BLOCKQUOTE
:
This text should be marked as BLOCKQUOTE
not Q
: [quote
text]."
- Suggested Repair:
- Allow the user to convert blocks of text to
Q
or BLOCKQUOTE
or
vice versa.
- (AERT 3.7.3) HTML 4.0: Verify that
BLOCKQUOTE
is not used for
formatting.
- Suggested Check:
- Element:
BLOCKQUOTE
unless text content has quote marks ("" or
'').
- Requirement:
- Not allowed: nested
BLOCKQUOTE
s.
- Suggested Message:
- "This text should be marked as normal text but formatted using style sheets or a
table."
- "
BLOCKQUOTE
elements should be used to define quotes and should not be
used for formatting text."
- Suggested Repair:
- Allow the user to transform the text in the
BLOCKQUOTE
element into a P
(paragraph) element.
- (WCAG 4.1, P1, Techniques) Clearly identify changes in the natural
language of generated text.
- (AERT 4.1.1) HTML 4.0: Verify changes in the natural
language of document.
- Suggested Check:
- Element: none (i.e. applies to all documents that contain text)
- Requirement: The document must contain at least 3 words of text.
- Suggested Message:
- "Any words or phrases in a document that are not in the primary language of the
document should be identified."
- Suggested Repair:
- Display the above user notification and provide the following suggestions:
- For blocks of text that are not in the primary language and are already enclosed by
markup elements such as
P
aragraph, 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.
- (WCAG 4.2, P3, Techniques) Specify the expansion of each abbreviation
or acronym in a document where it first occurs.
- (AERT 4.2.1) HTML 4.0: Verify that abbreviations and acronyms need expanding.
- Suggested Check:
- Elements: none (i.e. applies to all documents that contain text)
- Requirements:
- Document must contain at least 3 words.
- Document contains a potential abbreviation (word that starts with a capital letter,
contains lower case characters and ends with a period) or acronym (word greater than 2
characters that is all capital letters).
- Suggested Message:
- "A potential acronym/abbreviation has been discovered: [potential
acronym/abbreviation]."
- Suggested Repair:
- Ask the user if the acronym or abbreviation was defined elsewhere on the page and if so
give the user the option to re-use it.
- Allow the user to enter a definition for the abbreviation of acronym.
- (WCAG 4.3, P3, Techniques) Identify the primary natural language of a
document.
- (AERT 4.3.1) HTML 4.0: Verify the primary language of the document.
- Suggested Check:
- Suggested Message:
- "Missing
lang
attribute: The primary language of this document has not
been set."
- "Invalid
lang
attribute: The primary language of this document is
invalid."
- Suggested Repair:
- Prompt the user for the primary language of the document.
- Ensure that the language entered is one of the ISO 639 language codes.
- A (somewhat costly) technique for guessing the primary language, is to check for the use
of common words in a language. For example, if you find "a, the, you, for, is, of,
and" then it's English. If you find "le, du, la, a, se, pour, aux, des, ne"
then it's French, etc.
- Test Files and Discussion Files:
- (WCAG 5.1, P1, Techniques) For data tables, identify row and column
headers.
- (AERT 5.1.1) HTML 4.0: Determine the purpose of the table.
- Suggested Check:
- The purpose of the table must be determined before performing an accessibility
evaluation. To help the author make this assessment, the following language may be used:
- Suggested Message:
- "Data tables present relational data such as a bus schedule, a comparison of
regional sales figures, or a listing of employee contact information. Cells in data tables
are related to each other and usually must be perceived as a group."
- "Layout tables visually format images, text, and other information on the page such
as a navigation bar, or a newspaper page with stories, links, and images. Each cell in a
layout table is normally independent and can be viewed on its own."
- (AERT 5.1.2) HTML 4.0: Check data table for row and column headers.
- Suggested Check:
- Element:
TABLE
.
- Requirement: the table must have at least one complete row of headers or one complete
column of headers.
- This technique applies only to tables used for data, not to tables used for layout
purposes.
- Suggested Message:
- "If both row and column headers are missing: Table is missing headers."
- "If either row or column headers are missing: Table has row/column headers but may
require column/row headers."
- Suggested Repair:
- Allow the user to modify the table to include row headers and/or column headers.
- Allow the user to convert the top row and/or the left column to headers.
- The user should create at least one complete row or one complete column of headers.
- Test Files and Discussion Files:
- (WCAG 5.2, P1, Techniques) For data tables that have two or more
logical levels of row or column headers, use markup to associate data cells and header
cells.
- (AERT 5.2.1) HTML 4.0: Check data tables for multiple levels of row and column
headers.
- Suggested Check:
- Element:
TH span=(2 or more)
and either
- two or more
TR
elements containing at least one TH
- two or more
TH
elements within any TR
- Requirements:
- use of
SCOPE | AXIS | HEADER
- two or more rows containing
TH
OR
- two or more columns contain
TH
- Suggested Message:
- "Your table should identify structural groups of rows and groups of columns. Label
table elements with the "
scope
", "headers
",
and "axis
" attributes so that future browsers and assistive
technologies will be able to select data from your table by filtering on categories."
- Suggested Repair:
- If the table does contain 2 or more logical levels of row or column headers, use the HTML 4 table algorithm
to show the author how the headers are currently associated with the cells. If the author
determines that the current mark-up is not sufficient, allow the author to markup the
table
TD
or TH
elements with scope
, axis
,
or headers
attributes.
- Test Files and Discussion Files:
- (WCAG 5.3, P2, Techniques) Do not use tables for layout unless the
table makes sense when linearized. Otherwise, if the generated table does not make sense,
provide an alternative equivalent (which may be a linearized version).
- (AERT 5.3.1) HTML 4.0: Verify that layout tables make sense when linearized.
- Suggested Check:
- Element:
TABLE
- Requirement: Layout tables should make sense when linearized. This technique applies
only to tables used for layout purposes, not to data tables.
- Suggested Message:
- "Tables used for layout should make sense when linearized."
- "When a table is 'linearized,' the cells are read in the order in which they appear
in the HTML source."
- Suggested Repair:
- Linearize the table and ask the author to verify that the result is understandable.
- Test Files and Discussion Files:
- (WCAG 5.4, P2, Techniques) If a table is used for layout, do not use
any structural markup for the purpose of visual formatting.
- HTML 4.0: Check layout tables for structural markup.
- Suggested Check:
- Element:
TABLE
- Requirements: Contains at least one
TH
element. This technique applies only
to tables used for layout purposes, not to data tables.
- Suggested Message:
- "Tables used for layout should not use table headings to create formatting
effects."
- Suggested Repair:
- Allow user to change appearance of
TH
cells by style sheet properties or EM
and/or STRONG
- Test Files and Discussion Files:
- (WCAG 5.5, P3, Techniques) Provide summaries for tables.
- (AERT 5.5.1) HTML 4.0: Check
TABLE
elements for valid "summary
"
attribute.
- Suggested Check:
- Element:
TABLE
- Requirement: Must have valid "
summary
" attribute.
- If the table has nested headings, cells that span multiple columns or rows, or other
relationships that may not be obvious from analyzing the structure of the table but that
may be apparent in a visual rendering of the table, a valid "
summary
"
attribute may be provided.
- Valid "
summary
" attribute:
- Suggested Message:
- For missing summary - "Table is missing a summary."
- "In the summary, describe the purpose of the table (either layout or data). For
example ''This table charts the number of cups of coffee consumed by each senator, the
type of coffee (decaf or regular), and whether taken with sugar.'"
- Additional help text: "A summary of the relationships among cells is especially
important for tables with nested headings, cells that span multiple columns or rows, or
other relationships that may not be obvious from analyzing the structure of the table but
that may be apparent in a visual rendering of the table. A summary may also describe how
the table fits into the context of the current document. If no caption is provided, it is
even more critical to provide a summary."
- Suggested Repair:
- Allow the user to enter a summary of the table.
- Test Files and Discussion Files:
- (AERT 5.5.2) HTML 4.0: Check
TABLE
elements for valid CAPTION
element.
- Suggested Check:
- Element:
TABLE
- Requirement: @@
- Suggested Message:
- "This table does not have a caption: A table caption describes the nature of the
table in one to three sentences. For example, 'Cups of coffee consumed by each
senator.'"
- Suggested Repair:
- Allow the author to enter a CAPTION
- (WCAG 5.6, P3, Techniques) Provide abbreviations for header labels of
tables.
- (AERT 5.6.1) HTML 4.0: Check table for header abbreviations. (OPEN
ISSUES: How determine if an abbreviation is pronounceable? ASCII characters only?)
- Suggested Check:
- Element:
TH
- Requirement: Valid "
abbr
" attribute if the header name is greater
than 15 characters.
- Valid "
abbr
" attributes:
- Not allowed - NULL "
abbr
" value ("")
- Not allowed - "
abbr
" value of spaces (" ")
- Suspicious - placeholder "
abbr
" values
- "
abbr
" values should be shorter than 15 characters, but still
pronounceable.
- Suggested Message:
- "Table header is missing an abbreviation."
- Suggested Repair:
- Allow user to enter abbreviations for table header elements.
- Test Files and Discussion Files:
- (WCAG 6.1, P1, Techniques) Organize documents so they may be read
without style sheets.
- (AERT 6.1.1) HTML 4.0: Verify that the document is readable when style sheets
are not applied.
- Suggested Check:
- Elements:
LINK rel="stylesheet"
STYLE
- At least one "
style
" attribute used on any element.
- Suggested Message:
- "Ensure this document can be read without style sheets."
- Suggested Repair:
- Display a user notification if any use of style sheets is detected.
- (WCAG 6.2, P1, Techniques) Ensure that equivalents for dynamic content
are updated when the dynamic content changes.
- (AERT 6.2.1) HTML 4.0: Check the source of
FRAME
and IFRAME
elements for valid markup files.
- Suggested Check:
- Elements:
FRAME
or IFRAME
- Requirements:
- Valid "
src
" attribute values must have a suffix of
".htm," ".html," ".shtm," ".shtml,"
".cfm," ".cfml," ".asp," ".cgi," ".pl",
".smil" or target document must have a known public identifier at the top of
file.
- Suggested Message:
- "Frame source: [frame source file name] is not a valid markup file."
- Suggested Repair:
- Create an HTML "wrapper" around known object types, e.g. if the target is an
image, place the image in an HTML file.
- @@Adjust Javascript to point inside the wrapper?
- Test Files and Discussion Files:
- (AERT 6.2.2) HTML 4.0: Verify that equivalents of dynamic content are updated
and available as often as the dynamic content. (OPEN ISSUES: This is similar to
issues related to Guideline 7. do we need to tie them together in some way?)
- Suggested Check:
- Elements:
SCRIPT, APPLET, OBJECT type=@@?
, any_element
event_attribute where event_attribute is "onmouseover" etc.
- Requirements: any actions that change the display must change the equivalent @@Is this
computable in a practical time (cf. NP complete) . Computer science help needed
here. Of course, as in other parts of document, the fact that the equivalent changes
is no guarantee that equivalent is correct than it is guaranteed that
"alt"
text for an image is correct.
- Suggested Message:
- "Ensure that the descriptions of dynamic content are updated with changes in the
dynamic content."
- Test Files and Discussion Files:
- (WCAG 6.3, P1, Techniques) Ensure that pages are usable when scripts,
applets, or other programmatic objects are turned off or not supported. If this is not
possible, provide equivalent information on an alternative accessible page.
- (AERT 6.3.1) HTML 4.0: Verify that the page is usable when programmatic
objects are disabled.
- Suggested Check:
- Elements:
SCRIPT, OBJECT type=@@?, EMBED, APPLET
- Requirements:
- existence of "
alt
" and/or "title"
and/OR
- accessible alternative content in the body of
OBJECT, NOSCRIPT, NOEMBED, or APPLET
.
- Suggested Message:
- "Ensure that pages are usable when scripts, applets, or other programmatic objects
are turned off or not supported."
- Suggested Repair:
- Provide means to create an accessible alternative representation or provide a link to
one.
- (WCAG 6.4, P2, Techniques) For scripts and applets, ensure that event
handlers are input device-independent.
- (AERT 6.4.1) HTML 4.0: Check for device independent event handlers.
- Suggested Check:
- Elements:
SCRIPT, OBJECT type=@@?, EMBED, APPLET
- Requirements: Objects must not contain device dependent event handlers. @@Does this mean
checking Java, Flash, etc? Can we only do this for scripting? Or prompt the author to
check?
- Suggested Message:
- "For scripts and applets, ensure that event handlers are input
device-independent."
- Suggested Repair:
- Display object source code and suggest device independent replacement code.
- (WCAG 6.5, P2, Techniques) Ensure that dynamic content is accessible or
provide an alternative presentation or page.
- (AERT 6.5.1) HTML 4.0: Check that a
NOFRAMES
element exists within
each FRAMESET
. (OPEN ISSUES: 6.5.2 [priority 2] @@Need something for
scripts and programmatic objects?)
- Suggested Check:
- Element:
FRAMESET
- Requirements:
- A valid
NOFRAMES
section should exist within each FRAMESET
section
- Valid: Must contain at least one word of text or accessible HTML code.
- Valid: The contents of the
NOFRAMES
element must provide the
necessary links to navigate the site.
- Invalid: Telling the user that they should upgrade to a browser that supports
frames. Suspicious words within the text of a
NOFRAMES
element:
"upgrade," "full advantage," supports frames,"
"missing" etc.
- Suggested Message:
- "Does your page work if frames are not loaded?"
- Suggested Repair:
- Allow user to construct a valid
NOFRAMES
section.
- Test Files and Discussion Files:
- (WCAG 7.1, P1, Techniques) Until user agents allow users to control
flickering, avoid causing the screen to flicker.
- (AERT 7.1.1) HTML 4.0: Verify that the page does not cause flicker.
(OPEN ISSUES: It is desirable that a tool be able to measure flicker. This could be done
by software that renders, takes screenshots and compares. [Len Kasday, 23
January 2000])
- Suggested Check:
- Elements:
SCRIPT
OBJECT type =
(@@what are the type attribute values for Java, etc.?)
EMBED
APPLET
IMG
element with "src
" name ending with '.gif'.
- Suggested Message:
- "Display flicker is distracting and may be dangerous to some users. Please ensure
this element does not cause the display to flicker."
- Suggested Repair:
- Display the object and allow the user to verify that it does not cause display flicker.
If object does cause flicker, allow user to modify object.
- (WCAG 7.2, P2, Techniques) Until user agents allow users to control
blinking, avoid causing content to blink.
- (AERT 7.2.1) HTML 4.0: Check for
BLINK
elements.
- Suggested Check:
- Suggested Message:
- "The
BLINK
element is not defined in any W3C HTML specification and
should not be used."
- Suggested Repair:
- Allow the user to remove
BLINK
elements from the document.
- Allow the user to replace
BLINK
elements with any of the following
elements:
STRONG
EM
SPAN
- allow the user to enter attributes for the element.
H1
H2
H3
H4
H5
H6
- Test Files and Discussion Files:
- (WCAG 7.3, P2, Techniques) Until user agents allow users to freeze
moving content, avoid causing movement.
- (AERT 7.3.1) HTML 4.0: Check for
MARQUEE
elements.
- Suggested Check:
- Suggested Message:
- "The
MARQUEE
element is not defined in any W3C HTML specification and
should not be used."
- Suggested Repair:
- Allow the user to remove
MARQUEE
elements from the document.
- Allow the user to replace
MARQUEE
elements with any of the following
elements:
STRONG
EM
SPAN
- allow the user to enter attributes for the element.
H1
H2
H3
H4
H5
H6
- Test Files and Discussion Files:
- (AERT 7.3.2) HTML 4.0: Verify that programmatic objects do not create moving
content.
- Suggested Check:
- Elements:
SCRIPT
- distinguished by (see discussion)??
OBJECT type =
(@@what are the type attribute values for Java, etc.?)
EMBED
APPLET
- Suggested Message:
- "Moving text may be difficult to read and is inaccessible for many viewers."
- Suggested Repair:
- Allow the user to remove the
SCRIPT
from the document or create a mechanism
to stop the movement.
- @@ what about
OBJECT, EMBED, and APPLET
?
- Test Files and Discussion Files:
- (WCAG 7.4, P2, Techniques) Until user agents provide the ability to
stop the refresh, do not create periodically auto-refreshing pages.
- (AERT 7.4.1) HTML 4.0: Remove auto-refresh attributes from
META
elements.
- Suggested Check:
- Elements:
META http-equiv="refresh" content=integer_greater_than_zero
- Note:If the "
content
" attribute is a URI this is an auto-redirect
page. Refer to technique 7.5.1
- Suggested Message:
- "This page uses auto-refresh which can make the page difficult to read for some
people."
- Suggested Repair:
- Allow user option to either remove the auto-refresh from the document or create a page
with link to new page.
- Test Files and Discussion Files:
- (WCAG 7.5, P2, Techniques) Until user agents provide the ability to
stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure
the server to perform redirects.
- (AERT 7.5.1) HTML 4.0: Check auto-redirect attributes on
META
elements.
- Suggested Check:
- Element:
META http-equiv="refresh" content="any-URI"
.
- Suggested Message:
- "This page uses auto-redirect which can make the page difficult to read for some
people."
- Suggested Repair:
- Allow the user to remove the auto-redirect from the document and add a link to the new
document.
- Test Files and Discussion Files:
- (WCAG 8.1, Important and not elsewhere: P1, Otherwise: P2, Techniques)
Make programmatic elements such as scripts and applets directly accessible or compatible
with assistive technologies.
- (AERT 8.1.1) HTML 4.0: Verify that programmatic objects are directly accessible.
(OPEN ISSUES: Tools should include means to test the embedded technologies, e.g. java, at
least by running them, preferably by including any test software supplied for the
technology. [Len
Kasday - 23 January 2000])
- Suggested Check:
- Elements:
OBJECT, APPLET
, EMBED or SCRIPT
.
- Suggested Message:
- "This element may not be accessible to all users. Please ensure there is an
accessible interface to this object."
- "Ensure that scripts, applets, or other programmatic objects are directly
accessible"
- Suggested Repair:
- Display a user notification if any of the programmatic elements are in the document.
- (WCAG 9.1, P1, Techniques) Use client-side image maps instead of
server-side image maps except where the regions cannot be defined with an available
geometric shape.
- (AERT 9.1.1) HTML 4.0: Check for use of server-side image maps.
- Suggested Check:
- Suggested Message:
- "Use client-side image maps instead of server-side maps."
- Suggested Repair:
- Allow the user to convert the server-side image map to a client-side image map.
- (WCAG 9.2, P2, Techniques) Ensure that any element that has its own
interface can be operated in a device-independent manner.
- HTML 4.0: Ensure that any element that has its own interface can be operated in
a device-independent manner. (OPEN ISSUE: This technique is strongly tied to
Guideline 8 and checkpoint 1.1 (image maps). Is there redundancy that we can get rid of?)
- Suggested Check:
- Elements:
OBJECT type =
(@@what are the type attribute values for Java, etc.?)
EMBED
APPLET
- Suggested Message:
- "Ensure this programmatic object can be operated in a device independent
manner."
- Suggested Repair:
- Display a user notification if any of the programmatic objects are in the document.
- Test Files and Discussion Files:
- (WCAG 9.3, P2, Techniques) For scripts, specify logical event handlers
rather than device-dependent event handlers.
- HTML 4.0: Check scripts for logical event handlers.
- Suggested Check:
- Elements: All elements that can contain event handlers
- Requirement: Elements must have a device independent event handler if they have any of
the following device dependent event handlers:
onMouseDown()
onMouseUp()
onClick()
onMouseOver()
onMouseOut()
onMouseMove()
- Suggested Message:
- "For scripts, specify logical event handlers rather than device-dependent event
handlers."
- Suggested Repair:
- Allow the user to add or replace the event handlers according to the following list:
- "
onMouseDown
" add or replace with "onKeyDown
"
- "
onMouseUp
" add or replace with "onKeyUp
"
- "
onClick
" add or replace with "onKeyPress
"
- "
onMouseOver
" add or replace with "onFocus
"
- "
onMouseOut
" add or replace with "onBlur
"
- "
onMouseMove
" remove or replace with ??@@
- (WCAG 9.4, P3, Techniques) Create a logical tab order through links,
form controls, and objects.
- (AERT 9.4.1) HTML 4.0: Check for "
tabindex
" attribute.
(OPEN ISSIUES: If the tab order jumps around too much it could be confusing to someone
using magnification or a cognitive disability. Can we check for this?)
- Suggested Check:
- Elements:
A
AREA
BUTTON
INPUT
OBJECT
SELECT
TEXTAREA
- Suggested Message:
- "May contain a valid "
tabindex
" attribute"
- Suggested Repair:
- Display the controls and allow the user to set the tabindex of each.
- (WCAG 9.5, P3, Techniques) Provide keyboard shortcuts to important
links (including those in client-side image maps), form controls, and groups of form
controls.
- (AERT 9.5.1) HTML 4.0: Check for "
accesskey
" attribute.
- Suggested Check:
- Elements:
A
AREA
BUTTON
INPUT
LABEL
LEGEND
TEXTAREA
- Requirements:
- If any of these elements are present, at least one of them should have a valid "
accesskey
"
attribute
- Suggested Message:
- "There are no keyboard shortcut keys to any of the controls in this document.
Important links and controls should have shortcut keys."
- Suggested Repair:
- Display the objects that can contain shortcut keys and allow the user to assign shortcut
keys to them.
- (WCAG 10.1, P2, Techniques) Until user agents allow users to turn off
spawned windows, do not cause pop-ups or other windows to appear or change the current
window without informing the user.
- (AERT 10.1.1) HTML 4.0: Check
A
and AREA
elements for
valid "target
" attributes. (OPEN ISSUES: How do we handle
the "until user agents" clause? AND Is it enough for the document to inform the
user that the link will open in a new window or must we completely avoid new windows?)
- Suggested Check:
- Elements:
- Requirements:
- Should not have "
target
" attributes of "_blank
"
or "_new
".
- Suggested Message:
- "This anchor element [anchor text] will open a new window that can disorient some
users."
- Suggested Repair:
- Allow the user to
- remove the "
target
" attribute or
- use an existing window as the target
- Test Files and Discussion Files:
- (AERT 10.1.2) HTML 4.0: Verify that scripts do not spawn new windows.
(OPEN ISSUES: Do all
APPLET
elements trigger this technique? AND Are there
other embedded elements or scripting languages that ought to trigger this technique?)
- Suggested Check:
- Elements:
- Requirement:
SCRIPT
must not contain code of window.open()
- Suggested Message:
- "This script will open a new window that can be disorienting for some users."
- Suggested Repair:
- Allow the user to remove the scripting code that opens a new window.
- (WCAG 10.2, P2, Techniques) 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.
- (AERT 10.2.1) HTML 4.0: Verify that
LABEL
elements are properly
positioned. (OPEN ISSUES: Create a separate technique for LEGEND
and
LABEL
? [Michael Cooper
- 28 January 2000])
- Suggested Check:
- Elements:
- Requirement: Text labels must be positioned as the first text immediately before or
after the form control.
- Suggested Message:
- "Labels for form controls should be positioned close to their corresponding form
controls. This control [control type] does not have a closely positioned label."
- Suggested Repair:
- Allow the user to reposition labels associated with form controls as follows:
- Labels for radio buttons and checkboxes should appear after the radio button or
checkbox. For example: [checkbox] oranges, [checkbox] apples.
- Labels for text fields appear before the text field. For example: last name [text area].
- Labels for groups of any form control should appear before the group. For example:
choose a city [radio button] Boston [radio button] Madison.
- (WCAG 10.3, P3, Techniques) Until user agents 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.
- (AERT 10.3.1) HTML 4.0: Verify that a linearized version of tables used for
layout is provided.
- Suggested Check:
- Element:
TABLE
- Requirement: A linear version of the table is provided
- Suggested Message:
- "Please consult the definition of linearized table. This checkpoint benefits people
with user agents (such as some screen readers) that are unable to handle blocks of text
presented side-by-side; the checkpoint should not discourage content developers from using
tables to represent tabular information."
- Suggested Repair:
- If it has been determined that the table is used for layout (see Technique 5.1.1) then
create a linear version of the table by: [@@insert heuristics from table linearizer -
basically replace
TABLE
markup with text structural markup]. The author will
then need to check that it is readable.
- If it has been determined that the table is used for data (see Technique 5.1.1) then
create a linear version of the table by: [@@table linearizer heuristics? basically, for
each cell repeat the column and row headers associated with it]. The author will then need
to check that it is readable.
- Test Files and Discussion Files:
- Table linearizer(@@link)
- Trace "HelpDB" (@@link)
- other examples?
- (WCAG 10.4, P3, Techniques) Until user agents handle empty controls
correctly, include default, place-holding characters in edit boxes and text areas.
- (AERT 10.4.1) HTML 4.0: Check for valid default values of
INPUT, TEXTAREA
,
and SELECT
elements.
- Suggested Check:
- Elements:
INPUT type="text | checkbox | radio"
TEXTAREA
OPTION
- Requirements
INPUT
elements that have a type of "text",
"checkbox" or "radio"
must have at least one word of text in
their "value
" attribute.
- Between the
TEXTAREA
start and TEXTAREA
end elements must be
at least one word of text.
- One
OPTION
in each group contained by SELECT
elements must
have a "selected
" attribute.
- Suggested Message:
- "
INPUT
element missing value: This form control is missing placeholder
text."
- "
TEXTAREA
missing text: This TEXTAREA
is missing
placeholder text."
- "
OPTION
not selected: At least one OPTION
must be
selected within this group."
- Suggested Repair:
INPUT
element missing value: Allow user to enter placeholder text.
TEXTAREA
missing text: Allow user to enter text.
OPTION
not selected: Display all options and allow user to select one as
"selected".
- (WCAG 10.5, P3, Techniques) Until user agents render adjacent links
distinctly, include non-link, printable characters (surrounded by spaces) between adjacent
links.
- (AERT 10.5.1) HTML 4.0: Check for non-whitespace characters between consecutive
A
elements.
- Suggested Check:
- Element:
A
end element.
- Requirement:
A
sections within the same line of text must be separated by a
sequence of "whitespace, non-whitespace, whitespace".
- Whitespace is a space, tab, CR, or
- Non-whitespace is any text character.
- Suggested Message:
- "These sequential links do not have separating characters: [sequential
links]."
- Suggested Repair:
- Allow user to insert " | " characters between sequential links. Allow user to
choose another character other than "|" for separator.
- (WCAG 11.1, P2, Techniques) Produce markup using W3C technologies when
they are available and appropriate for a task and use the latest versions when supported.
- (AERT 11.1.1) HTML 4.0: Verify that W3C technologies are used, where possible
and appropriate. (OPEN ISSUES: Many of these W3C formats are not widely supported
yet. Therefore, how do we deal with this in the meantime? Present the info and let the
author decide?)
- Suggested Check:
- Element: ?@@
- Requirements:
- Check for uses of non-W3C technologies such as: PDF, Flash, GIF images, JPG images,
proprietary HTML elements (@@other major ones??).
- @@link See 1.1.1 for images used for mathematical equations.
- Note. I left out JavaScript because there is not a W3C equivalent technology yet.
- Suggested Message:
- "Non-W3C technology used: W3C technologies have been reviewed for accessibility
issues throughout the design phase and have accessibility built-in. Many non-W3C formats
require specific applications (often called plug-ins) that are inaccessible or do not work
well with assistive technologies. Using W3C technologies will tend to make pages more
accessible to more people using a wider variety of hardware and software. If inaccessible
technologies (proprietary or not) must be used, equivalent accessible pages must be
provided."
- Suggested Repair:
- Suggest that where appropriate, the author:
- convert quicktime movies (others?) into SMIL presentations.
- convert GIF and JPG images with text to text with style sheets.
- convert Flash animations to a combination of valid HTML, SMIL, and PNG or SVG.
- convert images of math equations to MathML.
- Use a text-only page generator (such as Adobe's PDFtoText) to create an equivalent
accessible page.
- (WCAG 11.2, P2, Techniques) Avoid deprecated features of W3C
technologies.
- (AERT 11.2.1) HTML 4.0: Check for deprecated features of W3C technologies.
- Suggested Check:
- Suggested Message:
- "This HTML element [deprecated element] is now deprecated and should not be used.
Use this element instead: [replacement element]."
- Suggested Repair:
- Allow the user to replace
FONT
with CSS
.
- Allow the user to replace
IMG
and APPLET
with OBJECT
.
- (WCAG 11.3, P3, Techniques) Provide information so that users may
receive documents according to their preferences (e.g., language, content type, etc.)
- (AERT 11.3.1) HTML 4.0: Check that documents are served per user preferences.
- Suggested Check:
- Element: ?@@
- Requirement: ?@@
- Suggested Message:
- Suggested Repair:
- Prompt user to specify language of document in technique 4.3.1.
- Use CC/PP or XML/XSLT or other transformations on the server or gateway to configure a
page for various user preferences and device profiles.
- Serve style sheets based on user preferences - use the media types.
- Work with your server system administrator to provide content negotiation.
- Use browser sniffing on the client to request documents on the server.
- Use cookies to remember user preferences between sessions and server documents per those
preferences.
- Link to other versions of the document (other formats and languages).
- If not possible to use content negotiation, indicate content type or language through
markup (e.g., in HTML use "
type
" and "hreflang
").
- (WCAG 11.4, P1, Techniques) If, after best efforts, an alternative page
is necessary, ensure that it includes equivalent information (or functionality), and is
updated as often as the inaccessible (original) page.
- (AERT 11.4.1) HTML 4.0: Verify that the page has passed all checkpoints of the
desired conformance level.
- Suggested Check:
- Elements: All elements specified in this document.
- Requirements: Check the document for compliance to the WCAG guidelines according to the
level specified by the user.
- Suggested Message:
- "This document does not conform to the WCAG guidelines. If you are unable to make
the necessary repairs to this document then please create another equivalent page that is
accessible and link to it from this document."
- Suggested Repair:
- Allow user to insert a link in the document to another more accessible page.
- Dynamically generated alternative pages [references@@].
- Tools to generate alternative pages [references@@].
- (WCAG 12.1, P1, Techniques) Title each frame to facilitate frame
identification and navigation.
- (AERT 12.1.1) HTML 4.0: Check
FRAME
elements for valid "title
"
attributes.
- Suggested Check:
- Element:
FRAME
- Requirement: Must have valid "
title
" attribute .
- Valid "
title
" attribute:
- Suggested Message:
- "Missing title for this frame: [frame file name]."
- Suggested Repair:
- Display the frame content and allow user to enter a new title for the frame.
- Test Files and Discussion Files:
- (WCAG 12.2, P2, Techniques) Describe the purpose of frames and how
frames relate to each other if it is not obvious by frame titles alone.
- HTML 4.0: (OPEN ISSUES: @@ covered by 1.1.8? AND @@Suggest that if the
FRAME
"title"
does not describe the frame that a "longdesc
"
is needed?)
- (WCAG 12.3, P2, Techniques) Divide large blocks of information into
more manageable groups where natural and appropriate.
- HTML 4.0: (OPEN ISSUES: Any suggestions)
- (WCAG 12.4, P2, Techniques) Associate labels explicitly with their
controls.
- (AERT 12.4.1) HTML 4.0: Check
LABEL
elements for valid "for
"
attribute values.
- Suggested Check:
- Elements:
INPUT
and LABEL
- Requirements:
INPUT
elements must have a valid "id
" attribute.
LABEL
elements must have a valid "for
" attribute
that matches the ID of one of the INPUT
elements in the document.
- Suggested Message:
- "This form control is not explicitly labeled: [form control]."
- "This label is not explicitly associated with a form control: [label]."
- Suggested Repair:
- Allow the user to set the "
id
" attribute for each INPUT
element in the document.
- Allow the user to set the "
for
" attribute of each LABEL
element so it matches an INPUT
element.
- (WCAG 13.1, P2, Techniques) Clearly identify the target of each link.
- (AERT 13.1.1) HTML 4.0: Verify that the target of each link is clearly
identified.
- Suggested Check:
- Element:
A
- Requirements:
- Names must be unique for each target.
- Must be meaningful
- Should be terse
- Should not be suspicious (click here, more, follow this, greater than 60 characters)
- Suggested Message:
- "If non-meaningful text found: This link text may not be meaningful when read on
its own: [link text]."
- "If lengthy text found: This link text is quite long and should be shortened: [link
text]."
- Suggested Repair:
-
- Allow user to change the link text and surrounding text.
- Retrieve the
TITLE
of the target page and suggest that as link text.
- If the author is trying to make a Level Triple A site, Ask the author to provide
supplemental information about the link in the "
title
" attribute.
- Resources:
- Harper, S., Stevens, R., and Goble, C. (1999). Towel: Real World Mobility on the Web. In
Vanderdonckt, J. and Puerta, A., eds.: Computer-Aided Design of User Interfaces II.
Dordrecht, Netherlands: Kluwer Academic Publishers.
- (WCAG 13.2, P2, Techniques) Provide metadata to add semantic
information to pages and sites.
- (AERT 13.2.1) HTML 4.0: Check for
META, ADDRESS, TITLE
and LINK
elements.
- Suggested Check:
- Elements:
- Requirements: Must have at least one of these elements in the document.
- Suggested Message:
- "This document does not contain any META information."
- Suggested Repair:
- If no
META, ADDRESS, TITLE
or LINK
elements are found, request
information from the author to be stored as meta information. Examples of content to
prompt for:
- title of the page (required for frames, see checkpoint 12.1),
- type of content,
- descriptions of the content of the page,
- conformance claims,
- author information,
- next page in a series (e.g.,
LINK rel="next"
).
- If a
LINK
element is found, check if it is used for style sheets. If it is,
then proceed as if no LINK
element were found.
- If a
META
element is found, check if it is used to create a redirect. If it
is, then proceed as if no META
element were found (refer also to checkpoints
7.4 and 7.5).
- (AERT 13.2.2) XML: Check for use of RDF. (OPEN ISSUES: @@Similar to
13.2.1, yet might be best in own technique??)
- (WCAG 13.3, P2, Techniques) Provide information about the general
layout of a site (e.g., a site map or table of contents).
- HTML 4.0: @@Machine checkable? Generate user notification?
- (WCAG 13.4, P2, Techniques) Use navigation mechanisms in a
consistent manner.
- HTML 4.0: @@Machine checkable? Generate user notification?
- (WCAG 13.5, P3, Techniques) Use navigation bars to highlight and give
access to the navigation mechanism.
- HTML 4.0: @@Machine checkable? Generate user notification?
- (WCAG 13.6, P3, Techniques) Group related links, identify the group
(for user agents), and, until user agents do so, provide a way to bypass the group.
- HTML 4.0: Verify if links should be grouped. (OPEN ISSUES: WCAG
question: can we suggest that links be grouped by
DIV or SPAN
? AND WCAG
question: is the use of MAP
to group links completely agreed upon?) AND This
suggests another technique that is not widely supported by user agents.)
- Suggested Check:
- Element: Several
A
elements all in one row or column of table and/or
separated only by
- spaces,
- bullets,
BR
elements,
- or a few characters such as "] [" or " | " or
- Requirement: links should be grouped by
SPAN,DIV
or MAP
elements.
- Suggested Message:
- "Groups of links should be grouped with a structural element."
- Suggested Repair:
- Ask the user if an identified list of links should be grouped.
- If the user wants to group the links, use one of the following techniques
- a
MAP
element
SPAN
or DIV
with appropriate "title
"
- Suggest that the user provide a link to bypass the group or that they move the group to
the bottom of the page or that they use a high "
tabindex
" attribute
value.
- (WCAG 13.7, P3, Techniques) If search functions are provided, enable
different types of searches for different skill levels and preferences.
- (AERT 13.7.1) HTML 4.0: Verify that search functions enable a variety of skill
levels and preferences.
- Suggested Check:
- Element:
FORM
- Requirement: Check if a
FORM
is used to submit a search.
- Suggested Message:
- "When providing search functionality, content developers should offer search
mechanisms that satisfy varying skill levels and preferences. Most search facilities
require the user to enter keywords for search terms. Users with spelling disabilities and
users unfamiliar with the language of your site will have a difficult time finding what
they need if the search requires perfect spelling. Search engines might include a spell
checker, offer "best guess" alternatives, query-by-example searches, similarity
searches, etc."
- (WCAG 13.8, P3, Techniques) Place distinguishing information at the
beginning of headings, paragraphs, lists, etc.
- HTML 4.0: @@Machine checkable? Generate user notification?
- (WCAG 13.9, P3, Techniques) Provide information about document
collections (i.e., documents comprising multiple pages.).
- (AERT 13.9.1) HTML 4.0: Verify that information about document collections is
provided. (OPEN ISSUES: Is there a way to use RDF to describe document
collections?)
- Suggested Check:
- Elements: @@?
LINK, A
- Requirement: If the page is part of a collection, such as a slide show, or a chapter in
a book, the previous and next pages ought to be marked as such.
- Suggested Message:
- "Bundled documents can facilitate reading off-line."
- Suggested Repair:
- In HTML/XHTML specify document collections with the
LINK
element and the
"rel
" and "rev
" attributes.
- Suggest that that the author create a collection by building an archive (e.g., with zip,
tar and gzip, stuffit, etc.) of the multiple pages.
- (WCAG 13.10, P3, Techniques) Provide a means to skip over multi-line
ASCII art.
- HTML 4.0: Verify that one can skip over multi-line ASCII art. (OPEN ISSUES: See
1.1.13 for algorithm to find ASCII art)
- Suggested Check:
- Elements:
PRE
and XMP
- Requirements: A link must be provided to skip over ASCII art.
- Suggested Message:
- "A link must be provided to skip over this character based (ASCII art) artwork:
[display artwork]"
- Suggested Repair:
- Allow user to insert a link in the document that skips over the ASCII art.
- Set title of link to "Skip Over ASCII Art" so it can be detected in future.
- (WCAG 14.1, P1, Techniques) Use the clearest and simplest language
appropriate for a site's content.
- HTML 4.0: (@@Check document using fog index? Generate user
notification?)
- (WCAG 14.2, P3, Techniques) Supplement text with graphic or auditory
presentations where they will facilitate comprehension of the page.
- HTML 4.0: (@@Machine checkable? Generate user notification?)
- (WCAG 14.3, P3, Techniques) Create a style of presentation that is
consistent across pages.
- (AERT 14.3.1) HTML 4.0: Verify that a consistent style of presentation is used
across pages. (OPEN ISSUES: @@This requires looking at pages throughout the site.
Need two levels of checking: page vs site?)
- Suggested Check:
- Elements:
STYLE
and LINK
- Requirements:
- The properties of
STYLE
elements should be consistent between pages.
- The names of external style sheets (referenced with
LINK
elements) should
be consistent between pages.
- This should be verified by the author. There are good reasons to use different styles
between pages.
- Suggested Message:
- "Consistent page layout and recognizable graphics benefit all users. In particular,
they help people with cognitive disabilities or who have difficulty reading."
- Suggested Repair:
- If style properties vary between pages, or various external style sheets are used,
suggest the author consolidate style properties into external style sheets and use
consistently.
Suggested:
- Highlight problems detected when documents are opened, when an editing or insertion
action is completed, or while an author is editing. Using CSS classes to indicate
accessibility problems will enable the author to easily configure the presentation of
errors.
- Alert authors to accessibility problems when saving.
- Accessibility problems can be highlighted using strategies similar to spell checking
within a word processor. Accessibility alerts within the document can be linked to context
sensitive help. Refer also to
checkpoint 4.2.
- Where the tools cannot test for accessibility errors, provide the author with the
necessary information, wizards, etc. to check for themselves.
- Include alerts for WCAG 1.0 [WCAG10] Priority 1 checkpoints in the default
configuration.
- Provide an editing view that shows equivalent alternatives in the main content view to
make it clear that they are necessary. This will make it obvious when they are missing.
- Allow authors to choose different alert levels based on the priority of authoring
accessibility recommendations.
- If intrusive warnings are used, provide a means for the author to quickly set the
warning to non-obtrusive to avoid frustration.
Reference:
- There are online tools whose output can be integrated with the user interface. Other
tools are available for incorporation in existing software, either as licensed products or
in some cases as "open source" solutions. The WAI Evaluation and Repair group
maintains information about available tools [WAI-ER].
- The Web Accessibility Initiative's Protocols and Formats group have a draft set of notes
about creating accessible markup languages [XMLGL].
Samples:
- Bobby
[Screenshot needed]
- 4.2 Assist authors in correcting accessibility problems. [Relative Priority] (Checkpoint 4.2)
Suggested:
- At a minimum, provide context-sensitive help with the accessibility checking required by
checkpoint 4.1
- Where there are site-wide errors, to make correction more efficient, allow the author to
make site-wide changes or corrections. For example, this may be appropriate for a common
error in markup, but may not be appropriate in providing a text equivalent that is
appropriate for one use of an image but completely inappropriate for the other uses of the
image on the same site (or even the same page).
- Assist authors in ways that are consistent with the look and feel of the authoring tool
(See ATAG 5.1).
- Allow authors to control both the nature and timing of the correction process.
- Provide a mechanism for authors to navigate sequentially among uncorrected accessibility
errors (See ATAG 7.4).
Samples:
- A-Prompt:
[Screenshot needed]
- 4.3 Allow the author to preserve markup not
recognized by the tool. [Priority 2] (Checkpoint 4.3)
- Note: The author may have included or imported
markup that enhances accessibility but is not recognized by the tool.
Required:
- If possible, preserve all unrecognized markup, since it might be related to
accessibility (See ATAG 1.2).
- If changes to markup that is not recognized by the tool are necessary for the tool to
further process the document (for example, a tool that requires valid markup when a
document is opened), inform the author.
Suggested:
- Provide options for the author to confirm or override removal of markup on a
change-by-change basis or as a batch process.
- Provide a summary of all automated structural changes that may affect accessibility.
- Do not change the DTD without notifying the author.
- 4.4 Provide the author with a summary of the
document's accessibility status. [Priority 3] (Checkpoint 4.4)
Required:
- Provide a list of all accessibility errors found in a Web page.
Suggested:
- Provide a summary of accessibility problems remaining by type and/or by number.
- Lots more to say...
Samples:
- 4.5 Allow the author to transform presentation markup that is misused to
convey structure into structural markup,
and to transform presentation markup used for style into style sheets. [Priority 3] (Checkpoint 4.5)
Required:
- Allow the author to define transformations for imported documents that have
presentation, rather than structural, markup.
- Remember that accessibility information, including attributes or properties of the
elements being transformed, must be preserved - see checkpoint 1.2
Suggested:
- Some examples of transformations include:
- HTML table-based layout into CSS.
- HTML
BR
to the P
element.
- HTML (deprecated)
FONT
into heuristically or author-determined structure.
- Word processor styles to Web styles.
- HTML deprecated presentational markup into CSS.
- XHTML
span
into ruby
.
- MathML presentational markup to semantic markup.
- Implement XSLT [XSLT] together with a user-interface for expressing transformations (see
ATAG 2.1).
- Allow the author to create style rules based on the formatting properties of an element,
and then apply the rule to other elements in the document, to assist conversion of
documents to the use of style sheets
- Include pre-written transformations to rationalize multiple tables, and to transform
(deprecated) presentation HTML into style sheets.
Samples:
- Amaya provides a language for specifying structure transformations, and a large number
of predefined transformations are included.
- ATAG 5.1 Ensure that functionality related to accessible authoring practices is
naturally integrated into the overall look and feel of the tool. [Priority 2]
(Checkpoint 5.1)
Required:
- The accessibility features should be designed as integral components of the authoring
tool application, not plug-ins or other peripheral components that need to be separately
obtained, installed, configured or executed.
- Ensure that author can utilize the tool's accessible authoring features by the same
interaction styles used for other features in the program. For example, if the tool makes
use of onscreen symbols such as underlines or coloration change rather than dialogs for
conveying information, then the same interface techniques should be used to convey
accessibility information.
- The same fonts, text sizes, colors, symbols, etc. that characterize other program
features should also characterize those dealing with accessibility.
- Include considerations for accessibility - such as the
"alt"
and "longdesc"
attributes of the HTML IMG
element - right below the "src"
attribute in a dialogue box, not buried behind an "Advanced..." button.
- The default installation of the authoring tool should include all accessibility features
enabled. The author may have the option to disable these features later on.
Suggested:
- Allow efficient and fast access to accessibility-related settings with as few steps as
possible needed to make any changes that will generate accessible content.
Samples:
- ATAG 5.2 Ensure that accessible authoring practices
supporting Web Content Accessibility Guidelines 1.0 [WCAG10] Priority 1 checkpoints are among the
most obvious and easily initiated by the author. [Priority 2]
(Checkpoint 5.2)
Required:
- If there is more than one option for the author, and one option is more accessible than
another, place the more accessible option first and make it the default. For example, when
the author has selected text to format, the use of CSS should be emphasized rather than
deprecated
FONT
element.
Suggested:
- Highlight the most accessible solutions when presenting choices for the author.
- Provide an editing view that shows equivalent alternatives in the main content view to
make it clear that they are necessary, and will make it obvious when they are missing.
Sample:
- Amaya's user interface guides the author to produce structured content, with
presentation elements separated into style sheets.
[Screenshot needed]
Checkpoints:
- ATAG 6.1 Document all features that promote the
production of accessible content. [Priority 1] (Checkpoint 6.1)
Required:
- Ensure that the help system of the tool can answer the questions: "What features
does this tool have to encourage the production of accessible content?" and "How
are these used?".
Suggested:
- Link from help text to any automated correction utilities.
- Link those mechanisms to identify accessibility problems (i.e., icons, outlining or
other emphasis within the user interface) to help files.
- ATAG 6.2 Ensure that creating accessible
content is a naturally integrated part of the documentation, including examples. [Priority 2] (Checkpoint
6.2)
Required:
- Always include accessibility-related practices in every example for which one would be
required, regardless of whether the example is meant to emphasize this or not (e.g., HTML
IMG
elements should appear with an alt
attribute and a longdesc
attribute wherever appropriate).
- Provide examples of all accessibility solutions in help text, including those of lower
priority in WCAG 1.0 [WCAG10].
Suggested:
- Writing Accessibility Rationale:
- Ensure that documentation examples conform to WCAG 1.0 [WCAG10], at least to the level that the tool
conforms to ATAG 1.0 [ATAG10].
- Explain the importance of utilizing accessibility features generally and for specific
instances.
- Take a broad view of accessibility-related practices. For example, do not refer to text equivalents as being "for blind authors", but rather
as "for authors who are not viewing images".
- Emphasize accessibility features that benefit multiple groups. In particular the
principles of supporting flexible display and control choices have obvious advantages for
the emergence of hands free, eyes-free, voice-activated browsing devices such as Web
phone, the large number of slow Web connections, and Web users who prefer text-only
browsing to avoid "image clutter".
- Explaining Accessibility:
- When explaining the accessibility issues related to non-deprecated elements, emphasize
appropriate solutions rather than explicitly discouraging the use of the element.
- Avoid labeling accessibility features of the tool with a "handicapped" icon,
as this can give the impression that accessible design practices only benefit disabled
authors.
- Context Sensitive Help
- For tools that include context sensitive help, implement context-sensitive help for
accessibility terms as well as tasks related to accessibility.
- Outside Reference:
- Link to or provide URIs for more information on accessible Web authoring, such as WCAG
1.0 [WCAG10], and
other accessibility-related resources.
- Document the tool's conformance to ATAG 1.0 [ATAG10].
- Include current versions of, or links to relevant language specifications in the
documentation. This is particularly relevant for languages that are easily hand edited,
such as most XML languages [XML].
- Tutorials:
- Include a tutorial specifically on checking for and correcting Web accessibility
problems.
- ATAG 6.3
In a dedicated section, document all features of the tool that promote the production of
accessible content. [Priority 3] (Checkpoint
6.3)
Required:
- Ensure that the help system of the tool includes the documentation required by ATAG
6.1 in a dedicated section.
Suggested:
- The dedicated section could be prefaced by an introduction that explains the importance
of accessibility for a wide range of users, from those with disabilities to those with
alternative viewers.
Checkpoints:
- ATAG 7.1 Use all applicable operating system and
accessibility standards and conventions (Priority 1 for standards and conventions that are
essential to accessibility; Priority 2 for those that are important to accessibility;
Priority 3 for those that are beneficial to accessibility). (Checkpoint 7.1)
Requirements:
- The techniques for this checkpoint include references to checklists and guidelines for a
number of platforms and to general guidelines for accessible
applications. This list does not cover all requirements for all platforms, and items may
not apply to some software. In addition, not all of the guidelines and checklists for
application accessibility are prioritized according to their impact on accessibility. For
instance, the priorities in "The Microsoft Windows Guidelines for Accessible Software
Design" [MS-SOFTWARE]
are partially determined by a logo requirement program. Therefore, developers may need to
compare the documents they are using to other UAAG 1.0 [UAAG10] that has a priority system that is
directly compatible with the priorities in [ATAG10]. Also, when user interfaces are built
as Web content, they should follow the Web Content Accessibility Guidelines 1.0 [WCAG10].
- Following Standards
- Draw text and objects using system conventions.
- Make mouse, keyboard, and API activation of events consistent.
- Provide a user interface that is "familiar" (to system standards, or across
platform).
- Use system standard indirections and APIs wherever possible.
- Ensure all dialogs, subwindows, etc., satisfy these requirements.
- Avoid blocking assistive technology functions (sticky/mouse keys, screenreader controls,
etc.) where possible.
- Configurability
- Allow users to create profiles.
- Allow control of timing, colors, sizes, input/output devices and media.
- Allow users to reshape the user interface - customize toolbars, keyboard commands, etc.
- Input Device
Independence
- Provide Keyboard access to all functions.
- Document all keyboard bindings.
- Provide customizable keyboard shortcuts for common functions.
- Provide logical navigation order for the keyboard interface.
- Avoid repetitive keying wherever possible.
- Provide mouse access to functions where possible.
- Icons, Graphics, Sounds
- Provide graphical (text) equivalents for sound warnings.
- Allow sounds to be turned off.
- Provide text equivalents for images/icons.
- Use customizable (or removable) colors/patterns.
- Ensure high contrast is available (as default setting).
- Provide text equivalents for all audio.
- Use icons that are resizable or available in multiple sizes.
- Layout
- Do not rely on color alone for meaning. Use color for differentiation, in combination
with accessible cues (text equivalents, natural language, etc.).
- Position objects and their related text labels in a consistent and obvious manner
(labels before objects is recommended).
- Group related controls.
- Ensure default window sizes fit in screen.
- Allow for window resizing (very small to very large).
- User Focus
- Clearly identify the user focus (and expose it via API).
- Viewing content (i.e., moving the focus to a new point) should not cause unexpected
events.
- Allow user control of timing (i.e., delays, time-dependent response, etc.)
- Allow for navigation between as well as within windows.
- Documentation
- Provide documentation for all features of the tool.
- Ensure that help functions are accessible.
References:
- Guidelines for specific platforms include:
- Java: "IBM Guidelines for Writing Accessible Applications Using
100% Pure Java" [JAVA-ACCESS] R. Schwerdtfeger, IBM
Special Needs Systems.
- X Windows: "An ICE Rendezvous Mechanism for X Window System
Clients" [ICE-RAP],
W. Walker. A description of how to use the ICE and RAP protocols for X Window clients.
- MS Active Accessibility: "Information for Developers About
Microsoft Active Accessibility" [MSAA] Microsoft Corporation.
- X Windows: "The Inter-Client communication conventions
manual" [ICCCM].
A protocol for communication between clients in the X Window system.
- Lotus Notes: "Lotus Notes accessibility guidelines" [NOTES-ACCESS]
IBM Special Needs Systems.
- Java: "Java accessibility guidelines and checklist" [JAVA-CHECKLIST]
IBM Special Needs Systems.
- Java Swing: "The Java Tutorial. Trail: Creating a GUI with
JFC/Swing" [JAVA-TUT].
An online tutorial that describes how to use the Swing Java Foundation Class to build an
accessible User Interface.
- Macintosh: "Macintosh Human Interface Guidelines" [APPLE-HI] Apple
Computer Inc.
- MS Windows: "The Microsoft Windows Guidelines for Accessible
Software Design" [MS-SOFTWARE].
- Guidelines for specific software types include:
- Authoring Tools: "The Three-tions of Accessibility-Aware HTML
Authoring Tools" [ACCESS-AWARE], J. Richards.
- User Agents: "User Agent Accessibility Guidelines (Working
Draft)" J. Gunderson, I. Jacobs eds. (This is a work in progress) [UAAG10]
- General guidelines for producing accessible software include:
- Microsoft: "Accessibility for applications designers" [MS-ENABLE] Microsoft
Corporation.
- Trace: "Application Software Design Guidelines" [TRACE-REF] compiled
by G. Vanderheiden. A thorough reference work.
- Sun: "Designing for Accessibility" [SUN-DESIGN] Eric
Bergman and Earl Johnson. This paper discusses specific disabilities including those
related to hearing, vision, and cognitive function.
- EITAAG: "EITAAC Desktop Software standards" [EITAAC] Electronic
Information Technology Access Advisory (EITACC) Committee.
- US Sept. of Education: "Requirements for Accessible Software
Design" [ED-DEPT]
US Department of Education, version 1.1 March 6, 1997.
- IBM: "Software Accessibility" [IBM-ACCESS] IBM Special Needs Systems
- "Towards Accessible Human-Computer Interaction" [SUN-HCI] Eric Bergman, Earl Johnson, Sun
Microsytems 1995. A substantial paper, with a valuable print bibliography.
- "What is Accessible Software" [WHAT-IS] James W. Thatcher, Ph.D., IBM,
1997. This paper gives a short example-based introduction to the difference between
software that is accessible, and software that can be used by some assistive technologies.
- ATAG 7.2 Allow the author to change the presentation
within editing views without affecting the
document markup. [Priority 1] (Checkpoint 7.2)
Requirements:
- For tools with editing views, the author must have the ability to change the fonts,
colours, sizing, etc. within the editing view, independently of the ability to control the
markup that is actually produced.
- For tools that display the source structure of a document using graphic representations
of tags, provide the author with the option of displaying the text of the elements,
instead (i.e., <title> rather than ).
Suggested:
- An authoring tool that offers a "rendered view" of a document, such as a
browser preview mode, may provide an editing view whose presentation can be controlled
independently of the rendered view.
- A WYSIWYG editor may allow an author to specify a local style sheet, that will override
the "published" style of the document in the editing view.
- Allow the author to create audio style sheets using a graphical representation rather
than an audio one (with accessible representation, of course).
Samples:
- Amaya allows the author to create local style sheets, and to enable or disable each
style sheet that is linked to a document.
[Screenshot needed]
- ATAG 7.3 Allow the author to edit all properties of each element and object in an accessible fashion. [Priority 1] (Checkpoint 7.3)
Required:
- Allow the author to individually edit each attribute of the elements in an HTML or XML
document, for example, through a menu. This must include the ability to add and edit
later, values for all valid attributes.
- For tools that graphically represented element start and end tags, text equivalent must
be provided in order to be accessible to assistive technologies that render text as
Braille, speech, or large print.
Suggested:
- An authoring tool may offer several editing views of the same document, such as a source
mode that allows direct editing of all properties.
- For a site management tool, allow the author to render a site map in text form (i.e., as
a structured tree file).
- Allow the author to specify that alternative information (or identifiers such as a URI
or filename) are rendered in place of images or other multimedia content while editing.
- Include attributes / properties of elements in a view of the structure.
- Provide access to a list of properties via a "context menu" for each element.
Samples:
- Amaya allows each attribute to be edited through the menu or through the structure view.
Element types can be assigned through the menu system.
[Screenshot needed]
- ATAG 7.4 Ensure that the editing view allows navigation via the structure
of the document in an accessible fashion. [Priority 1]
(Checkpoint 7.4)
Required:
- Does not apply to tools that do not have editing views (i.e. format translators).
- To minimally satisfy this checkpoint, allow navigation from element to element.
Suggested:
- Allow the author to navigate via an "outline" or "structure" of the
document being edited. This is particularly important for people who are using a slow
interface such as a small Braille device, or speech output, or a single switch input
device. It is equivalent to the ability provided by a mouse interface to move rapidly
around the document.
- In a hypertext document, allow the author to navigate among links and active elements of
a document.
- For time-based presentations (i.e., SMIL), allow the author to navigate temporally
through the presentation.
- For an image expressed in a structured language (i.e., SVG), allow the author to
navigate regions of the image, or the document tree .
- Implement the HTML
"accesskey"
attribute, and activate it in
editing views.
Sample:
- Amaya provides a structure view, that can be navigated element by element, a Table of
Contents view, that allows navigation via the headings, and a links view, that allows
sequential navigation via the links in the document. It also provides configurable
keyboard navigation of the HTML structure - parent, child, next and previous sibling
elements.
[Screenshot needed]
- ATAG 7.5 Enable editing of the structure of the document
in an accessible fashion. [Priority 2] (Checkpoint 7.5)
Suggested:
- An authoring tool may offer a structured tree view of the document that allows the
author to move among, select and cut, copy or paste elements of the document.
- A WYSIWYG tool may allow elements to be selected, and copied or moved while retaining
their structure.
- A tool may allow transformation from one element type to another, such as
- HTML: Paragraphs to lists and back
- HTML:
BR
to P
- SMIL: Transformations between
switch
, excl
,
and par
- HTML:
FONT
(deprecated) into heuristically determined
structure
- MathML: Transformations between semantic and presentation markup
- SVG:
g
to symbol
- Lists of lists to tables and back
- Giving a structural role to a part of an element, such as an SVG
g
or an
HTML p
element
- 7.6 Allow the author to search within editing views. [Priority 2]
(Checkpoint 7.6)
Required:
- Allow the user to search for a sequence of characters as a minimal measure for meeting
this checkpoint.
Suggested:
- More powerful searches can include the ability to perform searches that are case
sensitive or case-insensitive, the ability to replace a search string, the ability to
repeat a previous search to find the next or previous occurrence, or to select multiple
occurrences with a single search.
- The ability to search for a particular type of structure is useful in a structured
document, structured image such as a complex SVG image, etc.
- In an image editor, the ability to select an area by properties (such as color, or
closeness of color) is useful and common in middle range and high end image processing
software.
- The ability to search a database for particular content, or to search a collection of
files at once (a simple implementation of the latter is the Unix function
"grep") is an important tool in managing large collections, especially those
that are dynamically converted into Web content.
- The use of metadata (per WCAG 1.0 [WCAG10]) can allow for very complex searching
of large collections, or of timed presentations. Refer also to the paper "A
Comparison of Schemas for Dublin Core-based Video Metadata Representation" [SEARCHABLE] for
discussion specifically addressing timed multimedia presentations.
Samples:
- Amaya provides a search function. Because all editing views are synchronized, any search
text found will be selected in each of the available views.
[Screenshot needed]
Instances of the term "prompting"
The ATAG guidelines sometimes refer to the practice of prompting. The importance of
this concept in the document and a perceived ambiguity of its meaning has been identified
as a source of confusion. These techniques will attempt to clarify the issue. Remember
that although the following guidelines and checkpoints make explicit use of the term,
other guidelines may be best implemented using some form of prompting as well.
- GUIDELINE 3:
Support the creation of accessible content.
"... authoring tool developers should attempt to facilitate and automate the
mechanics of [producing equivalent information]. For example, prompting
authors to include equivalent alternative information such as text equivalents, captions,
and auditory descriptions at appropriate times can greatly ease the burden for
authors."
- Checkpoint 3.1: Prompt
the author to provide equivalent alternative information (e.g., captions, auditory
descriptions, and collated text transcripts for video). [Relative Priority]
- Checkpoint 3.4: Do not automatically
generate equivalent alternatives. Do not reuse previously authored alternatives without
author confirmation, except when the function is known with certainty. [Priority 1]
"For example, prompt the author for a text equivalent of an
image..."
- Checkpoint 4.1: (Check for and
inform the author of accessibility problems. [Relative Priority]
"Note: Accessibility problems should be detected automatically where possible. Where
this is not possible, the tool may need to prompt the author to make
decisions or to manually check for certain types of problems."
The term "prompting" is used in the document to denote all user interface
methods by which the author is given an opportunity to add accessible content. Developers
are often concerned that prompting requires them change their products in ways that their
users will not accept. To address these concerns the following statements should make
clear, what prompting is not:
- There is no requirement that prompting be modal. In other words, the
author should not necessarily be prevented from performing other tasks when accessibility
problems exist.
- There is no requirement that prompting be implemented with a one prompt
per accessibility issue system. In other words, the author may be presented with a number
of issues within one prompt, only one or several of which may relate to accessibility.
- There is no requirement that prompting be inflexible. A user-flexible
schedule should be an important component of the system. The degree of flexibility should
be determined by the nature of the tool.
- There is no requirement that prompting change the fundamental look and
feel of a tool. In fact, as a general rule, the implementation of prompting should be
governed by checkpoint 5.1 (Ensure
that functionality related to accessible authoring practices is naturally integrated into
the overall look and feel of the tool. [Priority 2])
Authoring tool support for the creation of accessible Web content should account for
different authoring styles. When authors are able to configure the tool's accessibility
features to support their regular work patterns, they will be more likely to accept
accessible authoring practices (ATAG Checkpoint 5.1).
For example, some authors may prefer to be alerted to accessibility problems when they
occur, whereas others may prefer to perform a check at the end of an editing session. This
is analogous to programming environments that allow users to decide whether to check for
correct code during editing or at compilation.
A user configurable schedule allows individual authors to determine how and when they
will be prompted about accessibility issues. For example, authors should have control over
the stringency of the checks (i.e. WCAG conformance level) and the scheduling of prompting
(i.e. as problems occur, following saves, or prior to Web publishing). Of course, the
extent of this configurability should be appropriate to each tool, as determined by the
developer. Some tool developers may decide to restrict authors to several global settings,
while others might allow authors to make fine grained distinctions, such as different
scheduling for different types of problems. For example, in Microsoft Word 2000, spelling
errors can be flagged and corrected in several ways depending on the preferences that the
author has set on the "Spelling & Grammar" property card (Figure A-1).
All authoring tools will have ways of conveying information to users and collecting
information in return. These methods vary according to the design of the tool and the user
interface conventions for the platform upon which it is implemented. For the sake of this
document we have attempted to divide the methods roughly between prompts and alerts. The
following is relatively generic overview of how these methods can be used for
accessibility prompting. Keep in mind that these categories may overlap. For example, an
intrusive alert may contain a prompt edit field.
Prompts are interface mechanisms that request information from the user, or at least
provide an opportunity for user to provide information if they wish. On most GUI
platforms, prompts commonly take the form of dialog box controls. The author answers the
requests by modifying the states of the controls (i.e. typing text in a textbox or
selecting a checkbox).
A prompt can be viewed as either intrusive or unintrusive depending on whether the user
has requested that it be displayed or not. For example, when the author activates the
"Save As..." menu item, an unintrusive dialog is typically displayed to prompt
the user for a file name and location. On the other hand, if the user presses activates
the "Save" command and the program detects a problem (ex. saving to a media that
has been removed), an intrusive dialog is usually displayed prompting the user to replace
the media or select a new saving location.
The main drawback of using unintrusive prompts for ensuring accessible authoring is
that once the author has dismissed the prompt, its message is unavailable unless the user
requests it again. This may be avoided by the use of intrusive prompts, however,
displaying too many of these can quickly annoy the author and one of the goals of this
document is to suggest techniques for implementing ATAG that preserve author cooperation.
Therefore, when implementing the ATAG, unintrusive prompts are recommended to encourage
authors to provide information required for accessibility when the user inserts or
inspects an element. For example, in the case of HTML, a prominently displayed alt-text
entry field in an image insertion dialog, would constitute a prompt (Figure A-3).
In ATAG, the interface priority of controls related to accessibility is governed by ATAG checkpoint 5.2 (Ensure that accessible
authoring practices supporting Web Content Accessibility Guidelines 1.0 [WCAG10] Priority
1 checkpoints are among the most obvious and easily initiated by the author. [Priority
2]). This checkpoint does not require that accessibility concerns obscure
the other editing tasks. The checkpoint merely emphasizes that these controls should be
allotted screen presence that is appropriate for their importance. For example, in
Macromedia's Dreamweaver 2 HTML authoring tool, a property toolbar is displayed with
fields that are appropriate to the currently selected element. In some cases, including
the image element, the author can toggle the toolbar between a limited and extended set of
properties. Due to the importance of the alt
attribute, it is recommended
that the edit field for this property be available in the limited set. In the case of
Dreamweaver, this is precisely what has been done (Figure A-2).
Conformance with checkpoint 5.2 may
be reinforced by visually highlighting accessibility features with colour, icons,
underlining, etc. For example, in Allaire's HomeSite authoring tool, attention is drawn
more explicitly to accessibility-related prompt fields. In this case, the HomeSite tag
editor dialog contains symbols, colour changes and explanatory text that highlight the
alt-text field and remind the author that it is required for HTML 4.0 and necessary for
accessibility.
Sometimes several editing tasks are required to make a single element accessible.
Instead of dispersing these prompts over multiple dialog boxes, it may be more effective
to draw them together into one group of controls. In the following example from Allaire
HomeSite, the prompt fields pertaining to multiple accessibility requirements of the HTML
input form control (i.e. Access Key, Tab Index, Title and Label Text) are organized into
the same dialog box.
In cases where there are many pieces of information required, authors may benefit from
a sequential presentation of prompts. This technique usually takes the form of a wizard or
a checker. In the case of a wizard, complex interactions are broken down into a series of
simple steps. The later steps can then be updated on the fly to take into account
information provided by the user in earlier steps. A checker is a special case of a wizard
in which the number of detected errors determines the number of steps. For example,
Microsoft Word 2000 has a checker that displays all the spelling and grammar problems one
at a time (Figure A-5). Notice how all the problems are displayed in a standard way: type
of problem (i.e. "not in dictionary"), the problem instance (i.e. "There
are a few spellling mistakes") and suggested fixes (i.e. a list of suggested correct
words). The user also has several correcting options, some of which can store responses to
affect how the same situation is handled later.
In an accessibility checker, the same is true, however the dialog template has to be
somewhat more flexible since the problems can range from a missing text string for a
multimedia object to missing structural information for a table to improper use of colour.
In the following example, from A-Prompt, the author is prompted to add alternate text for
an image as part of a correction run. Notice that, like the spell checker, the prompt
includes a statement of the problem (i.e. "missing alternate text for an
image"), the problem instance (i.e. earthrise.gif), and suggested fixes (i.e. a
suggestion from the alt-text registry, "An earth-rise as seen from the surface of the
moon"). In addition, the dialog also has some instructive text to aid the author in
writing text if necessary.
Alerts warn the author that there are problems that need to be addressed. Since
addressing these problems usually requires adding information, it may be argued that the
distinction between an alert (warning) and a prompt (information request) is confusing.
For the purpose of this document, an alert is essentially a warning without an immediate
means (i.e. a text box) for adding the missing information (although a well-designed
warning should link intuitively to a prompt wherever possible), whereas a prompt is an
opportunity to add missing information that may or may not include a warning. Still
confused? Fortunately, in general, it doesn't really matter as long as the tool succeeds
in convincing authors to add the required information at some point before Web publishing
occurs.
Note: The method by which a tool attracts the author's attention is a
tricky issue because it can influence the author's view of the tool and even their opinion
of accessible authoring as a whole. That's why the ATAG includes checkpoint 5.1
(Integrate accessibility solutions into the overall "look and feel" [Priority
2]).
Intrusive alerts are informative messages that interrupt the editing process for the
author. For example, intrusive alerts are often presented when an author's action could
cause a loss of data. Intrusive alerts allow problems to be brought to the author's
attention immediately. However, authors may resent the constant delays and forced actions.
Many people prefer to finish expressing an idea before returning to edit its format.
If the tool developer chooses to use intrusive alerts for some or all of the alerts,
the simplest implementation might to present the author with a single option that channels
them to a prompt where they may or may not be forced to enter the missing information.
This is not a recommended strategy. Instead, the alert should include two or more options
that linking to a prompt for correcting the problem, an option to return directly to
editing and perhaps even a link to relevant help (Figure A-7). In addition, the author may
be presented with an option to prevent similar intrusive warnings in the future.
Although intrusive alerts are the least user-friendly form of prompting, there are some
situations in which they may become necessary. For example, when the editing process is
complete and publishing to the Web appears imminent, unintrusive alerts are not an option
since there is simply no editing process left. This may always be the case when a document
composed in a proprietary (non-Web format) is being converted to a Web format for
publishing. This does not mean that unintrusive alerts are not also possible in these
situations. For example, an alert might be added directly to the "Save" dialog
(Figure A-8).
Unintrusive alerts are interface methods such as icons, underlines, and gentle sounds
that can be presented to the author without requiring immediate action. For example, in
some authoring tools misspelled text is highlighted within the document, identifying the
location of problems without forcing the author to make corrections immediately. As an
example, Microsoft Word 2000 includes the option to underline spelling errors (Figure A-9)
in red and grammatical errors in green (for author accessibility the user must be able to
change the default presentation - users who are red-green colorblind, for example, will
not be able to perceive the information being conveyed by red and green underlines). When
the user right-clicks on the highlighted text, they are presented with several correction
options.
Another Microsoft product, FrontPage 2000, uses unintrusive alerts in its HTML editing
environment to indicate syntax errors. As the author types, the syntax is automatically
checked (Figure A-10). The system is unintrusive because the author is allowed to make as
many syntax errors as they like, but the colour of the text signals that one or more
errors have been made.
In the context of the Authoring Tool guidelines, these unintrusive alert techniques
could be used to indicate which parts of a document or site contain accessibility
problems. This will inform the author about the type and number of errors without
interrupting their editing process. Of course, these are just two examples of the
techniques that developers might choose. Other implementations might include in-line icons
as the BOBBY evaluation tool does or even accessibility problem density displays for power
users.
The downside of unintrusive alerts is that the author may choose to ignore the alerts
completely. Therefore, the optimum strategy might be to emphasize unintrusive solutions
until a critical point (i.e. publishing) at which time an effective intrusive alert, such
as a problem summary, can be displayed.