In the introduction we emphasize the new techniques structures: i.e. the break-out
documents for each language, the required/suggested breakdown, the concpet of Crossover's
(practices that go towards satisfying multiple checkpoints), references, and screenshot
samples.
Perhaps we can produce a top-10 accesss 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.)
Checkpoints:
- 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:
- Ensure that all structural features available in a language are available within a tool.
For example, a web publishing system based on a database must allow for the use of
equivalent alternatives and the use of structural elements to identify the semantic role
played by different content.
- Include equivalent alternatives for image formats (ex. PNG, SVG, WebCGM, JPEG, and GIF)
that allow them text content (Crossover: ATAG 3.1).
- Include equivalent alternatives for audio or video formats that allow them (Crossover
ATAG: 3.1).
Suggested:
- Provide options for accessibility information to be
included whenever an object is added to a document. (Crossover: ATAG 3.1).
- Allow direct source editing
- An audio/video editing suite can use SMIL to synchronize audio, video, descriptive
signing and text tracks.
- 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 which does
not allow for markup of structured information. When converting to a language which does
allow structure, such as XHTML, allow the author to specify which presentation conventions
correspond to which structural markup.
Reference:
- 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 recognizes and 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.
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.
- 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)
- Do not transform 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:
- 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 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.
- 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:
- Use consistent document structures. (WCAG x.y, Pz)
- For a tool that does site-wide management, provide consistent navigation systems and
document structures. (WCAG x.y, Pz)
- Include markup that provides equivalent alternatives for media-dependent elements or
content. (WCAG x.y, Pz)
- Do not use structural markup for presentation
effects, or presentation markup for known
structures. For example, use list markup of an appropriate type rather than creating
multiple line paragraphs and beginning each line with an image of a bullet. Do not use
list markup for an indentation effect. (WCAG x.y, Pz)
- 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. (WCAG x.y, Pz)
- New markup languages are constantly being developed, and in many cases offer
improvements to the structure and utility of Web content. In implementing a new or
extended markup language, it is important to ensure that a tool does not remove access to
information that had been inherent in the base markup language. (WCAG x.y, Pz)
- The same can apply to a format that simplifies 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
implementing a means to include the attribute, compromises the accessibility of any
included IMG
elements. (WCAG x.y, Pz)
Reference:
- The Web Accessibility Initiative's Protocols and Formats group have a draft set of notes
about creating accessible markup languages [XMLGL].
- 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:
- Produce accessible representations for site maps generated by the authoring tool. (WCAG
x.y, Pz)
- Provide equivalent alternatives for all non-text content (images, audio, etc). (WCAG
x.y, Pz)
- Use consistent navigation mechanisms. (WCAG x.y, Pz)
- Ensure that event-handlers for scripts are device-independent. (WCAG x.y, Pz)
- Ensure that color schemes provide sufficient contrast for people or technology with poor
color separation. (WCAG x.y, Pz)
- Ensure that the natural language of the template is identified. (WCAG x.y, Pz)
Suggested:
- Provide navigation bars. (WCAG x.y, Pz)
- Provide keyboard shortcuts for important links, etc. (WCAG x.y, Pz)
Samples:
Checkpoints:
- 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.
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.
References:
- 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)
- This is necessary for user agents to be able to render Web
content in a manner appropriate to a particular user's needs.
-
Required:
- Produce valid HTML/XML. Refer to [HTML-XML-VALIDATOR].
- 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.
- 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 with Web and non-Web editing modes can change modes when invalid markup is
introduced. (Crossover: ATAG 4.1)
Sample:
- 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]
Checkpoints:
- 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:
- 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-formated 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)
- Satisfying checkpoint 3.5 would
provide much of the required functionality. Refer also to checkpoint 4.1. Refer also to checkpoint 6.2.
- 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.
- Prompt for text which describes the range and the effect of possible coordinate entries,
and generate an alternative, form-based entry system.
Reference:
- Relevant WCAG Checkpoints:
- (WCAG 1.1, P1) Provide a text equivalent for every non-text element.
- (WCAG 1.2, P1) Provide redundant text links for each active region of a server-side
image map.
- (WCAG 1.3, P1) 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) For any time-based multimedia presentation (e.g., a movie or animation),
synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual
track) with the presentation.
- (WCAG 1.5, P3) 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 2.1, P1) Ensure that all information conveyed with color is also available without
color, for example from context or markup.
- (WCAG 2.2, P2 for images)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.
- (WCAG 3.1, P2) When an appropriate markup language exists, use markup rather than images
to convey information.
- (WCAG 6.2, P1) Ensure that equivalents for dynamic content are updated when the dynamic
content changes.
- (WCAG 6.3, P1) 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) Ensure that dynamic content is accessible or provide an alternative
presentation or page.
- (WCAG 7.1, P1) Until user agents allow users to control flickering, avoid causing the
screen to flicker.
- (WCAG 7.2, P2) 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).
- (WCAG 7.3, P2) Until user agents allow users to freeze moving content, avoid movement in
pages.
- (WCAG 8.1, P1) Make programmatic elements such as scripts and applets directly
accessible or compatible with assistive technologies.
- (WCAG 9.1, P1) Provide client-side image maps instead of server-side image maps except
where the regions cannot be defined with an available geometric shape.
- (WCAG 11.1, P2) Use W3C technologies when they are available and appropriate for a task
and use the latest versions when supported.
- (WCAG 11.3, P3) Provide information so that users may receive documents according to
their preferences (e.g., language, content type, etc.)
- (WCAG 11.4, P1) 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.
- (WCAG 13.2, P2)Provide metadata to add semantic information to pages and sites.
- (WCAG 14.2, P3) Supplement text with graphic or auditory presentations where they will
facilitate comprehension of the page.
- The WAI Evaluation and Repair group [WAI-ER] is developing a document that
discusses detailed techniques for testing and repairing the accessibility of content
according to the Web Content Accessibility Guidelines. Much of that material is useful in
fulfilling the requirements of this checkpoint. A draft of that document is available [AUTO-TOOL].
- ATAG 3.2 Help the author create structured
content and separate information from its presentation. [Relative Priority]
(Checkpoint
3.2)
-
Required:
- Prompt the author to identify the structural role of content that has been emphasized
through styling. (WCAG x.y, Pz)
- Prompt the author to provide header information for tabular data. (WCAG x.y, Pz)
- Prompt the author (and allow them to specify a default suggestion) for the language of a
document. (WCAG x.y, Pz)
Suggested:
- 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 x.y, Pz)
- 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 x.y, Pz)
- Use a dictionary lookup system to recognise changes of language, or use of abbreviations
and acronym. A similar system can be used to recognise 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.
- Provide an outline view that lets the author clearly see the structure of the document
independently of the specified presentation.
Reference:
- Relevant WCAG Checkpoints:
- WCAG
Checkpoint 1.1 Provide a text equivalent for every non-text element [Priority 1]
- WCAG Checkpoint 1.2 Provide redundant text
links for each active region of a server-side image map. [Priority 1]
- WCAG Checkpoint 1.3 Until user
agents can automatically read aloud the text equivalent of a visual track, provide an
auditory description of the important information of the visual track of a multimedia
presentation. [Priority 1]
- WCAG Checkpoint 1.4 For any time-based
multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives
(e.g., captions or auditory descriptions of the visual track) with the presentation. [Priority 1]
- WCAG Checkpoint 1.5 Until user
agents render text equivalents for client-side image map links, provide redundant text
links for each active region of a client-side image map. [Priority 3]
- WCAG
Checkpoint 2.1 Ensure that all information conveyed with color is also
available without color, for example from context or markup. [Priority 1]
- Prompt the author to identify a class, or markup element for uses of color.
- 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].
- 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]
- 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 helplful 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]
- 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]
- 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]
- 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]
- 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]
- 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 recognised
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]
- 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]
- 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]
- 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]
- 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]
- WCAG
Checkpoint 5.5 Provide summaries for tables. [Priority 3]
- WCAG
Checkpoint 5.6 Provide abbreviations for header labels. [Priority 3]
- 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]
- WCAG
Checkpoint 6.2 Ensure that equivalents for dynamic content are updated when the
dynamic content changes. [Priority 1]
- 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]
- WCAG Checkpoint 6.4 For scripts and
applets, ensure that event handlers are input device-independent. [Priority 2]
- WCAG
Checkpoint 6.5 Ensure that dynamic content is accessible or provide an
alternative presentation or page. [Priority 2]
- WCAG
Checkpoint 7.1 Until user agents
allow users to control flickering, avoid causing the screen to flicker. [Priority 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]
- WCAG
Checkpoint 7.3 Until user agents
allow users to freeze moving content, avoid movement in pages. [Priority 2]
- 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]
- 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.]
- 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]
- WCAG
Checkpoint 9.2 Ensure that any element that has its own interface can be
operated in a device-independent manner. [Priority 2]
- WCAG Checkpoint 9.3 For scripts, specify
logical event handlers rather than device-dependent event handlers. [Priority 2]
- WCAG Checkpoint
9.4 Create a logical tab order through links, form controls, and objects. [Priority 3]
- 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]
- 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]
- 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]
- WCAG
Checkpoint 10.4 Until user agents
handle empty controls correctly, include default, place-holding characters in edit boxes
and text areas. [Priority 3]
- 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]
- WCAG
Checkpoint 11.2 Avoid deprecated features of W3C technologies. [Priority 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]
- 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]
- WCAG
Checkpoint 12.1 Title each frame to facilitate frame identification and
navigation. [Priority 1]
- 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]
- WCAG
Checkpoint 12.3 Divide large blocks of information into more manageable groups
where natural and appropriate. [Priority 2]
- WCAG
Checkpoint 12.4 Associate labels explicitly with their controls. [Priority 2]
- WCAG
Checkpoint 13.1 Clearly identify the target of each link. [Priority 2]
- 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]
- 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]
- 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]
- WCAG Checkpoint 13.5
Provide navigation bars to highlight and give access to the navigation mechanism. [Priority 3]
- 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]
- WCAG
Checkpoint 13.9 Provide information about document collections (i.e., documents
comprising multiple pages.). [Priority 3]
- 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]
- WCAG Checkpoint 14.1 Use the clearest
and simplest language appropriate for a site's content. [Priority 1]
- 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]
- 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].
- ATAG 3.3 Ensure that prepackaged content conforms to
the Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority]
(Checkpoint 3.3)
-
Required:
- Include captions, an auditory
description, and a collated text transcript with
prepackaged movies.
- 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).
- ATAG 3.4
Do not automatically generate equivalent
alternatives. Do not reuse previously authored alternatives without author
confirmation, except when the function is known with certainty. [Priority 1]
(Checkpoint 3.4)
-
Required:
- Prompt the author for a text equivalent
of an image.
- 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.
- 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.
- 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. For example, 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.
- 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.
- ATAG 3.5 Provide functionality for managing, editing,
and reusing alternative equivalents for
multimedia objects. [Priority 3] (Checkpoint 3.5)
Suggested:
- Maintain a database registry that associates object identity information with
alternative equivalent. Whenever an object is used and an equivalent equivalent is
provided a record associating them could be added to the database. In the case of a text equivalent, the equivalent information may be stored in the
database. For more substantial information (such as video captions or audio descriptions),
a link to the information may be stored.
- Allow different alternative information to be associated with a single object.
- These alternative equivalents may be packaged with the tool, written by the author,
retrieved from the Web, etc.
- Allow authors to make keyword searches of a description database (to simplify the task
of finding relevant images, sound files, etc.).
- Suggest pre-written descriptions as default text whenever one of the associated files is
inserted into the author's document. (Crossover: ATAG 3.4)
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 checkpoint have the potential to simultaneously satisfy several
higher priority checkpoints and dramatically improve the usability of an access aware
authoring tool. In particular:
- A tool might 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.
- A tool might 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.
References:
Checkpoints:
- ATAG 4.1 Check
for and inform the author of accessibility problems. [Relative Priority] (Checkpoint 4.1)
-
Required:
- 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.
- 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.
Suggested:
- 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.
- 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.
- 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.
- 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.
References:
- 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].
- 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].
- Refer also to the WAI accessibility references listed in techniques for Refer also to checkpoint 1.1.
- The Web Accessibility Initiative's Protocols and Formats group have a draft set of notes
about creating accessible markup languages [XMLGL].
Samples:
- Amaya, Aprompt, Faked (underlining).
- ATAG 4.2 Assist authors in correcting accessibility problems. [Relative Priority] (Checkpoint 4.2)
-
Required:
- At a minimum, provide context-sensitive help with the accessibility checking required by
checkpoint 4.1
Suggested:
- Assist authors in ways that are consistent with the look and feel of the authoring tool.
(Crossover: ATAG 5.1)
- 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..
References:
- 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].
- ATAG 4.3 Allow the author to preserve markup not
recognized by the tool. [Priority 2] (Checkpoint 4.3)
-
Suggested:
- 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.
- ATAG 4.4 Provide the author with a summary of the
document's accessibility status. [Priority 3] (Checkpoint 4.4)
-
Required:
- Provide a list of all accessibility errors found in a Web page.
Suggested:
- Provide a summary of accessibility problems remaining by type and/or by number.
- ATAG 4.5 Allow the author to transform presentation markup that is misused to
convey structure into structural markup,
and to transform presentation markup used for style into style sheets. [Priority 3] (Checkpoint 4.5)
-
Required:
- Allow the author to define transformations for imported documents that have
presentation, rather than structural, markup.
- Remember that accessibility information, including attributes or properties of the
elements being transformed, must be preserved - see checkpoint 1.2
Suggested:
- 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.
References:
- 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.
Checkpoints:
- ATAG 5.1 Ensure that functionality related to accessible authoring practices is
naturally integrated into the overall look and feel of the tool. [Priority 2]
(Checkpoint 5.1)
-
Required:
- 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.
Suggested:
- 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.
- ATAG 5.2 Ensure that accessible authoring practices
supporting Web Content Accessibility Guidelines 1.0 [WCAG10] Priority 1 checkpoints are among the
most obvious and easily initiated by the author. [Priority 2]
(Checkpoint 5.2)
-
Required:
- 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.
- 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.
Suggested:
- 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.
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. [Screenshot]
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 resizeable 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)
- This allows the author to edit the document according to personal requirements, without
changing the way the document is rendered when published.
- 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)
- An authoring tool may offer several editing views of the same document, such as a source
mode that allows direct editing of all properties.
- Allow the author to individually edit each attribute of the elements in an HTML or XML
document, for example, through a menu. Note: This must include the
ability to add valid values for attributes that are not present, as well as changing
current values of attributes.
- 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.
- Graphically represented elements cannot be identified by assistive technologies that
render text as braille, speech, or large print, unless there is appropriate information
available as text. For example, some HTML authoring tools render start and end tags as
graphics. Such tag representations need to have a text equivalent to be accessible to
assistive technologies.
- 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)
- Some tools, such as those used to translate from one format to another, do not have an
editing view.
- 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.
- To minimally satisfy this checkpoint, allow navigation from element to element.
- In a hypertext document allow the author to navigate among links and active elements of
a document.
- For SMIL and other time-based presentations, allow the author to navigate temporally
through the presentation.
- Allow the author to navigate regions of an image, or the document tree for an image
expressed in a structured language such as Scalable Vector Graphics [SVG].
- 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.
- 7.5 Enable editing of the structure of the document
in an accessible fashion. [Priority 2] (Checkpoint 7.5)
- 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.
- Sample: Amaya allows the author to select elements
(including containers) and cut, copy and paste them with their attributes and properties
in any of the formatted, structure and alternate views.
- 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]
These guidelines often refer to the practice of prompting and to a lesser extent
alerting. The following guidelines and selected checkpoints make explicit use of them:
- guideline 3
(Support the creation of accessible content)
...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....
- guideline 4
(Provide ways of checking and correcting inaccessible content)
- 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 importance of these concepts in the document and a perceived ambiguity of their
meanings has been identified as a source of confusion. This appendix will attempt to
clarify the issue.
The word 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.
Note: 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, to some extent,
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 level A, double-A or
triple-A) and the scheduling of prompting (i.e., as problems occur or at the completion of
authoring). Of course, the extent of this configurability should be determined by
developers on an individual basis. 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 5
Integrate accessibility solutions into the overall "look and feel". . 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. (from the introduction to guideline 4)
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. Below
is a screen shot of this card:
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.