This support includes prompting and assisting the author to create accessible
web content (Checkpoint 3.1), especially for information that cannot be generated
automatically, checking for accessibility problems (Checkpoint 3.2), and assisting
in the repair of accessibility problems (Checkpoint 3.3). In performing these
functions, the authoring tool must avoid including automatically generated equivalent
alternatives or previously authored equivalent alternatives without author consent
(Checkpoint 3.4). The authoring tool may also provide automated means for managing
equivalent alternatives (Checkpoint 3.5) and provide accessibility status summaries
(Checkpoint 3.6).
Accessibility-related documentation provides support and guidance to the author.
The documentation must accommodate the various levels of author familiarity
with web content accessibility issues. The checkpoint requirements include documenting
accessible content promoting features (Checkpoint 3.7), and ensuring that documentation
demonstrates authoring practices and workflow processes that result in accessible
content (Checkpoint 3.8).
@@more help designing well - e.g. alternatives to image
maps@@
When information is required of 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.
 |
Technique 3.1.1: Use an appropriate prompting and
assisting mechanism |
| |
3.1.1(1):
Prompting and assisting for short text labels (e.g. alternate text, titles,
short text metadata fields, rubies for ideograms):
- (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 rendered view of the object can be provided for the author to
examine while composing the label.
- (c) Short text labels are a good candidate for storage and reuse (see
Techniques for ATAG checkpoint 4.4)
- (d) Automated routines can be implemented to detect and offer labels
for objects serving special functions (e.g. "decorative",
"button", "spacer", "horizontal rule",
etc.).
- (e) An editable text entry box with a drop-down list can accommodate
new text entry as well as the option to select from reusable or special
function label text.
|
Example 3.1.1(1a): This illustration shows an authoring interface for
description reuse. It is comprised of a drop-down list that is shown with
several short labels for the same image. Notice that one of the labels
in the list is in a different language (i.e. French). The author must
be able to create a new label, if the stored strings are not appropriate.
(Source: mockup by AUWG)
 [longdesc
missing]
|
Example 3.1.1(1b): This illustration shows a code-based authoring interface
for short text label prompting. The author has just typed quotation marks
(") to close the href attribute. (Source: mockup by
AUWG)
 [longdesc
missing] |
| |
3.1.1(2):
Prompting and assisting for multiple text labels (e.g. image map area
labels):
- (a) Prompts for image map text labels can be similar to those for
short text labels with allowance
made for rapidly adding several labels for one image map.
- (b) A preview of the image map areas can be provided.
- (c) The URI of the image map areas can be provided.
- (d) The tool can offer to automatically generate a set of plain text
links from the labels.
|
Example 3.1.1(2): This illustration shows an authoring interface for image
map area text label prompting. It is comprised of a list with two columns.
In the right-hand column is the URL for each image map area. This can
be used as a hint by the author as they fill in a label text entry in
the left-hand column. A checkbox at the bottom provides the option of
using this label text to create a set of text links below the image map.
(Source: mockup by AUWG)
 [longdesc
missing]
|
| |
3.1.1(3):
Prompting and assisting for long text descriptions (e.g. longdesc text,
table summaries, site information, long text metadata fields):
- (a) The author can first be prompted as to whether the inserted object
is adequately described. Providing a "no images" view of the
page may help them decide.
- (b) If the short description is inadequate, the author can be prompted
for the location of a pre-existing description.
- (c) If the author needs to create a description, a special writing
utility can be provided (that can include a rendered view of the object
and description writing pointers).
- (d) Long descriptions are a good candidate for storage and reuse (see
Techniques for ATAG checkpoint 4.4)
- (e) Automated routines that detect and ignore some objects that do
not require long text descriptions (e.g. bullets, spacers, horizontal
rules).
|
Example 3.1.1(3): This illustration shows an authoring interface for long
text description prompting. A "description required" checkbox
controls whether the rest of the interface is available. If a description
is required, the author then has the choice of opening an existing description
file or writing (and saving) a new one. (Source: mockup by AUWG)
[longdesc missing]
Modify to show existing.
|
| |
3.1.1(4): Prompting and assisting for form field labels:
- (a) Present the form fields and ask the author to select text that
is serving as a label or to enter a new label.
- (b) Alert authors to form fields that are missing labels.
|
| |
Example 3.1.2(4): This
illustration shows a form properties list that allows the
user author to simultaneously decide the field labels, tab
order, form field place holders and accesskeys. (Source: mockup by AUWG)
 [longdesc
missing]
@@Modify to show what happens when label is missing@@ |
| |
3.1.1(5): Prompting and assisting for form field place-holders:
- (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.
|
| |
3.1.1(6): Prompting and assisting for TAB order sequence:
- (a) The author can be provided with a numbering tool that they can
use to select controls to create a TAB preferred sequence. (See Example
3.1.2(4))
- (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) Provide a links/controls list to check the TAB order.
@@needs its own example@@ |
| |
3.1.1(7): Prompting and assisting for navigational shortcuts (e.g.
keyboard shortcuts, skip links, voice commands, etc.):
- (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.
- (b) Accesskey lists can be managed to ensure consistency across sites
and to prevent conflicts within pages.(See Example
3.1.1(7b))
|
Example 3.1.1(7b): This illustration shows a code-based authoring interface
suggesting accesskey values. Notice that "m" is the first suggestion,
as it is the first letter of the link text, "moon". "c"
does not appear in the list as it is already used elsewhere in the document.
(Source: mockup by AUWG)
 [longdesc
missing]
@@mistake in mockup - double moon@@
@@provide an example of (a)@@
@@link rel???, skip links@@ |
| |
3.1.1(8): Prompting and assisting for contrasting colors:
- (a) When a foreground or background color is defined the color choices
provided to the author can be pre-screened for contrast.
- (b) Color palettes can be assembled with problematic colors excluded
(see Example 3.1.1(8)) or flagged.
- (c) Provide gray scale and black and white views or suggest the author
activate the system operating system high contrast mode.
|
Example 3.1.1(8):
This illustration shows an authoring interface for choosing a
text color. The palette has been filtered so that sufficient contrast
between the text and the current background color is assured. (Source:
mockup by AUWG)
 [longdesc
missing] |
| |
3.1.1(9):
Prompting and assisting for alternative resources for multimedia (transcripts,
captions, video transcripts, audio descriptions, signed translations,
still images, etc.):
- (a) The author can be prompted for the location of a pre-existing
alternative resources for multimedia (see Example
3.1.1(9)).
- (b) Although producing alternative resource for multimedia can be
a complex process for long media files, production suites do exist or
authoring tools can include simple utilities, with built-in media players,
for producing simple alternative resources.
- (c) Alternative resources for multimedia are good candidates for storage
and reuse (see Techniques for ATAG
checkpoint 3.4)
- (d) The tool should be able to access alternative resources for multimedia,
which may be incorporated into existing media or exist separately.
|
Example 3.1.1(9): This
illustration shows an authoring interface for embedding a video. The tool
automatically detects whether captions, video transcript, described audio,
or signed translation are present. For some items, links to utilities
to create them are available. (Source: mockup by AUWG)
 [longdesc
missing]
|
| |
3.1.2(10): Metadata:
[@@changed, metadata is actually just a special case of all the
other things in this list @@] @@[@@OPEN WORK ITEM: LEFT HERE AS A PLACEHOLDER]@@
(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.KM(new) (c) Check for DOCTYPE and refer to
Help if author is unsure of which to chooseKM(new) (d) Check that Metatags do not violate
WCAG such as refreshing not controllable by author. |
| |
3.1.1(11): Prompting and assisting for
document structure:
[@@OPEN WORK ITEM: this could be greatly expanded
to take into account highly structured (e.g. XSLT)
authoring @@]
- (a) The tool can offer to
transform presentation markup that is
misused to convey structure into structural markup (e.g. headings,
sub-headings, etc.), with style sheets used to retain the same appearance.
- (b) Formatting conventions such as a number of consecutive paragraphs
beginning with a bullet character (this may be a "bullet" or another
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)
|
Example
3.1.1(11): This illustration shows a tool that prompts for structural
information. (Source: mockup by AUWG)
[longdesc missing] |
| |
3.1.1(12): Prompting and assisting for
tabular structure:
- (a) The tool can prompt the author
to identify tables as used for layout or data or implement automated
detection mechanisms.
- (b) Differentiate utilities for table structure from utilities for
document layout - use this when tables are identified as being for layout.
[STRONGLY SUGGESTED]
- (c) The author can be prompted to provide
header information.
- (d) The author can be prompted to group and split columns, rows, or
blocks of cells that are related.
- (e) The tool can provide the author with a linearized view of tables
(as tablin does).
|
Example 3.1.1(12): This illustration shows a tool that
prompts the author as to whether the top row of a table is a row of table
headers. (Source: mockup by AUWG)
 [longdesc
missing] |
| |
@@OPEN WORK ITEM:
3.1.1(13): Prompting and assisting for style
sheets:
- (a) The tool can offer to
transform structural markup that is misused for style into style sheets
(see "opposite" in 3.1.1(11)).
- (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) Formatting patterns can be recognized and converted to style rules
(e.g. ????).
BUCKET OF LOW DETAIL STUFF
- The tool can offer prompting and/or assistance on using style sheets:
- to control fonts, colors, text sizes
- to specify fallback fonts to promote accessible content
- to specify font characteristics to promote accessible content
- and HTML elements to control fonts to promote accessible content
- to usw color contrast to promote accessible content[@@move-see
3.1.2(9)@@]
- specifying colors to promote accessible content[@@duplicate? -
could all color related items be bundled in 3.1.2(9)@@]
- specifying foreground and background contrast to promote accessible
content[@@duplicate? - could all color related items be bundled
in 3.1.2(9)@@]
- specifying fore- and background colors to promote accessible content
[@@duplicate? - could all color related items be bundled in 3.1.2(9)@@]
- conveying information through multiple means (not just color)
- using relative units of measure
- using of absolute units of measure
- creating stylized text with CSS rather than using raster images
- formatting and positioning of text
- using text style effects
- creating rules and borders
- using text equivalents for content generated by style sheets
- using generated content in the DOM[@@move@@]
- providing contextual clues in lists [@@move@@]
- creating layout, positioning, layering, and alignment
- creating null alt-text to promote accessible content[@@move -
part of 3.1.2(1)@@]
- providing good structural markup for graceful degradation to
promote accessible content[@@move@@]
- using scripting and style sheets
- using ACSS to create auditory presentation
- providing access to alternative representations of content [@@move@@]
- using media types properly
|
| |
3.1.1(14): Prompting and assisting for 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,
terms outside a controlled vocabulary as well as known abbreviation
or acronym expansions.
- (d) The author can be prompted for expansions of unknown acronyms,
recognizable in some languages as collections of uppercase letters.
- (e) Provide an automated reading level status.
|
Example 3.1.1(14): This illustration shows an authoring
interface for indicating the reading level of a page and whether it exceeds
a limit determined by the author's preference settings. (Source: mockup
by AUWG)
[longdesc missing] |
| |
[@@OPEN ISSUE - needs to be strong to cover us
in the programming lang area@@]
3.1.1(15): Prompting and assisting for device independent handlers:
- (a) During code development, the author can be prompted to include
device-independent means of activation.
- (b) Storage and reuse of accessible code, scripts, etc.
Example needed. |
| |
3.1.1(16): Prompting and assisting for non-text supplements to
text:
- (a) The tool can prompt authors to provide icons for buttons, illustrations
for text, graphs for numeric comparisons, etc.
- (b) Where subject metadata is available, the tool can look up appropriate
illustrations.
- (c) If the author has identified content as instructions then the
tool can provide templates or automated utilities for extracting flow
charts, etc.
|
Example 3.1.1(16): This illustration shows an authoring
interface for prompting the author as to whether a number-rich paragraph
might be made more clear with the addition of a chart or graph. (Source:
mockup by AUWG)
 [longdesc
missing]
@@Add metadata example(b)@@ |
| |
3.1.1(17): Prompting and assisting for other
types of accessibility information:
[@@want to keep but not sure where@@]
- (a) 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.
- Prompt for server-side alternatives for essential client-side scripts
(those used for content and navigation) and applets.
- (b) The author can be asked to provide a link to skip over objects
(since some browsers cause objects to permanently capture the tab focus).
- (c) 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.
- (d) When frames are used for a mosaic of images, the tool can allow
inclusion of markup files (with images embedded) rather than images
directly.
- (e) Warn about adjacent links.
|
| |
3.1.1(18): Prompting and assisting the author
to make use of up to date formats:
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.
@@BF: maybe add section to 3.1.1 about guiding author towards use of
XML/XSLT (i.e. most up to date formats)@@ |
| |
Technique 3.1.2: 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:
- an alternative content view (with images and other
multimedia replace by any alternative content),
- a monochrome view (to test contrast),
- a collapsible structure-only view,
- no scripts view
- no frames view
- no style sheet view
|
Example
3.1.2: This illustration shows a WYSIWYG authoring interface with a list
of rendering options displayed. The options include "All" (i.e.
render as in a generic browser), "text-only" (i.e. non-text
items replaced by textual equivalents), "no styles", "no
frames" and "grayscale" (used to check for sufficient contrast).
(Source: mockup by AUWG)
 [longdesc
missing] |
|
|
Technique 3.2.1: Automate as much checking as possible.
Where necessary provide semi-automated checking. Where neither of these
options is reliable, provide manual checking. |
| 1. Automated:
In automated checking, the tool is able to check for accessibility problems
automatically, with no human intervention required. This type of check is
usually appropriate for checks of a syntactic nature, such as the use of
deprecated elements or a missing attribute, in which the meaning of text
or images does not play a role. |
Example 3.2.1(c): This illustration shows a summary interface for a code-based
authoring tool that displays the results of an automated check. (Source:
mockup by AUWG)
[longdesc missing] |
Example 3.2.1(d): This illustration shows an interface that displays the
results of an automated check in a WYSIWYG authoring view using blue squiggly
highlighting around or under rendered elements, identifying accessibility
problems for the author to correct. (Source: mockup by AUWG)
 [longdesc missing] |
Example 3.2.1(e): This illustration shows an authoring interface of an
automated check in a code-level authoring view. In this view, the text
of elements with accessibility problems is shown in a blue font, instead
of the default black font. (Source: mockup by AUWG)
 [longdesc
missing] |
| 2. Semi-Automated:
In semi-automated checking, the tool is able to identify potential problems,
but still requires human judgment by the author to make a final decision
on whether an actual problem exists. Semi-automated checks are usually most
appropriate for problems that are semantic in nature, such as descriptions
of non-text objects, as opposed to purely syntactic problems, such as missing
attributes, that lend themselves more readily to full automation. |
Example 3.2.1(b): This illustration shows a dialog box that appears once
the tool has detected an image without a description attribute. However,
since not all images require description, the author is prompted to make
the final decision. The author can confirm the at this is indeed an accessibility
problem and move on to the repair stage by choosing "Yes". (Source:
mockup by AUWG)
 [longdesc
missing]
|
3.
Manual: In manual checking, 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
decide on their own whether or not a problem exists. Manual checks are
discouraged because they are prone to human error, especially when the
type of problem in question may be easily detected by a more automated
utility, such as an element missing a particular attribute. |
Example 3.2.1(a): This illustration shows a dialog box that reminds the
author to check if there are any words in other languages in the document.
The author can move on to the repair stage by pressing "Yes".
(Source: mockup by AUWG)
 [longdesc
missing] |
|
|
Technique 3.2.2: The Techniques For Accessibility Evaluation
And Repair Tools [WAI-ER @@change to AERT@@]
Public Working Draft document can be consulted for evaluation and repair
algorithms related to WCAG 1.0. |
|
|
Technique 3.3.1: Automate as much repairing as possible.
Where necessary provide semi-automated repairing. Where neither of these
options is reliable, provide manual repairing. |
| 1. Automated:
In automated tools, the tool is able to make repairs automatically, with
no author input required. For example, a tool may be capable of automatically
adding a document type to the header of a file that lacks this information.
In these cases, very little, if any, author notification
is required. This type of repair is usually appropriate for corrections
of a syntactic or repetitive nature. |
Example 3.3.1(c): This illustration shows a sample of an announcement
that an automated repair has been completed. An "undo " button
is provided in case the author wishes to reverse the operation. In some
cases, automated repairs might be completed with no
author notification at all. (Source: mockup by AUWG)
 [longdesc
missing]
|
| 2. Semi-Automated:
In semi-automated repairing, the tool can provide some automated assistance
to the author in performing corrections, but the author's input is still
required before the repair can be complete. For example, the tool may
prompt the author 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. This type of repair
is usually appropriate for corrections of a semantic nature. |
Example 3.3.1(b): This illustration shows a sample of a semi-automated
repair in a WYSIWYG editor. The author has right-clicked on an image highlighted
by the automated checker system. The author must then decide whether the
label text that the tool suggests is appropriate. Whichever option the
author chooses, the tool will handle the details of updating the content.
(Source: mockup by AUWG)
 [longdesc missing]
|
3. Manual:
In manual repairing, the tool provides the author with instructions for
making the necessary correction, but does not automate the task in any
substantial way. For example, the tool may move the cursor to start of
the problem, but since this is not a substantial automation, the repair
would 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 authors and
allows the most opportunity for human error. |
Example 3.3.1(a): This illustration shows a sample manual repair. The
problems have already been detected in the checking step and the selected
offending elements in a code view have been highlighted. However, when
it comes to repairing the problem, the only assistance that the tool provides
is a context sensitive hint. The author is left to make sense of the hint
and perform the repair without any automated assistance. (Source: mockup
by AUWG)
 [longdesc missing]
|
|
|
Technique 3.3.2: Consider implementing a special-purpose
correcting interface. 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 author 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
that includes only the input field(s) for the information currently required.
A further 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 short text label 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). |
Example 3.3.2: This illustration
shows a sample of a special-purpose correction interface. The tool supports
the author's repair task by providing a description of the problem, a
preview (in this case of the image missing a label), tips for performing
the repair, possible repair options (archived from previous repairs) and
other information (in this case the name of the image file). (Source:
mockup by AUWG)
 [longdesc missing]
|
|
|
Technique 3.3.3: Checks can be automatically sequenced.
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 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 that the author 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 author 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
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 "change to" word. The author also has correcting
options, some of which can store responses to affect how the same situation
can be 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 code-based according to 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.
@@Author should know what is the sequencing criteria@@ |
Example 3.3.3: This illustration shows an example of a sequential accessibility
checker, the special-purpose correction interface from Example
3.3.2 is supplemented with navigational controls for moving backwards
and forwards through the list of repair tasks. (Source: mockup by AUWG)
 [longdesc missing]
|
|
|
@@Should this be sent to 4.1???@@
Technique 3.3.4: When authoring tools produce content
in real time, it is usually no longer possible to delay addressing accessibility
problems until an arbitrary point in the future. 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 real-time authoring is consumed by individuals
with no special communicative needs, there may be no need for real-time
prompting. However, as with any other Web content it is often impossible
for the author to know all of the needs of the actual or potential participants.
Therefore, the best practice is to create real-time content that conforms
with WCAG to the greatest extent possible. However, when this is not
possible, a real-time authoring tool might be able to facilitate graceful
degradation of accessibility by polling the participants (see "Request
whiteboard descriptions" checkbox in the figure) or in some cases
checking the profiles of participants (e.g. using CCPP, ACCLIP) to determine
which types of accessibility practices would offer the greatest advantage
in the short time available. Once this information is compiled, the
tool can prompt the author (or see Assistant/Peer
Author) to correct problems appropriately (preferably during Preparation
Time). When it is not possible to know, with certainty, the needs
of all participants, the tool should still assume that accessible content
is required. This is especially true if the results of the session will
be archived.
- Assistant/Peer Author:
In some cases, it may be possible to designate one or more secondary
authors in the live community, who can receive and respond to prompts
for supplemental information generated as the primary author proceeds
uninterrupted. The secondary author might be an unrelated specialist,
analogous to Sign language interpreter, a co-author (helpful for describing
technical drawings, etc.), or in some situations any member of the session
audience (i.e. a peer).
- 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 and the obligation to support accessible authoring
as described elsewhere in this document.
- Archiving: If
the session will be archived, there may be other opportunities to increase
the accessibility of the content of the archive by guiding the author
through a process to check for and repair accessibility problems after
the real-time session has ended, but prior to archiving.
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 management functionality for equivalent alternatives
(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.
|
Example 3.3.4: This illustration shows an a real-time presentation in
a whiteboard/chat environment. Notice the functionality by which the presenter
or an assistant/peer author can describe the events on the whiteboard
even as the dialog continues. (Source: mockup by AUWG).
[longdesc missing]
|
|
|
Technique 3.3.5: Where a tool is able to detect site-wide
errors, allow the author to make site-wide corrections. This should not
be used for equivalent alternatives when the function
is not known with certainty (see
ATAG Checkpoint 3.4). |
|
|
Technique 3.3.6: Provide a mechanism for authors to
navigate sequentially among uncorrected accessibility errors. This allows
the author to quickly scan accessibility problems in context. |
| |
Technique 3.3.7: The Techniques For Accessibility Evaluation
And Repair Tools [WAI-ER @@change to AERT@@]
Public Working Draft document can be consulted for evaluation and repair
algorithms related to WCAG 1.0. |
