OVERALL NOTES ON FORMAT
- KM: Icons more visible - want more whitespace - tables do allow this (so
do other ways).~60 chars per line good for readability
- JR: icons seem to work best for examples not techniques
- CMN: WG could work up 2-page example that could cover lots of checkpoints
etc. (Implementation Example)
- CMN: Inclined to be less generous about how far an example applies. (more
focused=less icons per example)
- Success Criteria headers with full succ_crit text: OK
- Technique numbering: OK
@@Notes while editing@@
- @@Should we include specific examples for the well known XML applications
(SVG, SMIL, MathML, VRML, WAP, etc)? -> make sure to keep up to date with
WCAG@@
- @@Editor note: As part of the techniques writing process, changes are being
made to the text of success criteria and checkpoints. Once approved, these
changes need to be made back in the guideline document.@@
Introduction to Guideline 4:
This guideline requires that authoring tools must promote
accessible authoring practices within the tool as well as smoothly integrate
any functions added to meet the other requirements in this document. The checkpoint
requirements for this section include ensuring that accessibility practices
and features are given authoring interface priority (Checkpoint 4.1), clear
availability (Checkpoint 4.2), workflow integration (Checkpoint 4.3), natural
integration with the appearance and interactive style of the tool (Checkpoint
4.4), and sufficient configurability (Checkpoint 4.5)
Checkpoints in Guideline 4:
- Techniques for checkpoint 4.1 Ensure
that the most accessible option for an authoring task is given priority. [Priority
2]
- Techniques for checkpoint 4.2 Ensure
that accessibility prompting, checking, repair functions, and documentation
are always clearly available to the author [Priority 2]
- Techniques for checkpoint 4.3 Ensure that
accessibility prompting, checking, repair functions, and documentation are
integrated into the workflow of Web content development. [Priority 2]
- Techniques for checkpoint 4.4 Ensure
that accessibility prompting, checking, repair functions, and documentation
are naturally integrated into the appearance and interactive style of the
tool. [Priority 3]
- Techniques for checkpoint 4.5 Ensure that
accessibility prompting, checking, repair, and documentation functions are
configurable [Priority 3]
Notes:
- These techniques are informative (non-normative). There are no claims made,
implicit or explicit, that by following any of the techniques in this document
any conformance requirements of the ATAG2.0 WD will be satisfied. Rather,
these techniques represent an illustrative sampling of approaches that might
be useful in considering the subject of authoring tool accessibility. There
may be many other ways a tool might be designed and still meet the normative
criteria contained in the success criteria. It should be noted that some techniques
are so important to meeting their respective success criteria, that for all
practical purposes, the techniques are required. These techniques have been
marked with the term "STRONGLY SUGGESTED".
- For purposes of clarity, the techniques are phrased using a imperative voice.
Nevertheless, the techniques remain informative (non-normative).
ATAG Checkpoint 4.1: Ensure
that the most accessible option for an authoring task is given priority. [Priority
2]
Rationale: Authors are most likely to use the first and easiest
options.
Techniques for Success Criteria 1: When an authoring action has more
than one markup implementation (e.g. the color of text can be changed with presentation
markup or style sheets), those markup implementations that meet the requirements
of WCAG must have equal or higher prominence
than those markup implementations that do not meet the WCAG requirements.
Technique
4.1.1: If there are two or more authoring options for performing
the same authoring task (e.g. setting color, inserting multimedia, etc.),
and one option results in content that meets WCAG and the other does not,
the more accessible option should be given authoring
interface prominence.
(See Example 4.1.1) See the definition
of the term "prominence" for more information. [STRONGLY SUGGESTED]
Example 4.1.1: This illustration shows an authoring tool that supports
two methods for setting text color: using CSS and using font.
Since using CSS is the more accessible option, it is given a higher prominence
within the authoring interface by: (1) the "CSS Styling" option
appearing above the "FONT Styling" option in the drop down Text
menu, and (2) the CSS styling option being used to implement the one-click
text color formatting button in the tool bar. (Source: mockup by AUWG)
[longdesc missing]
Technique
4.1.2: Completely removing less accessible options simplifies the
task of meeting this success criteria.
ATAG Checkpoint 4.2: Ensure
that accessibility prompting, checking, repair functions, and documentation are
always clearly available to the author [Priority 2]
Rationale: If the features that support accessible authoring
are difficult to find and activate, they are less likely to be used. Ideally,
these features should be turned on by default.
Techniques for Success Criteria 1: Continuously
active processes that implement accessibility prompting, checking,
repair, and documentation functions must be enabled by default.@@rewording@@
Technique 4.2.1: Make any continuously
active processes related to accessibility that can be turned on or off (e.g.
"as you type"-style checkers), active by default.@@rewording@@
Techniques for Success Criteria 2: If the author chooses to disable
these continuously active processes, then the tool must inform
the author of the consequences of their choice.
Technique 4.2.2: Inform the author that
disabling any continuously active process may cause accessibility problems
that might not occur otherwise. @@rewording@@
Techniques for Success Criteria 3: The accessibility
prompting, checking, repair, and documentation must have at least the
same prominence as prompting, checking, repair, and documentation for other mandatory information in the tool critical
to content correctness(e.g. prompting for file names during saves or checking
for and repairing spelling or syntax errors).
Technique 4.2.3: Prompting for accessibility information
has the same prominence as prompting for information critical to content correctness.
For example, a tool that prompts the author for file name attributes required
to reference a multimedia object will have prompts with the same prominence
for short text labels and long descriptions for that object
Technique 4.2.4: Checking and repairing accessibility problems
has the same prominence as checking for information critical to content correctness.
For example, a tool that checks for spelling, grammar, or code syntax will
have checks with the same prominence for accessibility problems.
Example 4.2.4: This illustration shows an authoring interface that checks
for and displays spelling and accessibility errors with the same prominence.
In this case, the author has activated a right-click pop-up menu that includes
spelling and accessibility repair options. (Source: mockup by AUWG)
Technique 4.2.5: Documentation for accessibility has the
same prominence as documentation for information critical to content correctness.
For example, a tool that documents any aspect of its operation will have documentation
with the same prominence for accessibility.
General Techniques for Checkpoint 4.2:
Technique 4.2.6: Sometimes several input
fields must be filled in order to make a single element accessible. Instead
of dispersing these prompts over multiple dialog boxes, it can be more effective
to draw them together into one group of controls with a visible tab or other
method for accessing the group.@@new-from intro text@
Technique 4.2.7: When determining prominence,
control grouping rules usually takes precedence. (e.g. including a fields
for adding a label and a description to an image insertion dialog). @@from
BAF comment@@
ATAG Checkpoint 4.3:
Ensure that accessibility prompting, checking, repair functions, and documentation
are integrated into the workflow
of Web content development. [Priority 2]
Rationale: Accessible design as an afterthought or separate
process is much more onerous and therefore costly than when accessibility is
considered from the start. If the authoring tool supports a workflow in which
the author considers accessibility before and/or during the authoring process
it is more likely that accessible authoring practices will become a common practice.
This is analogous to internationalization, which is much easier when it is considered
from the beginning rather than handled last.
Techniques for Success Criteria 1: Accessibility
prompting must be integrated into all features that assist with author
decision-making (e.g. templates, wizards, and instruction text). Accessibility
checking, repair, and documentation functions must be made available before completion
of any authoring workflow.
Technique 4.3.1: Optimize the timing of prompting, checking,
and repair functions. Authoring accessible documents should be as efficient
as possible. Prompting, should be timed so that accessibility problems are
prevented whenever possible and, when not possible, checking, and repair should
occur when the accessibility problem is easily reversible. Integrated guidance
in creating accessible content from the beginning of the workflow will avert
the need for more disruptive checking and repair later in the workflow. Timing
options include: Negotiated Interruption, Scheduled
Interruption, and Immediate Interruption.
(a) Negotiated Interruption:
A negotiated interruption is caused by interface mechanisms (e.g. icons
or highlighting of the element, audio feedback) that alert the author to
a problem, but remain flexible enough to allow the author to decide whether
to take immediate action or address the issue at a later time. Since negotiated
interruptions are less intrusive than immediate or scheduled interruptions,
they can often be better integrated into the design workflow and have the
added benefit of informing the author about the distribution of problems
within the document. Although some authors may choose to ignore the alerts
completely, it is not recommended that authors be forced to fix
problems as they occur. Instead, it is recommended that negotiated interruption
be supplemented by scheduled interruptions at major
editing events (e.g., when publishing), when the tool should alert the
author to the outstanding accessibility problems.
Example 4.3.1(a): This illustration shows an example of a negotiated interruption.
The author is made aware of problems detected automatically by means of
a blue squiggly line around or under rendered elements with accessibility
problems. The author can decide to address the problems at a later time.
(Source: mockup by AUWG)
[longdesc missing]
(b) 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
opening, saving, closing, committing, or publishing
files. 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 (see Figure 4.3.1(b)), publishing, printing,
etc.. A potential downside of postponing corrective actions is that by the
time the prompt is displayed, the author may not have sufficient time or
inclination to make the required changes, especially if they are extensive.
(c) Immediate Interruption:
An immediate interruption is the most intrusive timing option because the
attention of the author 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, such as when an author decides to publish the content in question.
In general, negotiated and scheduled interruptions are preferred.
Technique 4.3.2: 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:
(a) 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.
(b)
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).
(c)
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.
(d)
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 4.3.2: 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 4.3.3: Detect and immediately highlight accessibility
problems when documents are opened, when an editing or insertion action is
completed, or while an author is editing.
Technique 4.3.4: If intrusive warnings are used, provide
a means for the author to select a less obtrusive method of alerting.
Techniques for Success Criteria 2: Any mechanism that guides the
author in sequencing authoring actions (e.g. design aids, wizards, templates,
etc.) must integrate accessibility prompting,
checking, repair functions, and documentation.
@@ BAF: Wizards are the way to go: . Repair tools can address
pre-existing content or content edits after use of a wizard (assuming you cannot
reenter the wizard). @@ @@BAF: wizards etc should be a major prompting mechanism.
Many samples should be shown such as the table example.@@ @@GP would like to
de-emphasize wizards a bit.@@
@@JT: Maybe have an example showing a template....?NTS?@@
@@JT: We need to have new techniques for tools that could
try to get author to put down structure first and separately than presentation
- swappable styles@@
Technique 4.3.5: Integrate prompting
into sequencing mechanisms (e.g. design aids, wizards, templates) at a point
early enough in the authoring process that there is less chance that it will
be bypassed.
Example 4.3.5: This illustration shows three screens of a page building
wizard (indirect authoring). The wizard prompts the author for a few key
pieces of information that are used to tailor the process, in this case
to create a gallery page. Since the accessibility-related prompts ("label"
and "description") occur on the third step of the wizard, the
"Finish" button is unavailable until then to prevent the author
from bypassing this step. (Source: mockup by AUWG)
[longdesc missing]
Technique 4.3.6: Integrate checking
and repairing into sequencing mechanisms (e.g. design aids, wizards, templates).
Example 4.3.6: This illustration shows the wizard screen that immediately
follows the sequence in Example 4.3.6. Since no text was entered in the
description field, checking, and repairing occurs immediately in the sequence
of the wizard interface. (Source: mockup by AUWG)
Technique 4.3.7: Provide the author
with immediate access to some basic accessibility documentation and one-step
access to more comprehensive documentation.
Technique 4.3.8: A tight coupling between all of the accessibility-related
functions leads to a more seamless authoring experience.
Example 4.3.8(a,b,c): This illustration shows a sequence of steps through
a WYSIWYG interface in which prompting, checking, repair, and documentation
of accessibility issues are all integrated into the process of creating
a table. In the first step (Figure 4.3.8(a)), the author has requested
that a table be inserted. The tool prompts the author for accessibility
information (i.e. caption and summary) at the same time as it prompts
for the number of rows and columns, etc. The tool assists the author by
filling both fields with known information (i.e. that this is the 3rd
table in the document). In the second step (Figure 4.3.8(b)), as the author
finishes filling in the top row of cells, the tool has checked the structure
of the table and found that no header cells have been defined. To address
this problem, the tool highlights the top row of the table. When the author
selects the highlighted area a drop-down is displayed that lets the user
choose whether to let the tool make the repair or ignore the problem.
In the third step (Figure 4.3.9(c)), the author has added a new row to
the top of the table and merged two cells in this new top row. The tool
again checks the table and facilitates the repair. In all three steps,
help documentation is within easy reach. (Source: mockup by AUWG)
[longdesc
missing]
ATAG
Checkpoint 4.4: Ensure that accessibility prompting, checking, repair
functions, and documentation are naturally integrated into the appearance and
interactive style of the tool. [Priority 3]
Rationale: Most authors are reluctant to use features that
depart from the conventions of a tool. Detachment
of accessibility modules also decreases the likelihood that authors will check
for and repair accessibility problems with their code.
Techniques for Success Criteria 1: The
authoring interface for accessibility prompting, checking, repair, and
documentation must match the authoring
interface for comparable functions in terms of the following characteristics:
(1) visual design (measured by design metaphors, artistic sophistication, sizes,
fonts, colors), (2) operation (measured by degree of automation, number of actions
for activation), and (3) comprehensiveness (measured by breadth and depth of
functionality coverage).
@@BAF: This one tends to be the default case (one would
rarely use a different style for accessibility prompting vs other prompting)
so we need to make this more a thing to look out for vs a conscious design action.
We should include other samples in the pattern below.@@
Technique 4.4.1: For accessibility
prompting, use authoring interfaces similar to prompting for information
that is required for proper functioning of the tool.
Example 4.4.1: This illustration shows a dialog box in which the prompting
for a text label and a long description matches that for the required src
attribute. The three three input fields match in terms of their size, font,
color, label spacing, and operation (ex. src and longdesc
have matching abilities to browse for file names). When additional functionality
for creating a new description is added to the longdesc field,
the icon used is consistent with the visual style of other icons in the
interface. (Source: mockup by AUWG )
[longdesc
missing]
Technique 4.4.2: For accessibility
checking and repair, use authoring interfaces similar to code syntax or spelling
checking and repair.
Example 4.4.2(a): This illustration shows a code-level authoring tool
with syntax and accessibility checking. In both cases, the mechanism used
to alert the author to problems is text color highlighting. The design
of the two mechanisms is thus identical, except that different colors
are used to differentiate one type of problem from the other. A status
line display at the bottom of the window provides some manual repair advice.
(Source: mockups by AUWG )
[longdesc
missing]
Technique 4.4.3: For accessibility
accessibility-related documentation, use authoring interfaces similar to
other documentation in the tool.
Technique 4.4.4: Provide a common toolkit to aid in designing
additional tool functionality modules. This might be used internally or by
third party developers to develop accessibility plug-ins with the same look
and feel as other parts of the tool.
Technique 4.4.5: Design accessibility features as integral
components of the authoring tool, not components that need to be separately
installed or executed.
ATAG
Checkpoint 4.5: Ensure that accessibility prompting, checking, repair, and
documentation functions are configurable. [Priority
3]
Rationale: A configurable tool is more likely to be adaptable
to the work habits of more authors.
Techniques for Success Criteria 1: All functions related to accessibility
prompting, checking, repair,
and documentation must match the other prompting,
checking, repair, and documentation functions of the tool (respectively), in
terms of the number of options controllable by the author and the degree to
which each option can be controlled.
Technique
4.5.1: Provide author configurability. Author acceptance of the accessibility
features of an authoring tool can depend on the degree to which these features
are integrated into the existing workflows of authors. Author configurability
can help naturally incorporate accessibility-related authoring tasks into
the regular workflow of the author. Useful configuration
options include (see Figure 4.5.1):
- the nature of the accessibility guidance they wish to receive,
- the degree to which the prompts are highlighted in the interface,
- the nature and timing of any automated accessibility features (e.g. accessibility
checking or repairing utilities), and
- which accessibility standards they wish to follow, and where applicable,
to which level.
Technique 4.5.2: Include alerts for high priority WCAG
checkpoints in the default configuration.
Technique 4.5.3: Allow authors to choose different alert
mechanisms based on the priority of accessibility problems.
Technique 4.5.4: CSS classes can be used to indicate
accessibility problems enabling the author to easily configure the presentation
of errors.@@more detailed than usual@@
Technique 4.5.4:
Contents | Guideline 1 |
Guideline 2 | Guideline 3
| Guideline 4 | References
[longdesc missing]
[longdesc
missing]
[longdesc
missing]
[longdesc
missing]
[longdesc missing]
[longdesc
missing]
[longdesc
missing]
[longdesc
missing]
[longdesc
missing] @@other mockup removed@@