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:
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 the author has more than one markup implementation to choose from (e.g. the color of text can be changed with presentation markup or style sheets), those markup implementations that conform to 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.
Techniques for Success Criteria 2: When the author is presented
with a list of choices, that includes choices of formats or authoring practices
that do not support content that conforms to WCAG, these should be marked
to indicate that the choice may produce content that is inaccessible.
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: All accessibility prompting, checking, repair functions and documentation
must meet the following conditions:
(a) if they are continuously active, then it must always be enabled by default and if the author disables it (e.g. from a preferences screen), then the tool must always inform the author that this may allow accessibility problems to be introduced.
(b) they must have at least the same prominence as the same type of function (i.e. prompting, checking, repair and documentation) related to other kinds of information (e.g. markup validity, program code syntax, etc.).
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.
Technique 4.2.2: Inform the author
that disabling any continuously active process may cause accessibility problems
that might not occur otherwise.
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.
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).
ATAG
Checkpoint 4.3: Ensure
that sequential authoring processes integrate accessible authoring practices. [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, 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
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.
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, 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. 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.3: Allow authors to choose different alert
mechanisms based on the priority of accessibility problems.
Contents | Guideline 1 |
Guideline 2 | Guideline 3
| Guideline 4 | References
[longdesc missing]
[longdesc
missing]
[longdesc
missing]
[longdesc
missing]
[longdesc missing]
[longdesc
missing]
[longdesc
missing]