Contents | Guideline 1 | Guideline 2 | Guideline 3 | Guideline 4 | References

W3C

Implementation Techniques for
Authoring Tool Accessibility Guidelines 2.0:

Guideline 4: Promote and integrate accessibility solutions

Working Group Draft 25 June 2004

This version:
http://www.w3.org/WAI/AU/2004/WD-ATAG20-20040625/tech4
Latest version:
http://www.w3.org/TR/ATAG20/tech4
ATAG 1.0 Recommendation:
http://www.w3.org/TR/ATAG10
Editors of this chapter:
Jutta Treviranus - ATRC, University of Toronto
Jan Richards - ATRC, University of Toronto
Matt May - W3C

@@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:


Notes:


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@@

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions

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 can be given authoring interface prominence.

Applicable to 'what you see is what you get' authoring functions Example 4.1.1: This illustration shows an authoring tool that supports text colour formatting via two options: using CSS and using font. Since CSS is the more accessible action, it is given a higher prominence within the authoring interface. Specifically, the "CSS Styles" option appears above the "font Styles" option in the drop down Format>Text Color menu and the CSS option is also used to implement the one-click text color formatting button in the tool bar. (Source: mockup by AUWG)
Demonstration of giving CSS higher prominence over font control [longdesc missing]

@@BAF: We should enumerate options:
For a list or combobox: place the accessible items at the top of the list
For a button set: place the accessible items at the left
For menu/toolbars: highlight/emphasize the more accessible options (for example, give them mnemonics)@@ F2F decides the exisitng example is enough@@

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 4.1.2: Completely removing less accessible options can simplify 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.

@@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.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 4.2.1: Optional continuously active processes controlled by preference settings can be active by default.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions 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)
Illustration of how continuously active processes related to accessibility might be controlled via a preferences setting. [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.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions 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.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions 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)
Illustration of how a user might be warned about turned off an accessibility related process [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@@]

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions

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.

Applicable to 'what you see is what you get' authoring functions 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)
Screen shot demonstrating coconfigured interuption[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.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions 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)
Screen shot demonstrating a save as dialog with accessibility warning message[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.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions 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)
Screen shot demonstrating an immediate interruption[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@@

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions

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.

Applicable to Indirect authoring functions 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)
Illustration of a page building wizard with a Web based interface.[longdesc missing]
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions

Technique 4.3.5: Checking can be integrated into sequencing mechanisms (e.g. design aids, wizards, templates)

Example: See 4.3.5 @@TEMPLATE@@

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions

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@@

 

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions

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.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions 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)
Demonstration of an interface providing accessibility tips[longdesc missing]
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 4.3.8: A tight coupling between all of the accessibility-related functions leads to a more seamless authoring experience.
Applicable to 'what you see is what you get' authoring functions 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)
Illustration of an 'insert table' dialog with places to add a caption and summary[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.@@

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 4.4.1: Accessibility prompting may match prompting for information that is required for proper functioning.
Applicable to 'what you see is what you get' authoring functions 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 )
Illustration of image insertion dialog showing accessibility prompts as well as required attribute prompt for src.[longdesc missing]
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 4.4.2: In some cases, accessibility checking and repair mechanism can be equivalent to a code syntax checking mechanisms or spell checking mechanisms.
Applicable to Code-Level authoring functions Example 4.4.2(a,b): This illustration compares a syntax checker and an accessibility checker in a code-level authoring tool. (Source: mockup by AUWG )
Illustration of potential similarities between an accessibility checker and a syntax checker.[longdesc missing]
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Example 4.4.2(c,d): This illustration compares a spell checker and an accessibility checker. (Source: mockup by AUWG )
Illustration of potential similarities between an accessibility repair tool and a spelling repair tool.[longdesc missing]
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 4.4.3: In most cases, accessibility-related documentation can be equivalent to other documentation in the tool.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions 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)
Illustration of help for 'checking for accessibility'[longdesc missing]
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 4.4.4: Consider providing 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.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 4.4.4: Consider designing accessibility features as integral components of the authoring tool, not components that need to be separately installed or executed.

Technique 3.2.4: CSS classes can be used to indicate accessibility problems enabling the author to easily configure the presentation of errors.

Make checker like spell checker.

 

ATAG Checkpoint 4.5: Ensure that accessibility prompting, checking, repair and documentation functions are configurable. [Priority 2]

Rationale: A configurable tool is more likely to be adatpable 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.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions

Technique 4.X.1: Consider how much author configurability to provide.

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

  • which accessibility standards they wish to follow, and where applicable, to which level,
  • the degree to which the prompts are highlighted in the interface,
  • the nature of the accessibility guidance they wish to receive, and
  • the nature and timing of any automated accessibility features (e.g. accessibility checking or correcting utilities).
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Example 3.1.1(a): This illustration shows an accessibility preferences dialog that allows the author to customize the nature of accessibility checking, highlighting and help as well as set the accessibility standards the tool will check against. (Source: mockup by AUWG)
Screen shot demonstrating an accessibility options card [longdesc missing]
Applicable to Code-Level authoring functions Example 3.1.1(b): This illustration shows shows a different preferences layout, in which accessibility checking is just one of the checkers available as the author enters text in a code-level authoring tool. Other checkers are shown for spelling, syntax and usability. (Source: mockup by AUWG)@@added due to BAF comment@@
Screen shot demonstrating an checkers options card
  Technique 3.2.8: Alerts for high priority WCAG checkpoints can be included in the default configuration.
  Technique 3.2.10: Preference utilities can be designed to allow authors to choose different alert levels based on the priority of accessibility practices.
  All functions that support accessible authoring practices should allow author preferences to be configurable to allow for different authoring styles. Custom configurations should improve use of the tool and make authors more receptive to assistive interventions from the authoring tool.

 


Contents | Guideline 1 | Guideline 2 | Guideline 3 | Guideline 4 | References