@@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 the priority for accessible means of completing
an authoring tasks (Checkpoint 4.1), ensuring the availability of accessibility-related
functions (Checkpoint 4.2), and ensuring that accessibility-related functions
fit into the appearance and interactive style of the tool (Checkpoint 4.4).
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. 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.
- The techniques all use the phrasing "can", rather than "must"
or "should". This is intended to reinforce to the reader the non-normative
status of this document. 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".
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. @@change in ATAG GL@@
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.
@@BAF: "logical" grouping rules should take precedence.
If necessary the accessibility options can be on separate pages if easily accessed
through the many flow of the application. Typically this will not be the case.
For example, have an "description" field as a part of an image selection
dialog is both natural and appropriate.@@
Techniques for:
Success Criteria 1: Continuously active processes (e.g. a checker that
underlines errors as they occur, a checker that runs at each save, a checker
that runs every 10 minutes, etc.) that implement functions required by checkpoints
3.1, 3.2, 3.3 and 3.7 must be enabled by default.
 |
Technique 4.2.1: Optional continuously active processes
controlled by preference settings can be active by default. |
Example 4.2.1: This illustration
shows the preference setting area of an authoring tool, open to an "Accessibility"
section. Settings that control continuously active processes are circled
in red. (Source: mockup by AUWG)
[longdesc missing]
|
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: The tool can inform the author that
disabling any continuously active process may cause accessibility problems
that might not occur otherwise. |
Example 4.2.2: This illustration shows a dialog box that is activated
if the author unchecks a "highlighting accessibility related fields"
feature, as shown in figure 4.2.1. Notice
that the wording used in this example makes reference to the possibility
that documents will be "less accessible to many users" and that
"in some jurisdictions accessibility is a legal requirement".
(Source: mockup by AUWG)
[longdesc missing] |
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
(e.g. prompting for file names during saves or checking for and repairing spelling
or syntax errors).
@@JR: the techniques here are pretty weak - we must ensure
they relate to success criteria@@
@@MIRROR 4.3.4 -> 4.3.7 APPROACH HERE@@
| |
|
| |
|
| |
|
| |
|
| |
Technique 4.2.3: Accessibility
features, such as short text label and long description attributes, can
appear on the same dialog as the source attribute. |
| |
Technique 4.2.4: Efficient and fast
access to accessibility-related settings with as few steps as possible is
needed to make any changes that will generate accessible content. (@@KM concerned about this@@)
|
| |
Technique 4.2.5: If
a single checker tool is implemented to detect spelling errors and accessibility
problems, the design can ensure equal visibility for the accessibility checking
component: @@JR@@
@@BAF spelling is an example of a verification action. this may lead
one to think its the only one (ie if no spell check, we can ignore this).@@ |
| |
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@@ |
ATAG Checkpoint 4.3:
Ensure that accessible authoring practices 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, checking, and repair functions and documentations must
occur before completion of authoring workflow. [@@note to us: this allows accessibility
checking to be the last step in workflow, if necessary@@][@@wording is still
flexible@@] [@@maybe we can allow authoring to define scope of workflow with
input from author@@]
|
|
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. |
| 1. 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]
|
2. 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, or page generation.
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. |
Example 4.3.1(b): This illustration shows a "Save As" dialog
box that is an example of a scheduled interruption. The author is alerted
to the existence of accessibility problems and has the option to attend
to the problems immediately following the save operation. (Source: mockup
by AUWG)
 [longdesc
missing]
|
3. 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. |
Example 4.3.1(c): This illustration shows an example of an immediate interruption
of the author's workflow. The author must press the "OK" button
on the dialog box to continue. (Source: mockup by AUWG)
 [longdesc missing]
|
| |
Technique 4.3.2: Accessibility problems can be detected
and immediately highlighted when documents are opened, when an editing or
insertion action is completed, or while an author is editing. |
| |
Technique 4.3.3: 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 seperately than presentation
- swappable styles@@
|
|
Technique 4.3.4: Prompting can be integrated 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.4: This illustration shows a wizard (indirect authoring) interface
that prompts the author for a few key pieces of information that will
then be used to generate a complete page; a gallery page in this case.
Since this step of the wizard includes a "Finish" button, this
is a suitable place to add the accessibility-related prompts ("label"
and "description"). Placing these prompts later in the process
would allow the author to bypass them. (Source: mockup by AUWG)
 [longdesc
missing] |
|
|
Technique 4.3.5: Checking can
be integrated into sequencing mechanisms (e.g. design aids, wizards, templates) |
|
Example: See 4.3.5 @@TEMPLATE@@
|
|
|
Technique 4.3.6: Repair can be
integrated into sequencing mechanisms (e.g. design aids, wizards, templates) |
|
Example 4.3.6: This illustration
shows ... @@PROCESS OF CONSTRUCTING CONTENT AND STRUCTURE BEFORE STYLING@@
|
|
|
Technique 4.3.7: Immediate access
to some basic accessibility documentation and one-step access to more
comprehensive documentation can be provided to support the author as needed. |
Example 4.3.7: This illustration shows an accessibility
checker with some limited short label authoring tips listed beneath the
text entry area as well as a button linking to the full documentation.
(Source: mockup by AUWG)
 [longdesc
missing]
|
|
|
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 a lack of header cells. To address this problem,
the tool asks whether this "is a row of table headers". If the
author answers "Yes", then the tool can make the repair automatically.
In the third step (Figure 4.3.8(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 asks the author whether this "merged cell
is a header for the column headers below it". If the author answers
"Yes", then the tool can repair the table structure accordingly.
In all three steps, key terms are linked directly to the help documentation.
(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)."
@@change in GL@@
@@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. (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,b): These illustrations compare a syntax checker and an
accessibility checker in a code-level authoring tool. (Source: mockup
by AUWG )
 [longdesc
missing] |
Example 4.4.2(c,d): These illustrations compare a spell checker and an
accessibility checker. (Source: mockup by AUWG )
 [longdesc
missing]
|
|
|
Technique 4.4.3: For accessibility
accessibility-related documentation use authoring interfaces similar to
other documentation in the tool. |
Example 4.4.3: This illustration
shows how the accessibility documentation for a tool might look within
the main documentation feature. (Source: mockup by AUWG)
 [longdesc
missing]
|
|
|
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 or more authors.
Techniques for
Success Criteria 1: The configurability of functions related to accessibility
prompting, checking, repair,
and documentation must be equivalent to that of
comparable functions in terms of number of options controllable by the author
and the degree to which each option can be controlled.
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: Worked up 2-page example could cover lots of checkpoints etc. (Implementation
Example)
Inclined to be less generous about how far an example applies. (more focussed=less
icons per example)
Success Critera headers with full succ_crit text: OK
Technique numbering: OK
Contents | Guideline 1 |
Guideline 2 | Guideline 3
| Guideline 4 | References
