NOTES ABOUT THIS DRAFT:
- Intro, references, etc. have been removed fro 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 techs - 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.).
- 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.
- 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:
- 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:
- 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.
- 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:
- HTML 4.0: Check
OBJECT
elements of type="image_MIME_types"
for valid text equivalents and descriptions (where necessary)
- Open issues for this technique:
- This only covers text equivalents. Where is non-text covered if not here?
- 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:
- 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:
- 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.
- 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:
- 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:
- 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:
- 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?
- HTML 4.0: Verify that valid text equivalents are provided for
PRE
and XMP
elements used to create ASCII art.
- Open issues for this technique:
- A-Prompt has been using an algorithm to detect ASCII art (There must be 5 or more lines
of text and there must be 5 or more same characters in a sequence). This works quite well
but detects things such as code samples (don't require text equiv.) and guitar tabulature
(do require text equiv.) Should we suggest this algorithm in the evaluation?
- What about ASCII art that is interspersed in text, such as in
P
elements?
- Bill Shackleton suggested that a tool use a library of well-known ascii art to detect
some ascii art such as emoticons. Yahoo maintains
a list of ascii art one list is specifically about smileys.
- 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.
- HTML 4.0: Verify that a server-side image map has associated text links.
- Open issues for this technique:
- WCAG issue: text links are a priority 3 if the same image also has a client side map
(images can have both a client-side and a server-side).
- 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.
- 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)
- 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)
- SMIL: Check SMIL files for synchronized media
- Open issues for this technique:
- This technique is a specific example of 1.4.1. Should it stand on its own or be
incorporated into 1.4.1?
- This technique is also SMIL specific while the majority of techniques are HTML specific.
Should we include a SMIL specific technique?
- 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.
- 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.
- (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.
- (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.
- (WCAG 3.4, P2, Techniques) Use relative rather than absolute units for
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.
- (WCAG 3.6, P2, Techniques) Mark up for lists and list items properly.
- (WCAG 3.7, P2, Techniques) Mark up 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.
- Where there is a change in the writing script used, prompt the author to identify
whether there has been a change in language
- (WCAG 4.2, P3, Techniques) Specify the expansion of each abbreviation
or acronym in a document where it first occurs.
- (WCAG 4.3, P3, Techniques) Identify the primary natural language of a
document.
- (WCAG 5.1, P1, Techniques) For data tables, identify row and column
headers.
- (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.
- (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).
- (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.
- (WCAG 5.6, P3, Techniques) Provide abbreviations for header labels of
tables.
- (WCAG 6.1, P1, Techniques) Organize documents so they may be read
without style sheets.
- (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.4, P2, Techniques) For scripts and applets, ensure that event
handlers are input device-independent.
- (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 causing movement.
- (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 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.
- (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.
- (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.
- (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.
- (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.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.
- (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 10.5, P3, Techniques) Until user agents render adjacent links
distinctly, include non-link, printable characters (surrounded by spaces) between adjacent
links.
- (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.
- (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 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 12.3, P2, Techniques) Divide large blocks of information into
more manageable groups where natural and appropriate.
- (WCAG 12.4, P2, Techniques) Associate labels explicitly with their
controls.
- (WCAG 13.1, P2, Techniques) Clearly identify the target of each link.
- (WCAG 13.2, P2, Techniques) Provide metadata to add semantic
information to pages and sites.
- (WCAG 13.3, P2, Techniques) Provide information about the general
layout of a site (e.g., a site map or table of contents).
- (WCAG 13.4, P2, Techniques) Use navigation mechanisms in a
consistent manner.
- (WCAG 13.5, P3, Techniques) Use navigation bars to highlight and give
access to the navigation mechanism.
- (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.
- (WCAG 13.7, P3, Techniques) If search functions are provided, 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.
- (WCAG 13.9, P3, Techniques) Provide information about document
collections (i.e., documents comprising multiple pages.).
- (WCAG 13.10, P3, Techniques) Provide a means to skip over multi-line
ASCII art.
- (WCAG 14.1, P1, Techniques) Use the clearest and simplest language
appropriate for a site's content.
- (WCAG 14.2, P3, Techniques) Supplement text with graphic or auditory
presentations where they will facilitate comprehension of the page.
- (WCAG 14.3, P3, Techniques) Create a style of presentation that is
consistent across pages.
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 interruptive 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]
The ATAG guidelines often refer to the practice of prompting. The importance of these
concepts in the document and a perceived ambiguity of their meanings has been identified
as a source of confusion. These techniques will attempt to clarify the issue. Although the
following guidelines and checkpoints make explicit use of them, others may refer to
prompting implicitly :
- 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. The
following are responses to concerns raised by developers.
- 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 dedicated to one
accessibility issue. 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.
Important: 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])
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.
Authoring tool support for the creation of accessible Web content should account for
different authoring styles. Authors who can configure the tool's accessibility features to
support their regular work patterns are more likely to accept accessible authoring
practices (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.
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 property card. View screenshot.
All authoring tools will have ways of conveying information to users and collecting
information in return. These methods vary according to factors such as the design of the
tool and the user interface conventions for its platform. 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 basically requests for information. On most GUI platforms, prompts take the
form of dialog boxes that request information from the user.The author answers the
requests by setting modifying control values (i.e. typing text in a textbox or selecting a
checkbox). Prompts are relatively unintrusive because they are often displayed at the
user's request. For example, when the user has chosen to save a document and the
application prompts for the user to enter a name. However, once the author has dismissed a
prompt, its message is unavailable unless the user requests it again.
For the purposes of the Guidelines, prompts can be used to encourage authors to provide
information required for accessibility. For example, in the case of HTML, a prominently
displayed alt-text entry field in an image insertion dialog, would constitute a prompt.
In the Guidelines, the interface priority of controls related to accessibility is
governed by 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 cases such as the image
element, the author can toggle the toolbar between a limited and extended set of
properties. Importantly, in terms of checkpoint
5.2, the alt
attribute property is afforded sufficient field priority to
appear on the limited version of the toolbar.
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 an accessibility-related prompt fields. In this case, the Homesite tag
editor dialog contains symbols, colour changes and explanatory text highlight alt-text as
required for HTML 4.0 and necessary for accessibility.
Sometimes a number of accessible editing tasks are required for a single element.
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, also from
Allaire HomeSite, the multiple accessibility requirements of the HTML input form control
(i.e. Access Key, Tab Index, Title and Label Text) are prompted for from within the same
dialog.
In some cases, authors may benefit from the sequential presentation of a number of
prompts. This technique usually takes the form of a wizard or a checker. In the case of a
wizard, relatively complex interactions are broken down into a number of simple steps so
that later steps can 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.
The first example is a spelling and grammar checker from Microsoft Word 2000. 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 spelling
mistakes") and suggested fixes (i.e. a list of suggested correct words). The user
also has a number of 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 (8 of 20) 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. The art of
attracting the author's attention is a tricky issue. The way authors are alerted,
prompted, or warned can influence their view of the tool and even their opinion of
accessible authoring. 5 Integrate
accessibility solutions into the overall "look and feel". .
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. The
following screenshot shows an example of an intrusive alert that might be displayed if the
author fails to enter Alt-text at an image insertion prompt.
When the author dismisses an intrusive alert, the program may or may not display a
prompt allowing the author make the appropriate action.
Note: While intrusive alerts are the least user-friendly form of
prompting, there are situations in which the editing process is complete and publishing to
the Web appears imminent. This may be the case when a document composed in a proprietary
(non-Web format) is saved out into Web format. In these cases, unintrusive alerts are not
an option since there is simply no editing process left. An alternative to a number of
alerts might be a number of sequential prompts (i.e. wizard) that could take the user
through a process by which the inaccessible proprietary document is converted into an
accessible Web document.
Unintrusive alerts are interface objects such as icons, underlines, and gentle sounds
that can be presented to the author without requiring immediate action. For example, in
some word processors misspelled text is highlighted in the text, without forcing the
author to make the correction immediately. These alerts allow authors to continue editing
with the knowledge that problems will be easy to identify at a later time. However,
authors may choose to ignore the alerts altogether. As an example, Microsoft Word 2000
includes the option to underline spelling errors in red and grammatical errors in green.
(Note that a user must be able to change this default presentation - users who are
red-green colorblind, for example, will not be able to perceive the information being
conveyed by this default). 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. The author is allowed to make syntax errors, but the colour of the text signals
that an error has been made.
In the context of the Authoring Tool guidelines, such 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.
Example Screenshots: