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 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:
- 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:
- 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)
Required by 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 (ATAG 3.4, P1). 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 - 3.7) Covered by ATAG 3.2.
- (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).
- (WCAG 13.4, P2, Techniques) Generate navigation mechanisms in a consistent
manner.
- (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.
Suggested:
- 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.1-13.10, P1-3]
- Produce accessible representations for site maps generated by the authoring tool.
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)
Required by 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 - 3.7) Covered by ATAG 3.2.
- (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.
- Other stuff...
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. For example, when creating mathematical content for the Web use
MathML [MATHML]
rather than another markup language. Use applicable HTML 4 [HTML4] structures (WCAG
11.1, P2).
- 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.
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 where there are multiple versions):
- 2.2 Ensure that the tool automatically
generates valid markup. [Priority 1] (Checkpoint 2.2)
Required:
- Produce valid HTML/XML.
- 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)
Suggested:
- Invalid markup can be highlighted through the use of style sheets.
- A tool that provides a Web editing mode and a non-Web editing mode can change modes when
invalid markup is introduced. [Crossover: ATAG 4.1]
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)
Required by 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.
- 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].
- (WCAG 1.2, P1, Techniques) Provide redundant text links for each active region of a server-side image
map.
- 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.
- (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.
- 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.2 - 13.10, 14.1 - 14.3.
Required:
- 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). (WCAG 1.1, P1)
- When video is inserted, prompt the author for a still image as part of the alternative
information. (WCAG 1.1, P1)
- Provide an author with the option of specifying alternative information, or electing to
insert null alternative information for images, audio, video. Default to an accessibility
error such as no
TITLE
or DESC
element for SVG images. Prompt
the author to identify the type of image (decorative, a navigation icon, etc.). (WCAG x.y,
Pz)
- 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.
(WCAG x.y, Pz)
Suggested:
- 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.
- For image maps, prompt for text which describes the range and the
effect of possible coordinate entries, and generate an alternative,
form-based entry system.
- Satisfying checkpoint 3.5 would
provide much of the required functionality for images.
- Identify the natural language of text equivalents. (WCAG 4.1, P1)
-
Reference:
- For more information on prompting, see Appendix A.
- 3.2 Help the author create structured
content and separate information from its presentation. [Relative Priority]
(Checkpoint
3.2)
Required by 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 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.
- Prompt the author to identify the structural role of content that has been emphasized
through styling.
- (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.
- (WCAG 3.6, P2, Techniques) Mark up lists and list items properly.
- 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.
- (WCAG 3.7, P2, Techniques) Mark up quotations. Do not use quotation markup for formatting effects such as indentation.
- (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.
- (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).
- (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 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 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.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 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.4, P2, Techniques) Associate labels explicitly with their
controls.
- (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.
- Not applicable: WCAG 2.2, 5.5, 5.6, 8.1, 9.1, 9.5,
10.1 - 10.5, 11.1, 11.4, 12.1 - 12.3, 13-1 - 13.5, 13.7 - 13.10, 14.1 -
14.3.
-
Required:
-
Suggested:
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:
- WCAG
Checkpoint 2.1 Ensure that all information conveyed with color is also
available without color, for example from context or markup. [Priority 1]
- Techniques for WCAG checkpoint
2.1
- General
-
- WCAG
Checkpoint 2.2 Ensure that foreground and background color combinations provide
sufficient contrast when viewed by someone having color deficits or when viewed on a black
and white screen. [Priority 2 for images, Priority 3 for text].
- Techniques for WCAG
checkpoint 2.2
- General
- Provide a monochrome preview for the author to test themselves.
- WCAG
Checkpoint 3.1 When an appropriate markup language exists, use markup rather
than images to convey information. [Priority 2]
- Refer also to WCAG guideline 6 and WCAG
guideline 11.
- Techniques for WCAG checkpoint
3.1
- General
- Refer also to checkpoint 2.1.
- For mathematical content use MathML [MATHML], TeX or LaTeX.
- For tabular data (for example timetables) use an HTML
table
, or XML.
- In some cases it is helpful to include a graphic form as well as a markup-based form.
For example, a graph may be presented along with the XML source data used to generate it.
Or it may be an SVG image [SVG]
which contains the source data within the SVG file, as RDF [[RDF]].
- WCAG
Checkpoint 3.3 Use style sheets to control layout and presentation. [Priority 2]
- Techniques for WCAG checkpoint
3.3
- Text / hypertext
- Recognize formatting patterns and convert them to style rules.
- Provide a view which allows the author to edit the layout and styling effects
independently of the text content.
- WCAG
Checkpoint 3.5 Use header elements to convey document structure and use them
according to specification. [Priority 2]
- Techniques for WCAG
checkpoint 3.5
- Text / hypertext
- Prompt the author to identify headings and subheadings
- Provide an "outline" or "structure" view which allows the author to
easily grasp the heading structure, and edit it.
- WCAG
Checkpoint 3.6 Mark up lists and list items properly. [Priority 2]
- Techniques for WCAG
checkpoint 3.6
- text / hypertext
- Include lists (marked as lists) in a collapsible structure view
- WCAG Checkpoint 3.7
Mark up quotations. Do not use quotation markup for formatting effects such as
indentation. [Priority 2]
- Techniques
for WCAG checkpoint 3.7
- HTML
- Automatically include (configurable or localized) quotation marks around quotations.
This will encourage authors to use the markup, and not to misuse it.
- Where material appears within quote marks ask the author if this is a quotation.
- WCAG
Checkpoint 4.1 Clearly identify changes in the natural language of a document's
text and any text equivalents
(e.g., captions). [Priority 1]
- Techniques for WCAG
checkpoint 4.1
- Text / hypertext
- Use a dictionary lookup to recognize words, and changes in the natural language used.
- Provide an option in spellcheckers to identify a word or phrase that is not
recognized as being in a natural language other than the primary language of the document.
- WCAG
Checkpoint 4.2 Specify the expansion of each abbreviation or acronym in a
document where it first occurs. [Priority 3]
- Techniques for WCAG checkpoint
4.2
- HTML
- Ask the author to provide an expansion for
abbr
and acronym
elements or confirm that a previously supplied one should be used again.
- General
- Provide a dictionary mechanism that recognizes abbreviations and prompts the author to
include appropriate markup.
- WCAG
Checkpoint 4.3 Identify the primary natural language of a document. [Priority 3]
- Techniques for WCAG
checkpoint 4.3
- General:
- Ask the author to identify the language of any document. Provide a mechanism for setting
a default.
- For data tables, identify row and column headers. [Priority 1]
- Techniques for WCAG
checkpoint 5.1
- WCAG
Checkpoint 5.2 For data tables that have two or more logical levels of row or
column headers, use markup to associate data cells and header cells. [Priority 1]
- For example, in HTML, use THEAD, TFOOT, and TBODY to group rows, COL and COLGROUP to
group columns, and the "axis", "scope", and "headers"
attributes, to describe more complex relationships among data.
- Techniques for WCAG
checkpoint 5.2
- HTML
- Ask the author to group columns, rows, or blocks of cells that are related.
- WCAG Checkpoint 5.3 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).
[Priority 2]
- Refer also to WCAG checkpoint 3.3.
- Techniques for WCAG
checkpoint 5.3
- HTML
- Prompt the author to identify tables which are used as layout devices.
- For layout tables, provide a linearized version, and offer it as a link from the table
or as a replacement. An example tool which linearizes tables is tablin. It is also
possible to provide a link direct to tablin [[TABLIN]].
- WCAG
Checkpoint 5.4 If a table is used for layout, do not use any structural markup
for the purpose of visual formatting. [Priority 2]
- Techniques for WCAG checkpoint
5.4
- WCAG
Checkpoint 5.5 Provide summaries for tables. [Priority 3]
- Techniques for WCAG
checkpoint 5.5
- HTML
- In a table creation wizard, include a summary or caption dialog
- Render the
caption
, title
and summary
of a table,
or prompt for content.
- Amaya's user
interface guides the author to include a caption for tables, in the following way: 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. (This is a standard part of the Amaya user interface).
- WCAG
Checkpoint 5.6 Provide abbreviations for header labels. [Priority 3]
- Techniques for WCAG
checkpoint 5.6
- HTML
- Prompt for an abbreviated form of each table header (
th
)
- WCAG
Checkpoint 6.1 Organize documents so they may be read without style sheets. For
example, when an HTML document is rendered without associated style sheets, it must still
be possible to read the document. [Priority 1]
- Techniques for WCAG
checkpoint 6.1
- HTML
- Provide a "draft" view which does not apply styling.
- WCAG
Checkpoint 6.2 Ensure that equivalents for dynamic content are updated when the
dynamic content changes. [Priority 1]
- Techniques for WCAG
checkpoint 6.2
- SVG
- Prompt for appropriate changes to
title
and desc
elements
which are children of the target of an animate.
- HTML
- See also frames.
- WCAG Checkpoint 6.3
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. [Priority 1]
- Refer also to WCAG guideline 1.
- Techniques for WCAG checkpoint 6.3
- HTML
- Prompt for server-side alternatives for scripts and applets
- Prompt for
noscript
content for each script
.
- Prompt for alternative content for applets and programmatic objects (for example
object
elements which have a code
attribute).
- WCAG Checkpoint 6.4 For scripts and
applets, ensure that event handlers are input device-independent. [Priority 2]
- Refer to the definition of device
independence.
- Techniques for
WCAG checkpoint 6.4
- Applet development
- Prompt the author to include device-independent means of activation
- WCAG
Checkpoint 6.5 Ensure that dynamic content is accessible or provide an
alternative presentation or page. [Priority 2]
- Techniques for WCAG
checkpoint 6.5
- HTML
- Ask the author for:
- appropriate links and content to include in a
noframes
element
- a server-side alternative to applets and script functions
- WCAG
Checkpoint 7.1 Until user agents
allow users to control flickering, avoid causing the screen to flicker. [Priority 1]
- Techniques for WCAG
checkpoint 7.1
- WCAG
Checkpoint 7.2 Until user agents
allow users to control blinking, avoid causing content to blink (i.e., change presentation
at a regular rate, such as turning on and off). [Priority 2]
- Techniques for WCAG
checkpoint 7.2
- WCAG
Checkpoint 7.3 Until user agents
allow users to freeze moving content, avoid movement in pages. [Priority 2]
- Refer also to WCAG guideline 8.
- Techniques for WCAG
checkpoint 7.3
- WCAG
Checkpoint 7.5 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. [Priority 2]
- Techniques for WCAG
checkpoint 7.5
- WCAG Checkpoint 8.1 Make programmatic elements
such as scripts and applets directly accessible or compatible with assistive technologies
[Priority 1 if functionality is important and not
presented elsewhere, otherwise Priority 2.]
- Refer also to WCAG guideline 6.
- Techniques for WCAG
checkpoint 8.1
- WCAG
Checkpoint 9.1 Provide client-side image maps instead of server-side image maps
except where the regions cannot be defined with an available geometric shape. [Priority 1]
- Refer also to WCAG checkpoint 1.1, WCAG checkpoint 1.2, and WCAG checkpoint 1.5.
- Techniques for WCAG
checkpoint 9.1
- HTML
- 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, on a map the input might be used to lookup latitude and longitude of a
point and then give information about that point.
- WCAG
Checkpoint 9.2 Ensure that any element that has its own interface can be
operated in a device-independent manner. [Priority 2]
- Refer also to WCAG guideline 8.
- Techniques for WCAG
checkpoint 9.2
- WCAG Checkpoint 9.3 For scripts, specify
logical event handlers rather than device-dependent event handlers. [Priority 2]
- Techniques for
WCAG checkpoint 9.3
- WCAG Checkpoint
9.4 Create a logical tab order through links, form controls, and objects. [Priority 3]
- Techniques for WCAG checkpoint
9.4
- HTML
- 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
Checkpoint 9.5 Provide keyboard shortcuts to important links (including those
in client-side image
maps), form controls, and groups of form controls. [Priority 3]
- Techniques for WCAG
checkpoint 9.5
- HTML
- Ask authors to specify an accesskey for links that appear common to a number of pages
- WCAG
Checkpoint 10.1 Until user agents
allow users to turn off spawned windows, do not cause pop-ups or other windows to appear
and do not change the current window without informing the user. [Priority 2]
- Techniques for WCAG
checkpoint 10.1
- HTML
- Where a link or active element will spawn a new window, prompt the author for
title
text to make this clear.
- WCAG Checkpoint 10.2 Until user agents
support explicit associations between labels and form controls, for all form controls with
implicitly associated labels, ensure that the label is properly positioned. [Priority 2]
- Refer also to WCAG checkpoint 12.4.
- Techniques for WCAG
checkpoint 10.2
- WCAG
Checkpoint 10.4 Until user agents
handle empty controls correctly, include default, place-holding characters in edit boxes
and text areas. [Priority 3]
- Techniques for WCAG
checkpoint 10.4
- HTML
- Prompt the author for default place-holder text. Offer the value of the
name
attribute as a default.
- WCAG
Checkpoint 10.5 Until user agents
(including assistive technologies) render adjacent links distinctly, include non-link,
printable characters (surrounded by spaces) between adjacent links. [Priority 3]
- Techniques for WCAG checkpoint
10.5
- WCAG
Checkpoint 11.2 Avoid deprecated features of W3C technologies. [Priority 2]
- Techniques for WCAG
checkpoint 11.2
- WCAG Checkpoint 11.3 Provide information so
that users may receive documents according to their preferences (e.g., language, content
type, etc.) [Priority 3]
- Note. Use content negotiation where possible.
- Techniques for WCAG
checkpoint 11.3
- WCAG Checkpoint
11.4 If, after best efforts,
you cannot create an accessible page, provide a link to an alternative page
that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated
as often as the inaccessible (original) page. [Priority 1]
- Techniques for WCAG checkpoint
11.4
- WCAG
Checkpoint 12.1 Title each frame to facilitate frame identification and
navigation. [Priority 1]
- Techniques
for WCAG checkpoint 12.1
- HTML
- Prompt the author for a short, human-readable title for each frame. Default text
presented in the prompt could use the
title
defined for the document
referenced in the src
- WCAG
Checkpoint 12.2 Describe the purpose of frames and how frames relate to each
other if it is not obvious by frame titles alone. [Priority 2]
- Techniques for WCAG
checkpoint 12.2
- HTML
- 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
Checkpoint 12.3 Divide large blocks of information into more manageable groups
where natural and appropriate. [Priority 2]
- Refer also to WCAG guideline 3.
- Techniques for WCAG
checkpoint 12.3
- HTML
- Where there are more than 10 choices in a list (
select
, checkbox
or radio
boxes) ask the author to identify subgroups
- WCAG
Checkpoint 12.4 Associate labels explicitly with their controls. [Priority 2]
- Techniques for WCAG
checkpoint 12.4
- HTML
- Ask authors to mark explicitly the labels for form inputs (
input
and textarea
elements)
- WCAG
Checkpoint 13.1 Clearly identify the target of each link. [Priority 2]
- Techniques for WCAG
checkpoint 13.1
- General
- Prompt the author to provide text which can be used as a title for a link.
- WCAG
Checkpoint 13.2 Provide metadata to add semantic information to pages and
sites. [Priority 2]
- Refer
also to WCAG checkpoint 13.5.
- Techniques for WCAG checkpoint
13.2
- General
- 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
Checkpoint 13.3 Provide information about the general layout of a site (e.g., a
site map or table of contents). [Priority 2]
- Techniques for WCAG
checkpoint 13.3
- General
- Prompt the author to provide a link or content describing the structure of the site, and
its accessibility features.
- WCAG Checkpoint 13.4 Use navigation mechanisms
in a consistent manner. [Priority 2]
- Techniques for WCAG
checkpoint 13.4
- WCAG Checkpoint 13.5
Provide navigation bars to highlight and give access to the navigation mechanism. [Priority 3]
- Techniques for WCAG checkpoint 13.5
- WCAG
Checkpoint 13.6 Group related links, identify the group (for user agents), and,
until user agents
do so, provide a way to bypass the group. [Priority 3]
- Techniques for WCAG checkpoint
13.6
- HTML
- Ask authors if lists of links are a group and should be a map.
- WCAG
Checkpoint 13.9 Provide information about document collections (i.e., documents
comprising multiple pages.). [Priority 3]
- Techniques for WCAG
checkpoint 13.9
- General
- 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.
- WCAG
Checkpoint 13.10 Provide a means to skip over multi-line ASCII art. [Priority 3]
- Refer to WCAG checkpoint 1.1 and the example of ascii
art in the glossary.
- Techniques for WCAG
checkpoint 13.10
- HTML
- Where a PRE element is used with substantial punctuation and non-words, ask for text
alternative.
- WCAG Checkpoint 14.1 Use the clearest
and simplest language appropriate for a site's content. [Priority 1]
- Techniques for
WCAG checkpoint 14.1
- General
- Provide readability ratings for text.
- Provide a thesaurus function
- Provide a grammar-checking function
- WCAG Checkpoint 14.2
Supplement text with graphic or auditory presentations where they will facilitate
comprehension of the page. [Priority 3]
- Refer also to WCAG guideline 1.
- Techniques for WCAG checkpoint 14.2
- 3.3 Ensure that prepackaged content conforms to
the Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority]
(Checkpoint 3.3)
- For example, include captions, an auditory description, and a collated
text transcript with prepackaged movies. Refer also to checkpoint 3.4.
- 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.
- 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: Amaya does not provide any clip art or other prepackaged content.
- 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)
- For example, prompt the author for a text equivalent of an image. If the author has already provided a
text equivalent for the same image used in another document, offer to reuse that text and
prompt the author for confirmation. If the tool automatically generates a
"Search" icon, it would be appropriate to automatically reuse the previously
authored text equivalent for that icon. Refer also to checkpoint 3.3 and checkpoint
3.5.
Note: 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.
- 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.
- 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: These alternative equivalents may be packaged with the tool,
written by the author, retrieved from the Web, etc.
- Maintain a database registry that associates object identity information with
alternative information. Whenever an object is used and an equivalent alternative is
provided, ask the author whether they want to 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.
- Reference: >Allow authors to make keyword searches of a description database
(to simplify the task of finding relevant images, sound files, etc.). A paper describing a method to create searchable databases for video
and audio files is available (refer to [SEARCHABLE]).
- Suggest pre-written descriptions as default text whenever one of the associated files is
inserted into the author's document.
- The use of the Resource Description Framework (RDF) [RDF10], or formats like SVG can enable a tool
to maintain and use libraries of information within the tool and on the Web.
- This checkpoint is priority 3, meaning that in itself, it does not have a critical
effect on an authoring tool's likelihood of producing accessible mark-up. However, certain
implementations of this Alternative Information Management Mechanism (AIMM) [APROMPT] have the
potential to simultaneously satisfy several higher priority checkpoints and dramatically
improve the usability of an access aware authoring tool. In particular:
- The AIMM [APROMPT] should maintain
a list of associations between object file names and authored responses to prompts for
alternative information (per checkpoint
3.1). The alternative information may take the form of short strings (i.e.,
"alt"-text) or pointers to descriptive files (i.e., "longdesc",
transcripts, etc.). Multiple associations for the same object for different languages or
contexts should also be handled.
- The AIMM [APROMPT] would offer the
associated alternative information as a default whenever the appropriate associated object
is selected for insertion. 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 alternative information mechanism should be closely integrated with the pre-written
alternative information provided for all packaged multimedia files, per checkpoint 3.3. 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.
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.
- Reference: The WAI Evaluation and Repair group [WAI-ER] is developing a document that
discusses detailed techniques for testing content according to the Web Content
Accessibility Guidelines. A draft of that document is available [AUTO-TOOL].
- Where the tools cannot test for accessibility errors, provide the author with the
necessary information, wizards, etc. to check for themselves. Refer also to checkpoint 5.1.
- 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.
- 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.
- 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.
- Where there is a change in the writing script used, prompt the author to identify
whether there has been a change in language
- 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..
- 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].
- Reference: Refer also to the WAI accessibility references listed in techniques
for Refer also to checkpoint 1.1..
- Reference: The Web Accessibility Initiative's Protocols and Formats group have a
draft set of notes about creating accessible markup languages [XMLGL].
- Sample: Amaya currently checks for validity, but the only warning of invalid
markup appears in the structure view. The Amaya developers are investigating automating an
accessibility check and author notification. Where Amaya detects an error, it identifies
and highlights the incorrect code in the structure view, allowing the author to delete it.
- 4.2 Assist authors in correcting accessibility problems. [Relative Priority] (Checkpoint 4.2)
- At a minimum, provide context-sensitive help with the accessibility
checking required by checkpoint 4.1
- Reference: The WAI Evaluation and Repair group [WAI-ER] is developing a document that
discusses detailed techniques for repairing accessibility errors in content according to
the Web Content Accessibility Guidelines. A draft of that document is available [AUTO-TOOL].
- Assist authors in ways that are consistent with the look and feel of the authoring tool.
- Provide context sensitive-help for accessibility errors. Refer also to guideline 6.
- 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).
- 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 Refer also to checkpoint 7.4..
- Possible implementation strategy: Where there are errors in a document Amaya could alert
the author and warn that the document must be changed, and present the structure view
highlighting areas where it has changed the markup, allowing the author to abort the
editing session or save the changed version under a new name.
- 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.
- Provide a summary of all automated structural changes that may affect accessibility.
- Provide options for the author to confirm or override removal of markup on a
change-by-change basis or as a batch process.
- If changes to the markup 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.
- 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)
- Provide a list of all accessibility errors found in a Web page.
- Provide a summary of accessibility problems remaining by type and/or by number.
- 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)
- Implement XSLT [[XSLT]] together with a user-interface for expressing transformations. Refer also to checkpoint 2.1.
- 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.
- Allow the author to define transformations for imported documents that have
presentation, rather than structural, markup.
- 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.
- Remember that accessibility information, including attributes or properties of the
elements being transformed, must be preserved - see checkpoint 1.2
- Sample: Amaya provides a language for specifying structure transformations, and a
large number of predefined transformations are included.
Checkpoints:
- 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)
- 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.
- 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.
- 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
- 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.
- A help page that describes how to make an HTML image map should include adding
alternative information for each
AREA
element in the MAP
as part
of the process. Any examples of code should give either block content with text links, or AREA
elements that all have relevant "alt"
attribute values.
- When an author creates an HTML frameset, suggest the links from the navigation bar (and
perhaps the content of the "first page") as the content for the
NOFRAMES
element.
- Sample: In Amaya some accessibility features are part of relevant dialogs.
Others, such as longdesc and title attributes must be separately generated by the author.
The development team will integrate these into the relevant dialogues in future releases.
- 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)
- When the author has selected text to format, the use of CSS should be emphasized rather
than the (deprecated) HTML
FONT
element.
- Highlight the most accessible solutions when presenting choices for the author.
- Providing an editing view that shows equivalent alternatives in the main content view
will make it clear that they are necessary, and will make it obvious when they are
missing.
- 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
requesting equivalent alternatives for an image with the HTML
OBJECT
element,
offer an unchecked option for a null value (i.e., there is no content, implying the image
has no real function) with the cursor positioned in the entry field for alternative text
(and, if available, provide the appropriate value from the "Alternative Information
Management Mechanism"; refer to checkpoint
3.5) rather than offering the filename as a default suggestion, or selecting the null
"alt" value as a default.
- Sample: Amaya's user interface guides the author to produce structured content,
with presentation elements separated into style sheets. Providing an equivalent
alternative is mandatory at the time of inserting some elements.
Checkpoints:
- ATAG 6.1 Document all features that promote the
production of accessible content. [Priority 1] (Checkpoint 6.1)
-
Required:
- Ensure that accessibility solutions are present in all help text descriptions of markup
practices (e.g., HTML
IMG
elements should appear with an "alt"
attribute and a "longdesc"
attribute wherever appropriate).
- Ensure that electronic documentation complies with the Web Content Accessibility
Guidelines 1.0 [WCAG10]
Suggested:
- Link from help text to any automated correction utilities.
- Link those mechanisms to identify accessibility problems (e.g., icons, outlining or
other emphasis within the user interface) to help files.
Samples:
- Amaya help pages for images and image maps include providing text alternatives as part
of the process. [Screenshot needed]
- 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. For
example, in an example explaining how the border of an image can be changed in an image
properties dialog, ensure that the ALT field is filled with meaningful text.
- Provide examples of all accessibility solutions in help text, including those of lower
priority in WCAG 1.0 [WCAG10].
Suggested:
- In help text, when explaining the accessibility issues related to non-deprecated
elements, emphasize appropriate solutions rather than explicitly discouraging the use of
the element.
- 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".
- Avoid labelling accessibility features of the tool with a "handicapped" icon,
as this can give the impression that accessible design practices only benefit disabled
authors.
- In help text, 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".
- Implement context-sensitive help for all special accessibility terms as well as tasks
related to accessibility.
- Document the tool's conformance to ATAG 1.0 [ATAG10].
- Include current versions of, or links to relevant specifications in the documentation
(e.g. HTML 4 [HTML4],
CSS [CSS2].) This is
particularly relevant for markup languages that are easily hand edited, such as most XML
languages [XML].
- Include a tutorial specifically on checking for and correcting Web accessibility
problems.
- Link to or provide URIs for more information on accessible Web authoring, such as WCAG
1.0 [WCAG10], and
other accessibility-related resources.
- Ensure that documentation examples conform to WCAG 1.0 [WCAG10], at least to the level that the tool
conforms to ATAG 1.0 [ATAG10].
- 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)
-
-
Checkpoints:
- 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)
-
- The techniques for this checkpoint include references to checklists and guidelines for a
number of platforms and to general guidelines for accessible
applications.
- 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 guidelines. WCAG 1.0 [WCAG10] and UAAG 1.0 [UAAG10] both have priority
systems that are directly compatible with the priorities in [ATAG10].
- User Interfaces are sometimes built as Web content, and, as such, should follow the Web
Content Accessibility Guidelines 1.0 [WCAG10]. Refer also to guideline 1.
Requirements:
The following are common requirements for producing accessible software. This list does
not necessarily cover all requirements for all platforms, and items may not apply to some
software.
- 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.
- 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.
- 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.
- 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.
- Do not rely on color alone for meaning. Use color for differentiation, in combination
with accessible cues (text equivalents, natural language, etc.).
- Position related text labels and objects consistently, and in an 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).
- Clearly identify the user focus (and expose it via API).
- Unexpected events should not be caused by viewing content (for example by moving the
focus to a new point).
- Allow user control of timing - delays, time-dependent response, etc.
- Allow for navigation between as well as within windows.
- Provide documentation for all features of the tool.
- Ensure that help functions are accessible.
References:
- Guidelines for specific platforms include:
- "IBM Guidelines for Writing Accessible Applications Using 100% Pure Java" [JAVA-ACCESS] R.
Schwerdtfeger, IBM Special Needs Systems.
- "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.
- "Information for Developers About Microsoft Active Accessibility" [MSAA] Microsoft Corporation.
- "The Inter-Client communication conventions manual" [ICCCM]. A protocol for communication between
clients in the X Window system.
- "Lotus Notes accessibility guidelines" [NOTES-ACCESS] IBM Special Needs
Systems.
- "Java accessibility guidelines and checklist" [JAVA-CHECKLIST]
IBM Special Needs Systems.
- "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 Human Interface Guidelines" [APPLE-HI] Apple Computer Inc.
- "The Microsoft Windows Guidelines for Accessible Software Design" [MS-SOFTWARE].
- Guidelines for specific software types include:
- "The Three-tions of Accessibility-Aware HTML Authoring Tools" [ACCESS-AWARE],
J. Richards.
- "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:
- "Accessibility for applications designers" [MS-ENABLE] Microsoft Corporation.
- "Application Software Design Guidelines" [TRACE-REF] compiled by G. Vanderheiden. A
thorough reference work.
- "Designing for Accessibility" [SUN-DESIGN] Eric Bergman and Earl
Johnson. This paper discusses specific disabilities including those related to hearing,
vision, and cognitive function.
- "EITAAC Desktop Software standards" [EITAAC] Electronic Information Technology
Access Advisory (EITACC) Committee.
- "Requirements for Accessible Software Design" [ED-DEPT] US Department of Education, version
1.1 March 6, 1997.
- "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.
- 7.2 Allow the author to change the presentation
within editing views without affecting the
document markup. [Priority 1] (Checkpoint 7.2)
-
Requirements:
- In representing the source structure of a document mark elements with text brackets
rather than with purely graphic representations. For example, "</>" is
regarded as a text bracket, since it is made of character elements.
- Allow the author to create audio style sheets using a graphical representation rather
than an audio one (with accessible representation, of course).
- 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.
- Sample: Amaya allows the author to create local style sheets, and to enable or
disable each style sheet that is linked to a document.
- 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 (e.g., 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.
Sample:
- Amaya allows each attribute to be edited through the menu or through the
structure view. Element types can be assigned through the menu system.
- 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:
- This checkpoint does not apply to tools, such as those used to translate from one format to another,
that do not have an
editing view.
- 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]
- 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, allowing 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 (deprecated)
FONT
into heuristically determined structure;
- Lists of lists to tables and back;
- MathML transformations between semantic and presentation markup;
- Transforming the SVG
g
element to symbol
;
- 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:
- Search functions are already present in almost every text and hypertext editing tools.
The simplest allow searching for a sequence of characters, while 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.
Suggested:
- 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. This is 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: