Techniques for
checkpoint 3.9: Document the workflow
process of using the tool to produce accessible content. [Priority 3] [@@ed.
The term "workflow" still needs definition.@@]

Guiding the author to produce accessible content:

Conformance with accessibility authoring practices is an authoring constraint,
analogous to producing valid code or grammatical text. Since the role of any
authoring tool is to facilitate satisfaction of authoring constraints, it is
natural that accessibility-aware authoring tools should include features to
facilitate the process of creating accessible content. The checkpoint requirements
for this section include prompting and assisting the author to create accessible
content, especially for information that cannot be generated automatically,
such as descriptions of graphics (Checkpoint 3.1), checking
for accessibility problems (Checkpoint 3.2), and assisting
in the repair of accessibility problems (Checkpoint 3.3).
[@@some edits here to bring back to GL's]

Implementation Note: All functions added to support accessible authoring
should be flexible enough to take into account different authoring styles. When
authors can configure accessibility features to support their regular work patterns,
they will be more likely to feel comfortable with their use and be more receptive
to interventions from the tool. 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.

Executive Summary: [@@this has all
been modified@@]

In some authoring situations it may be necessary to prompt
(see clarification) or assist
(e.g. task automation, entry storage, etc.) authors to follow accessible authoring
practices. This is especially true of accessibility problems that require human
judgment to remedy, such as adding descriptions to images.

One approach to prompting and assisting the author to create accessible content
is to allow problems to be created and then address them later as part of checking
(checkpoint 3.2) and correcting (checkpoint
3.3). However, if the author is left uninformed of accessibility problems
for too long, they may be overwhelmed by the full weight of the accumulated
problems then when they are finally informed. It is, therefore, preferable to
begin guiding the author towards the production of accessible content before
accessibility problems have actually been introduced.

It is important to note that when information is required from the author,
it is crucial that that information be correct and complete.
This is most likely to occur if the author has been convinced to provide the
information voluntarily. Therefore, overly restrictive mechanisms are not recommended
for meeting this checkpoint.

Clarification:
[@@all modified@@]

The term prompt in this checkpoint should not be
interpreted as implying intrusive prompts, such as pop-up dialog boxes. Instead,
ATAG 2.0 uses prompt in a wider sense, to mean anyprocess
of eliciting author input. This process should be:

initiated by the tool rather than the user,

user configurable in form and timing, and

implemented with the goal of developing, in the user, a positive attitude
towards the accessibility-related features. [@GL4?@]

Techniques for Success Criteria 1: When the actions of the author risk creating
accessibility problems (e.g. image inserted, author typing invalid element
into a code view, author initiating a page creation wizard, etc.), the tool
must intervene to introduce the appropriate accessible authoring
practice. This intervention may proceed according to a user-configurable schedule.

Technique 3.1.1: Consider
how much user configurability will be provided. User acceptance
of the accessibility features of an authoring tool will likely depend on
the degree to which these features can be integrated into authors' existing
workflows. That is why the ATAG definition of "prompting" clearly
states that: "the form and timing that this prompting takes can be
user configurable". In other words, the author should be able to control
to some extent how and when assistance in avoiding accessibility problems
is rendered by the tool. This user configurablity will help reconcile the
additional accessibility authoring tasks with the regular work pattern of
the author. To achieve this, tools may offer the author a range of checking
and prompting options (see Figure 3.1.1), including:
[@@new@@]

which accessibility standards they wish to follow, and where applicable,
to which level,

the degree to which the prompts are highlighted in the interface,

the nature of the accessibility guidance they wish to receive, and

the nature and timing of any automated accessibility features (e.g.
accessibility checking or correcting utilities).

(a) Since prompts for short text strings are usually intended to elicit
entries of ten words or less, they can be afforded relatively little
screen real estate.

(b) A preview of the image can be provided.

(c) The text control can include a drop-down list so that the author
can either enter new text or choose from labels appropriate for objects
serving special functions (e.g. "decorative", "button",
"spacer", "horizontal rule", etc.).

(a) Prompts for form field place-holders can be similar to those for
short text labels.

(b) Authors could have the option of directly selecting nearby text
strings that are serving implicitly as labels.

(c) This can be included in a "form clean-up" utility.

Technique 3.1.2(5): Accesskeys:[@@changed@@]

(a) Authors can be prompted with a list of links that are candidates
for accesskeys because they are common to a number of pages in a site.

Technique 3.1.2(6): List sub-groups: [@@changed@@]

(a) Where there are more than 10 choices in
a list of form controls (that can be grouped), the user can be asked
to identify subgroups.

(b) This can be included in a "form clean-up"
utility.

Technique 3.1.2(7): Form field labels:[@@changed@@]

(a) This can take the form of a utility that walks the user through
the existing form fields and queries them to select existing text that
is serving as a label or to enter a label.

(b) This can be included in a "form clean-up" utility.

[@@EXAMPLE@@]

Technique 3.1.2(8): TAB order definitions:[@@changed@@]

(a) The author can be provided with a numbering tool that they can
use to select controls to create a TAB preferred sequence.

(b) Where there are only a few links that change in each page of a
collection, a tool can ask the author to confirm whether these links
receive focus first. If so, then the tool can appropriately update the
tabindex order.

(c) This can be included in a "form clean-up" utility.

Technique 3.1.2(9): Contrasting colours:
[@@changed@@]

(a) When a foreground or background color is defined the color choices
provided to the author could be pre-screened for contrast.

(b) Color palettes can be assembled with problematic colors flagged.

[@@EXAMPLE@@]

Technique
3.1.2(10): Audio/video transcripts:
[@@changed@@]

(a) The author can be prompted for the location of a pre-existing
transcript.

(b) Although transcript writing is a complex process for long media
files, tools can include simple transcription writing suites, with built-in
media players, for short media files.

(a) The author can be prompted for the location of a captioned version
of a video.

(b) The creation of captions can be a time consuming process, but
public domain tools do exist for adding relatively simple captions (e.g.,
MAGpie).

Technique
3.1.2(12): Audio descriptions for video:
[@@changed@@]

(a) The author can be prompted for the location of a described version
of a video.

(b) The recording of traditional video descriptions (that are encoded
into the video file where silent periods occur in the original soundtrack)
is a complex process that may be beyond the average author. However,
technologies are becoming available that allow the audio description
files to be stored separately, to be played only if requested by the
user.

(a) The author can be prompted for the location of a version of an
audio or video file with signed translation.

(b) The creation of signed translation video files is assumed to be
beyond the average author, but new technologies (signing avatars) are
being developed for automated sign language animation to be generated
from text.

Technique 3.1.2(14):
Still images of video:
[@@changed@@]

(a) The author can be prompted for the location of a still image.

(b) The tool can provide a utility for grabbing still images from
video.

Technique 3.1.2(15): Metadata:[@@changed,
needs MUCH more@@]

(a) 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.

(b) Metadata retrieval standards can be supported.

Technique 3.1.2(16): Document structure:[@@addedand likely will include many more techs@@]

(a) The tool can offer to
transform presentation markup that is
misused to convey structure into structural markup, with style
sheets used to retain the same appearance.
[@@split and changed@@]

(b) 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 "-") can be used to automatically
identify lists.

(c) Authors of DTDs or Schemas can be prompted to specify explicit
structure (e.g. nesting)

Technique 3.1.2(17): Tabular structure:[@@addedand likely will include many more techs@@]

(a) To tool can prompt the author to
identify tables as used for layout or data or implement automated detection
mechanisms.

(b) The author can be prompted to provide
header information.
@@PJ indicated he
would work on this@@

(c) The author can be prompted to group columns, rows, or blocks of
cells that are related.
@@PJ indicated he
would work on this@@

(d) The tool can provide the user with a linearized view of tables
(as tablin does).
For layout tables, this version can be offered as alternatives.

Technique 3.1.2(18): Style sheets:[@@added
and likely will include many more techs@@]

(a) The tool can offer to
transform structural markup that is misused for style into style sheets.
[@@changed@@]

(b) The tool can 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.

(c) The tool can provide a utility for editing
the layout and styling effects independently of the text content.

(d) The author can be asked to identify headings and subheadings.

(e) Formatting patterns can be recognized and converted to style rules.

Technique 3.1.2(19): Clearly written text: [@@changed@@]

(a) The author can be prompted to specify a default language of a
document.

(b) A thesaurus function can be provided.

(c) A dictionary lookup system can recognize changes of language,
abbreviations or acronyms.

(d) Recognize collections of uppercase letters as likely acronyms
(in languages that have case) and prompt the author for an expansion.

Technique 3.1.2(20): Non-Text supplements to text: [@@changed@@]

(a) The tool can prompt authors to provide icons for buttons, illustrations
for text, graphs for numeric comparisons, etc.

Technique 3.1.2(21): Other information: [@@changed@@]

(a) During applet development, the author can be prompted to include
device-independent means of activation.

(b) Where regions are not easily defined, the author can be asked
to provide information that can be used to generate a form-based input
method and explains how the coordinates input will be used. For example,
for a geographic map the input might be used to look up latitude and
longitude of a point and then give information about that point.

(c) The author can be asked to provide a link to skip over objects
(since some browsers cause objects to permanently capture the tab focus).
@@new category and T####@@@@proposed
at F2F@@

(d) The author can be prompted 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.

(e) When frames used for a mosaic of images, the tool can allow inclusion
of markup files (with images embedded) rather than images directly.
@@new category and T####@@@@proposed
at F2F@@

Technique 3.1.3: The tool can provide multiple preview
modes and a warning to authors that there are many other less predictable
ways in which a page may be presented (aurally, text-only, text with pictures
separately, on a small screen, on a large screen, etc.). Some possible
document views include:
[@@changed@@]

Technique ???: Provide an outline view that
lets the author clearly see the structure of the document independently
of the specified presentation.
@@new category and T####@@

Technique ???: Include lists (marked as lists)
in a collapsible structure view.

Technique ???: Prompt for alternative content
for applets and programmatic objects. [T0145][@@covered by labels and descriptions?@@]

Technique ???: Prompt the author for a longdesc
for each frame in a frameset.
[@@covered: should be deleted@@]

Technique ???: Use technologies according to specification.-
This is likely to be handled by the choices made by the tool developers.
General-purpose text editors (e.g. emacs, etc.) would need to make technology
selection recommendations. [@@needs to be moved
out of here@@]

Technique ???: Prompt for server-side alternatives
for essential client-side scripts (those used for content and navigation)
and applets.

Techniques for Success Criteria 2: The intervention must occur at
least once before completion of authoring (e.g. final save, publishing, etc.).

Executive Summary:

Despite prompting assistance from the tool (see
Checkpoint 3.1), accessibility problems may still be introduced. For example,
the author may cause accessibility problems during hand coding or content with
existing accessibility problems may be opened for editing. In these cases, the
prompting and assistance mechanisms that operate when markup is added or edited
(i.e. insertion dialogs and property windows) must be backed up by a more general
checking system that can detect and alert the author to problems anywhere within
the content (attribute, element, programmatic object, etc.). It is preferable
that this checking mechanisms be well integrated with correction mechanisms
(see Checkpoint 3.3), so that when
the checking system detects a problem and informs the author, the tool can also
help the author address the issue.

Techniques for Success Criteria 1: The tool must provide a check ( automated
check, semi-automated check or manual check) for detecting violations of each
requirement of WCAG.

Technique 3.2.1: Consider the level of automation
to be used for checking (and informing). Options include:
[@@new@@]

1.
Manual (not automated): The tool provides the author with instructions
for detecting a problem, but does not automate the task of detecting the
problem in any meaningful way. As a result, the author must follow the
instructions and make the determination that a problem exists by themselves.
This type of check is discouraged since it can be annoying for the author,
especially when the type of problem in question may be easily detected
by a more automated utility (e.g. an element missing a particular attribute).

2. Semi-Automated:
The tool is able to identify potential problems, but still requires a human
judgment by the author to make a final appraisal. This type of check is
usually most appropriate for semantic-type problems, such as descriptions
of non-text objects, as opposed to purely syntactic problems, such as missing
attributes, which lend themselves more readily to automation.

3. Automated:
The tool is able to check for accessibility problems automatically, with
no human intervention required. This type of check is usually appropriate
for syntactic-type checks, such as the use of deprecated elements or a missing
attribute, in which the meaning of text does not play a role.

Technique 3.2.2: Consider the timing options to be used
for informing the author of the results of the check. Options include:
[@@new@@]

1. Immediate Interruption:
An immediate interruption is the most intrusive timing option because
the author's attention is actively diverted from the current editing task
by the notification of some issue. This might be achieved, for instance,
by an alert dialog. This type of alert presents multiple usability problems,
and should be used sparingly because it interferes with the normal design
workflow. Intrusive warnings are probably only appropriate when the window
of opportunity for correcting a serious accessibility problem is about
to close. An example of this might be when an author is publishing a document
to their site. In general, we recommend using the less disruptive timing
options.

Figure 3.2.2(a): Example of a dialog
box making an immediate interruption. [d]
(Source: mockup by AUWG)

2. Configured Interruption
(Preferred): A negotiated interruption is caused by interface
mechanisms (icons, line or color highlighting of the element, audio feedback,
etc.) that alert the author to a problem, but are flexible as to whether
the author should take immediate action or address the issue at a later
stage in the design process. This type of unintrusive alert can be better
integrated into the design workflow. For example, a colored outline might
be drawn around offending objects in a WYSIWYG view (see Figure
3.2.5), while the markup text for the same object might be highlighted
by a different font color in the code view (see Figure
3.2.6). Besides being unintrusive, such indicators will have the added
benefit of informing the author about the distribution of errors within
the document without interrupting their editing process.Of course, some
authors may choose to ignore the alerts completely. In this case, the
AUWG does not recommend forcing the author to fix the problem.
Instead, it recommends that, at some major editing
event (e.g., when publishing), the tool should remind the author of
the continuing unresolved accessibility issues.

3. Scheduled Interruption:
A scheduled interruption is one in which the author has set the tool to
alert them of accessibility issues on a configurable
schedule. One option for the schedule might be to have prompts associated
with the interface mechanisms for significant authoring events such as
saving, exiting, publishing, printing, etc. At the significant authoring
event, the author would be informed of the problem, while at the same
time they would not be prevented from saving, publishing, printing,
etc. For example, a "save as" dialog could display an accessibility warning
and an option to launch a correction utility after saving (see
Figure 3.2.7). A potential downside of this type of prompting is that
by the time the prompt is displayed (publishing, etc.), the author may
not have time to make the required changes, especially if they are extensive.

Figure 3.2.2(d):
Example of a scheduled prompt included at the bottom of a "save
as" dialog. [d]
(Source: mockup by AUWG)

Technique 3.2.3: See AERT document for evaluation and
repair algorithms. 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].

Technique 3.2.4: 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.

Technique 3.2.5: Alert authors to accessibility problems
when saving.

Technique 3.2.6: 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. (See
the Techniques for ATAG checkpoint 6.1)

Technique 3.2.7: Where the tools cannot test for accessibility
errors, provide the author with the necessary information, wizards, etc.
to check for themselves.

Technique 3.2.8: Include alerts for WCAG Priority 1
checkpoints in the default configuration.

Technique 3.2.9: 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.

Technique 3.2.10: Allow authors to choose different alert
levels based on the priority of authoring accessibility recommendations.

Technique 3.2.11: If intrusive warnings are used, provide
a means for the author to quickly set the warning to non-obtrusive to avoid
frustration.

Technique 3.2.12: The WAI Evaluation and Repair group
[WAI-ER] has produced a
Public Working Draft of techniques for evaluating and repairing HTML according
to WCAG 1.0 [AERT].

Executive Summary:

Once a problem has been detected by the author or, preferably, the tool (see
Checkpoint 3.2), the tool may assist the author to correct the problem.
As with accessibility checking, the extent to which accessibility correction
can be automated depends on the nature of the particular problems. Some repairs
are easily automated, whereas others that require human judgment may be semi-automated
at best.

Techniques for Success Criteria 1: The tool must provide a repair (automated
repair, semi-automated repair or manual repair) for correcting violations of
each requirement of WCAG.

Technique 3.3.1: Consider the level of automation to
be used for correction. Options include: [@@new@@]

1. Manual:
The tool provides the author with instructions for making the necessary
repair, but does not automate the task in any meaningful way (e.g. the
tool may move the cursor to start of the problem and still be considered
"manual"). Manual correction tools leave it up to the author
to follow the instructions and make the repair by themselves. This is
the most time consuming option for users and allows the most opportunity
for user error.

Figure 3.3.1(a): Example of a manual
repair.
This tool has detected the problem, selected the offending element in
a code view and provided a hint for repairing it - but the user must
still make the actual repair. [d]
(Source: mockup by AUWG)

2. Semi-Automated:
For some types of problems, tool can provide some automated assistance
to the user in performing corrections, but the author's input is still
required. For example, the tool may prompt the user for a plain text string,
but then be capable of handling all the markup required to add the text
string to the content. In other cases, the tool may be able to narrow
the choice of repair options, but still rely on the author to make the
final selection.

Figure 3.3.1(b): Example of a semi-automated
repair in a WYSIWYG editor. The user has right-clicked on a highlighted
object. The user must then decide whether the suggested "alt"
text is appropriate. If the user decides that it is, the tool handles
the details of updating the markup. [d]
(Source: mockup by AUWG)

3. Automated:
For some types of problems, tools may be is able to make repairs automatically.
For example, in cases where the user wishes to strip out every instance
of specific element. In these cases, very little, if any, user interface
is required.

Figure 3.3.1(c): Automated repair.
Since an automated repair might be completed with the user interface,
here is an example of an announcement that might follow an automated
repair. [d]
(Source: mockup by AUWG)

Technique 3.3.2: Consider implementing a special-purpose
correcting interface. [@@new@@]When problems
require some human judgment, the simplest solution is often to display the
property editing mechanism for the offending element. This has the advantage
that the user is already somewhat familiar with the interface. However,
this practice suffers from the drawback that it does not necessarily focus
the author's attention on the dialog control(s) that are relevant to the
required correction. Another option is to display a special-purpose correction
utility (see example) that includes only the input field(s) for the information
currently required. The advantage of this approach is that additional information
and tips that the author may require in order to properly provide the requested
information can be easily added. Notice that in the figure, a drop-down
edit box has been used for the alt-text field. This technique might be used
to allow the author to select from text strings used previously for the
alt-text of this image (see ATAG Checkpoint
3.5 for more).

1. Sequential Checking: In cases where there are likely
to be many accessibility problems, it may be useful to implement a checking
utility that presents accessibility problems and repair options in a sequential
manner. This may take the a form similar to a configuration wizard or a
spell checker (see Figure 3.3.5). In the case of a
wizard, a complex interaction is broken down into a series of simple sequential
steps the user can complete one at a time. The later steps can then be updated
on the fly to take into account the information provided by the user in
earlier steps. A checker is a special case of a wizard in which the number
of detected errors determines the number of steps. For example, word processors
usually have checkers that display all the spelling problems one at a time
in a standard template with places for the misspelled word, a list of suggested
words, and the correct word. The user also has correcting options, some
of which can store responses to affect how the same situation is handled
later. In an accessibility problem checker, sequential prompting is an efficient
way of correcting problems. However, because of the wide range of problems
the checker needs to handle (i.e. missing text, missing structural information,
improper use of color, etc.), the interface template will need to be even
more flexible than that of a spell checker. Nevertheless, the template is
still likely to include areas for identifying the problem (WYSIWYG or markup-based
according to the target audience of the tool), suggesting multiple solutions
and choosing between or creating new solutions. In addition, the dialog
may include context-sensitive instructive text to help the author with the
current correction.

Figure 3.3.3(a): Example of a sequential
accessibility checker that incorporates the special-purpose correction
interface from Figure 3.3.2. [d]
(Source: mockup by AUWG based on A-Prompt)

Technique 3.3.4: When authoring
tools produce content in real-time, the luxury of prompting on a user
configurable schedule is to a large degree lost. At the same time, due
to the time pressure, authors in real-time environments tend to be less
receptive to intrusive prompts. Nevertheless, tools that allow this kind
of authoring (see Figure 3.3.6) should still take
accessibility issues into account by supporting the following:

Determination of Participant
Requirements: If a real-time communication takes place between
individuals with no special communicative needs, there may be no need
for real-time prompting. However, the author may not personally know
all the special communicative needs of the participants (even if the
author knows everyone personally). The tool might be able to facilitate
a decision about whether supplements need to be provided by asking participants
which types of supplemental material they wish to have made available
(see "Request whiteboard descriptions" checkbox in the figure).
and then prompt the author (or see Assistant Author)
to provide these (preferably during Preparation
Time). In cases when it is not possible to know the needs of everyone
participating in a communication, the tool should assume there are unidentified
users with disabilities. Moreover, even if there are no individuals
with special communicative needs participating in the original real-time
communication, if the communication is archived there
will always be a possibility that future users will experience accessibility
problems with the material. Therefore, even when it has been determined
that the original communication does not require supplements, if the
author chooses to archive the communication, the authoring tool should
guide the author through a configurable interruption process to check
for and repair accessibility problems after the real-time session has
ended, but prior to archiving.

Assistant Author:
In some cases, it may be possible to designate a secondary author in
the live community, who can receive and respond to the intrusive prompts
for supplemental information generated as the primary author proceeds
uninterrupted. The secondary author might be an unrelated specialist,
analogous to Sign language interpreter, or a co-author (helpful for
describing technical drawings, etc.).

Preparation Time:
If the authoring tool allows the author time to pre-assemble materials
for a live presentation (e.g. a professor preparing for an online class),
this authoring is not considered real-time authoring. The authoring
tool has the opportunity to provide both intrusive and unintrusive prompts
and alerts as described elsewhere in this document. For example, when
the professor imports an image to be used in her lecture, she could
be prompted to provide an alternative representation of that image.

If it has been determined that the author must provide real-time supplements,
but no preparation time or assistant
author are available, then in addition to allowing the author control
of the nature and timing of prompting, the authoring tool can facilitate
the inclusion of supplements by:

Implementing the equivalent alternatives management functionality
(see Checkpoint 3.5). This way,
if the author uses an object that has been used before, the tool can
suggest the previously stored alternative, which the author can quickly
accept or decline without substantial workflow disruption.

Providing a voice recognition capability so that the author's real-time
speech input can be converted into captioning.

Figure 3.3.6: Real-time presentation
in a Whiteboard/Chat environment. Notice the functionality for requesting
whiteboard descriptions, volunteering to be the secondary author (describer),
and describing a whiteboard object even as the dialog continues. [d]
(Source: mockup by AUWG).

Technique 3.3.5: At a minimum, provide context-sensitive
help with the accessibility checking required by ATAG Checkpoint 3.2.

Technique 3.3.6: Where a tool is able to detect site-wide
errors, allow the author to make site-wide corrections. This should not
be used equivalents alternatives when the function
is not known with certainty (see
ATAG Checkpoint 3.4).
[@@changed@@]

Techniques for Success Criteria 1: When the author inserts an unrecognized
non-text object, the tool must not insert an automatically generated text equivalent
(e.g. label generated from the file name).

Technique 3.4.1: If the author has not specified an alternative
equivalent, default to leaving out the relevant attribute, rather than including
the attribute with no value or with automatically-generated content. Leaving
out the attribute will increase the probability that the problem will be
detected by checking algorithms (see Techniques for ATAG
checkpoint 5.1).

Techniques for Success Criteria 2: When the author inserts a non-text object
for which the tool has a previously authored equivalent (i.e. created by the
author, tool designer, pre-authored content developer, etc.), but the function
of the object is not known with certainty, the tool must prompt the author to
confirm insertion of the equivalent. However, where the function of the non-text
object is known with certainty (e.g. "home button" on a navigation
bar, etc.), the tool may automatically insert the equivalent.

Technique 3.4.3: The function of objects is considered
to be known with certainty when they are used throughout a Web site in a
standard way (e.g., graphical navigation bars). In this case, the objects
should have standard alternative information. Where an object has already
been used in a document, the tool should offer the alternative information
that was supplied for the first or most recent use as a default. If the
user changes the alternative content, they might be asked whether all instances
of the object should have their alternative content updated with the new
value.

Note: This checkpoint is priority 3 and is, therefore, not required
to be implemented in order for a tool to conform to ATAG 2.0 at the single-A
and double-AA levels. However, implementing this checkpoint has the potential
to simplify the satisfaction of several higher priority checkpoints (ATAG checkpoint
3.1, ATAG checkpoint 3.2, and ATAG checkpoint 3.3) and improve the usability
of the tool.

Techniques for Success Criteria 1: When non-text objects have been previously
inserted using the tool, the tool must suggest any previously authored textual
equivalents for that non-text object.

Technique 3.5.1: Maintain a registry that associates
object identity information with alternative information (this could be
done with the Resource Description Framework (RDF) [RDF10]). Whenever an object
is used and an equivalent alternative is collected (see ATAG Checkpoint 3.1) add the object (or identifying
information) and the alternative information to the database. In the case
of a text equivalent, the alternate information
may be stored in the document source. For more substantial information (such
as video captions or audio descriptions), the information may be stored
externally and linked from the document source. Allow different alternative
information to be associated with a single object.

Technique 3.5.2: Stored alternative information can be
presented to the author as default text in the appropriate field, whenever
one of the associated files is inserted into the author's document. This
satisfies ATAG Checkpoint
3.4 because the equivalent alternatives are not automatically generated
and they are only reused with author confirmation.

Technique 3.5.3: When no stored 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 ATAG 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.

Technique 3.5.4: The stored alternative information required
for ATAG Checkpoint 3.4 might be part of the management
system, allowing the alternative equivalents to be retrieved whenever the
prepackaged objects are inserted.

Techniques for Success Criteria 1: The tool must provide the author with an
option to view a listing of all current accessibility problems.

Promoting accessibility in help and documentation:

Because authors are likely to differ widely in their familiarity with Web
content accessibility issues, the help and documentation of the authoring tool
must address several types of use. The checkpoint requirements for this section
include documenting accessible content promoting features (Checkpoint 3.7),
ensuring that accessibility solutions are modeled in the documentation and help(Checkpoint
3.8), and including suggested workflow instructions for using the tool to produce
accessible content (Checkpoint 3.9).

ATAG Checkpoint 3.7 : Document
all features that promote the production of accessible content. [Priority
1]

Techniques for Success Criteria 1: All features that play a role in creating
accessible content must be documented in the help system.

Technique 3.7.1: Ensure that the help system can answer
the following questions: "What features of the tool encourage the production
of accessible content?" and "How are these features operated?".

Technique 3.7.2: Provide direct links from the features
to context sensitive help on how to operate the features. (i.e., the link
might originate with icons, outlining or other emphasis within the user
interface).

Technique 3.7.3: Provide links from within the help text
to relevant automated correction utilities.

ATAG Checkpoint 3.8:
Ensure that accessibility is modeled in all documentation and help, including
examples. [Priority 2]

Techniques for Success Criteria 1: All examples of markup code and views of
the user interface (dialog screenshots, etc.) must meet the requirements
of WCAG, regardless of whether the examples are intended to demonstrate accessibility
authoring practices.

Technique 3.8.1: In the documentation, ensure that all
code examples pass the accessibility checking mechanism required for checkpoint
3.1, regardless of what aspect of the code, the example is meant to show.

Technique 3.8.2: In the documentation, provide at least
one model of each accessibility practice in the relevant
WCAG techniques document for each language supported by
the tool. Note: This includes all levels of accessibility
practices, not just Level 1 or 2.

Technique 3.8.3: When the help files of a base tool do
not meet this checkpoint, an accessibility plug-ins that updates the files
is acceptable.

Technique 3.8.4: When explaining the accessibility issues
related to elements that have not been officially deprecated, try to emphasize
the solutions rather than explicitly discouraging the use of the element.

Technique 3.8.6: For tools that include context sensitive
help, implement context-sensitive help for accessibility terms as well as
tasks related to accessibility.

Technique 3.8.7: For tools that include tutorials, provide
a tutorial on checking for and correcting Web accessibility problems.

Technique 3.8.8: Include pointers to more information
on accessible Web authoring, such as WCAG and other accessibility-related
resources,

Technique 3.8.9: Include current versions of, or links
to relevant language specifications in the documentation. This is particularly
relevant for languages that are easily hand edited, such as most XML languages.

ATAG Checkpoint 3.9:
Document the workflow process of using the tool to produce accessible content.
[Priority 3] [@@ed. The term "workflow"
still needs definition.@@]

Techniques for Success Criteria 1: The documentation must contain
suggested content creation workflow descriptions that include how and when to
use the accessibility-related features of the tool.

Technique 3.9.1: Document the sequence of steps that
the author should take, using the tool, in order to increase the likelihood
of producing accessible content. This should take account of any idiosyncrasies
of the tool.

Technique 3.9.2: The section could be prefaced by an
introduction that explains the importance of accessibility for a wide range
of users, from those with disabilities to those with alternative viewers.

Technique 3.9.3: For tools that explain the reasons for
accessibility, take a broad view. For example, do not refer to any particular
accessibility feature as being "for blind authors" or label them with a
"disability" icon. Instead, refer to them as being for "authors who are
not viewing images". Consider emphasizing points in "Auxiliary
Benefits of Accessibility Features", a W3C-WAI resource.

Technique 3.9.4: This documentation could be located
in a dedicated section.

Techniques for Success Criteria 2: For tools that lack a particular accessibility-related
feature, the workflow description must include a workaround for that
feature.

Technique 3.9.5: Tools that lack an accessibility checking
and/or repair feature may point to the relevant WCAG Techniques
document for the language. Note: this will not suffice to meet the checkpoints
related to accessibility checking (ATAG Checkpoint 3.1)
and repair (ATAG Checkpoint 3.2).