Contents | Guideline 1
| Guideline 2 | Guideline 3 | Guideline
4 | Glossary @@now uses GL glossary@@ |
References
Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
Conformance with accessibility authoring practices is an authoring constraint, analogous to producing valid code or grammatical text. Since the role of any authoring tool is to facilitate satisfaction of authoring constraints, it is natural that accessibility-aware authoring tools should include features to facilitate the process of creating accessible content. The checkpoint requirements for this section include prompting and assisting the author to create accessible content, especially for information that cannot be generated automatically, such as descriptions of graphics (Checkpoint 3.1), checking for accessibility problems (Checkpoint 3.2), and assisting in the repair of accessibility problems (Checkpoint 3.3). [@@some edits here to bring back to GL's]
Implementation Note: All functions added to support accessible authoring should be flexible enough to take into account different authoring styles. When authors can configure accessibility features to support their regular work patterns, they will be more likely to feel comfortable with their use and be more receptive to interventions from the tool. For example, some authors may prefer to be alerted to accessibility problems when they occur, whereas others may prefer to perform a check at the end of an editing session.
In some authoring situations it may be necessary to prompt (see clarification) or assist (e.g. task automation, entry storage, etc.) authors to follow accessible authoring practices. This is especially true of accessibility problems that require human judgment to remedy, such as adding descriptions to images.
One approach to prompting and assisting the author to create accessible content is to allow problems to be created and then address them later as part of checking (checkpoint 3.2) and correcting (checkpoint 3.3). However, if the author is left uninformed of accessibility problems for too long, they may be overwhelmed by the full weight of the accumulated problems then when they are finally informed. It is, therefore, preferable to begin guiding the author towards the production of accessible content before accessibility problems have actually been introduced.
It is important to note that when information is required from the author, it is crucial that that information be correct and complete. This is most likely to occur if the author has been convinced to provide the information voluntarily. Therefore, overly restrictive mechanisms are not recommended for meeting this checkpoint.
The term prompt in this checkpoint should not be interpreted as implying intrusive prompts, such as pop-up dialog boxes. Instead, ATAG 2.0 uses prompt in a wider sense, to mean any process of eliciting author input. This process should be:
Technique 3.1.1: Consider
how much user configurability will be provided. User acceptance
of the accessibility features of an authoring tool will likely depend on
the degree to which these features can be integrated into authors' existing
workflows. That is why the ATAG definition of "prompting" clearly
states that: "the form and timing that this prompting takes can be
user configurable". In other words, the author should be able to control
to some extent how and when assistance in avoiding accessibility problems
is rendered by the tool. This user configurablity 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@@]
|
|
|
|
Technique 3.1.2: How to prompt and assist for various types of information: [@@new@@] | |
Technique 3.1.2(1): Short text labels (e.g. Alternate text, Titles, Rubies for Ideograms): [@@changed@@]
|
|
|
|
Technique 3.1.2(2): Multiple text labels (e.g. image map area labels): [@@changed@@]
|
|
|
|
Technique 3.1.2(3): Long text descriptions (e.g. Longdesc text, table summaries, site information): [@@changed@@]
|
|
|
|
Technique 3.1.2(4): Form field place-holders: [@@changed@@]
|
|
Technique 3.1.2(5): Accesskeys: [@@changed@@]
|
|
Technique 3.1.2(6): List sub-groups: [@@changed@@]
|
|
Technique 3.1.2(7): Form field labels: [@@changed@@]
|
|
|
|
Technique 3.1.2(8): TAB order definitions:[@@changed@@]
|
|
Technique 3.1.2(9): Contrasting colours: [@@changed@@]
|
|
|
|
Technique 3.1.2(10): Audio/video transcripts: [@@changed@@]
|
|
Technique 3.1.2(11): Audio/video captions: [@@changed@@]
|
|
Technique 3.1.2(12): Audio descriptions for video: [@@changed@@]
|
|
Technique 3.1.2(13): Signed translation for audio/video : [@@changed@@]
|
|
Technique 3.1.2(14): Still images of video: [@@changed@@]
|
|
Technique 3.1.2(15): Metadata: [@@changed, needs MUCH more@@]
|
|
Technique 3.1.2(16): Document structure: [@@added and likely will include many more techs@@]
|
|
Technique 3.1.2(17): Tabular structure: [@@added and likely will include many more techs@@]
|
|
Technique 3.1.2(18): Style sheets: [@@added and likely will include many more techs@@]
|
|
Technique 3.1.2(19): Clearly written text: [@@changed@@]
|
|
Technique 3.1.2(20): Non-Text supplements to text: [@@changed@@]
|
|
Technique 3.1.2(21): Other information: [@@changed@@]
|
|
Technique 3.1.3: The tool can provide multiple preview modes and a warning to authors that there are many other less predictable ways in which a page may be presented (aurally, text-only, text with pictures separately, on a small screen, on a large screen, etc.). Some possible document views include: [@@changed@@]
|
|
|
|
[@@Techniques needed@@]
Technique 3.1.1: | |
Despite prompting assistance from the tool (see Checkpoint 3.1), accessibility problems may still be introduced. For example, the author may cause accessibility problems during hand coding or content with existing accessibility problems may be opened for editing. In these cases, the prompting and assistance mechanisms that operate when markup is added or edited (i.e. insertion dialogs and property windows) must be backed up by a more general checking system that can detect and alert the author to problems anywhere within the content (attribute, element, programmatic object, etc.). It is preferable that this checking mechanisms be well integrated with correction mechanisms (see Checkpoint 3.3), so that when the checking system detects a problem and informs the author, the tool can also help the author address the issue.
Technique 3.2.1: Consider the level of automation to be used for checking (and informing). Options include: [@@new@@] |
|
1. Manual (not automated): The tool provides the author with instructions for detecting a problem, but does not automate the task of detecting the problem in any meaningful way. As a result, the author must follow the instructions and make the determination that a problem exists by themselves. This type of check is discouraged since it can be annoying for the author, especially when the type of problem in question may be easily detected by a more automated utility (e.g. an element missing a particular attribute). |
|
|
|
2. Semi-Automated: The tool is able to identify potential problems, but still requires a human judgment by the author to make a final appraisal. This type of check is usually most appropriate for semantic-type problems, such as descriptions of non-text objects, as opposed to purely syntactic problems, such as missing attributes, which lend themselves more readily to automation. | |
|
|
3. Automated: The tool is able to check for accessibility problems automatically, with no human intervention required. This type of check is usually appropriate for syntactic-type checks, such as the use of deprecated elements or a missing attribute, in which the meaning of text does not play a role. | |
|
|
Technique 3.2.2: Consider the timing options to be used for informing the author of the results of the check. Options include: [@@new@@] | |
1. Immediate Interruption: An immediate interruption is the most intrusive timing option because the author's attention 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. An example of this might be when an author is publishing a document to their site. In general, we recommend using the less disruptive timing options. |
|
|
|
2. Configured Interruption (Preferred): A negotiated interruption is caused by interface mechanisms (icons, line or color highlighting of the element, audio feedback, etc.) that alert the author to a problem, but are flexible as to whether the author should take immediate action or address the issue at a later stage in the design process. This type of unintrusive alert can be better integrated into the design workflow. For example, a colored outline might be drawn around offending objects in a WYSIWYG view (see Figure 3.2.5), while the markup text for the same object might be highlighted by a different font color in the code view (see Figure 3.2.6). Besides being unintrusive, such indicators will have the added benefit of informing the author about the distribution of errors within the document without interrupting their editing process.Of course, some authors may choose to ignore the alerts completely. In this case, the AUWG does not recommend forcing the author to fix the problem. Instead, it recommends that, at some major editing event (e.g., when publishing), the tool should remind the author of the continuing unresolved accessibility issues. |
|
|
|
3. 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, printing, etc. 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. For example, a "save as" dialog could display an accessibility warning and an option to launch a correction utility after saving (see Figure 3.2.7). A potential downside of this type of prompting is that by the time the prompt is displayed (publishing, etc.), the author may not have time to make the required changes, especially if they are extensive. |
|
|
|
Technique 3.2.3: See AERT document for evaluation and repair algorithms. The WAI Evaluation and Repair group [WAI-ER] is developing a document that discusses detailed techniques for testing the accessibility of content according to the Web Content Accessibility Guidelines, and methods of repairing it. A draft of that document is available [AUTO-TOOL]. | |
Technique 3.2.4: Highlight problems detected when documents are opened, when an editing or insertion action is completed, or while an author is editing. Using CSS classes to indicate accessibility problems will enable the author to easily configure the presentation of errors. | |
Technique 3.2.5: Alert authors to accessibility problems when saving. | |
Technique 3.2.6: Accessibility problems can be highlighted using strategies similar to spell checking within a word processor. Accessibility alerts within the document can be linked to context sensitive help. (See the Techniques for ATAG checkpoint 6.1) | |
Technique 3.2.7: Where the tools cannot test for accessibility errors, provide the author with the necessary information, wizards, etc. to check for themselves. | |
Technique 3.2.8: Include alerts for WCAG Priority 1 checkpoints in the default configuration. | |
Technique 3.2.9: Provide an editing view that shows equivalent alternatives in the main content view to make it clear that they are necessary. This will make it obvious when they are missing. | |
Technique 3.2.10: Allow authors to choose different alert levels based on the priority of authoring accessibility recommendations. | |
Technique 3.2.11: If intrusive warnings are used, provide a means for the author to quickly set the warning to non-obtrusive to avoid frustration. | |
Technique 3.2.12: The WAI Evaluation and Repair group [WAI-ER] has produced a Public Working Draft of techniques for evaluating and repairing HTML according to WCAG 1.0 [AERT]. |
Once a problem has been detected by the author or, preferably, the tool (see Checkpoint 3.2), the tool may assist the author to correct the problem. As with accessibility checking, the extent to which accessibility correction can be automated depends on the nature of the particular problems. Some repairs are easily automated, whereas others that require human judgment may be semi-automated at best.
Technique 3.3.1: Consider the level of automation to be used for correction. Options include: [@@new@@] | |
1. Manual: The tool provides the author with instructions for making the necessary repair, but does not automate the task in any meaningful way (e.g. the tool may move the cursor to start of the problem and still be considered "manual"). Manual correction tools leave it up to the author to follow the instructions and make the repair by themselves. This is the most time consuming option for users and allows the most opportunity for user error. |
|
|
|
2. Semi-Automated: For some types of problems, tool can provide some automated assistance to the user in performing corrections, but the author's input is still required. For example, the tool may prompt the user for a plain text string, but then be capable of handling all the markup required to add the text string to the content. In other cases, the tool may be able to narrow the choice of repair options, but still rely on the author to make the final selection. |
|
|
|
3. Automated: For some types of problems, tools may be is able to make repairs automatically. For example, in cases where the user wishes to strip out every instance of specific element. In these cases, very little, if any, user interface is required. |
|
|
|
Technique 3.3.2: Consider implementing a special-purpose correcting interface. [@@new@@]When problems require some human judgment, the simplest solution is often to display the property editing mechanism for the offending element. This has the advantage that the user is already somewhat familiar with the interface. However, this practice suffers from the drawback that it does not necessarily focus the author's attention on the dialog control(s) that are relevant to the required correction. Another option is to display a special-purpose correction utility (see example) that includes only the input field(s) for the information currently required. The advantage of this approach is that additional information and tips that the author may require in order to properly provide the requested information can be easily added. Notice that in the figure, a drop-down edit box has been used for the alt-text field. This technique might be used to allow the author to select from text strings used previously for the alt-text of this image (see ATAG Checkpoint 3.5 for more). | |
|
|
Technique 3.3.3: Decide whether to provide sequential checking or real-time (live) checking, or both: | |
1. Sequential Checking: In cases where there are likely to be many accessibility problems, it may be useful to implement a checking utility that presents accessibility problems and repair options in a sequential manner. This may take the a form similar to a configuration wizard or a spell checker (see Figure 3.3.5). In the case of a wizard, a complex interaction is broken down into a series of simple sequential steps the user can complete one at a time. The later steps can then be updated on the fly to take into account the information provided by the user in earlier steps. A checker is a special case of a wizard in which the number of detected errors determines the number of steps. For example, word processors usually have checkers that display all the spelling problems one at a time in a standard template with places for the misspelled word, a list of suggested words, and the correct word. The user also has correcting options, some of which can store responses to affect how the same situation is handled later. In an accessibility problem checker, sequential prompting is an efficient way of correcting problems. However, because of the wide range of problems the checker needs to handle (i.e. missing text, missing structural information, improper use of color, etc.), the interface template will need to be even more flexible than that of a spell checker. Nevertheless, the template is still likely to include areas for identifying the problem (WYSIWYG or markup-based according to the target audience of the tool), suggesting multiple solutions and choosing between or creating new solutions. In addition, the dialog may include context-sensitive instructive text to help the author with the current correction. | |
|
|
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:
|
|
|
|
Technique 3.3.5: At a minimum, provide context-sensitive help with the accessibility checking required by ATAG Checkpoint 3.2. | |
Technique 3.3.6: Where a tool is able to detect site-wide errors, allow the author to make site-wide corrections. This should not be used equivalents alternatives when the function is not known with certainty (see ATAG Checkpoint 3.4). [@@changed@@] | |
Technique 3.3.7: Assist authors in ways that are consistent with the look and feel of the authoring tool (See Techniques for ATAG Checkpoint ?.?). | |
Technique 3.3.8: Allow authors to configuration the nature and timing of the correction process. | |
Technique 3.3.9: Provide a mechanism for authors to navigate sequentially among uncorrected accessibility errors. | |
Technique 3.3.10: The WAI Evaluation and Repair group [WAI-ER] has produced a Public Working Draft of techniques for evaluating and repairing HTML according to WCAG 1.0 [AERT]. |
Technique 3.4.1: If the author has not specified an alternative equivalent, default to leaving out the relevant attribute, rather than including the attribute with no value or with automatically-generated content. Leaving out the attribute will increase the probability that the problem will be detected by checking algorithms (see Techniques for ATAG checkpoint 5.1). |
Technique 3.4.2: If human-authored equivalent alternatives may be available for an object (for example, through Techniques for ATAG checkpoint 4.4 and/or Techniques for ATAG checkpoint 3.4), it is appropriate for the tool to offer these to the author as defaults. | |
Technique 3.4.3: The function of objects is considered to be known with certainty when they are used throughout a Web site in a standard way (e.g., graphical navigation bars). In this case, the objects should have standard alternative information. Where an object has already been used in a document, the tool should offer the alternative information that was supplied for the first or most recent use as a default. If the user changes the alternative content, they might be asked whether all instances of the object should have their alternative content updated with the new value. |
Note: This checkpoint is priority 3 and is, therefore, not required to be implemented in order for a tool to conform to ATAG 2.0 at the single-A and double-AA levels. However, implementing this checkpoint has the potential to simplify the satisfaction of several higher priority checkpoints (ATAG checkpoint 3.1, ATAG checkpoint 3.2, and ATAG checkpoint 3.3) and improve the usability of the tool.
Technique 3.5.1: Maintain a registry that associates object identity information with alternative information (this could be done with the Resource Description Framework (RDF) [RDF10]). Whenever an object is used and an equivalent alternative is collected (see ATAG Checkpoint 3.1) add the object (or identifying information) and the alternative information to the database. In the case of a text equivalent, the alternate information may be stored in the document source. For more substantial information (such as video captions or audio descriptions), the information may be stored externally and linked from the document source. Allow different alternative information to be associated with a single object. | |
Technique 3.5.2: Stored alternative information can be presented to the author as default text in the appropriate field, whenever one of the associated files is inserted into the author's document. This satisfies ATAG Checkpoint 3.4 because the equivalent alternatives are not automatically generated and they are only reused with author confirmation. | |
Technique 3.5.3: When no stored association is found, the field should be left empty (i.e., no purely rule-generated alternative information should be used). Note: The term "default" implies that the alternative information is offered for the author's approval. The term does not imply that the default alternative information is automatically placed without the author's approval. Such automatic placement may only occur when in situations where the function of the object is known with certainty, per ATAG Checkpoint 3.4. Such a situation might arise in the case of a "navigation bar builder" that places a navigation bar at the bottom of every page on a site. In this case, it would be appropriate to use the same "alt"-text automatically for every instance of a particular image (with the same target) on every page. | |
Technique 3.5.4: The stored alternative information required for ATAG Checkpoint 3.4 might be part of the management system, allowing the alternative equivalents to be retrieved whenever the prepackaged objects are inserted. | |
Technique 3.5.5: Tools might allow authors to make keyword searches of a description database (to simplify the task of finding relevant images, sound files, etc.). A paper describing a method to create searchable databases for video and audio files is available (refer to [SEARCHABLE]). |
Technique 3.6.1: Provide a list of all accessibility errors found in a Web page. | |
Technique 3.6.2: Provide a summary of accessibility problems remaining by type and/or by number. |
Because authors are likely to differ widely in their familiarity with Web content accessibility issues, the help and documentation of the authoring tool must address several types of use. The checkpoint requirements for this section include documenting accessible content promoting features (Checkpoint 3.7), ensuring that accessibility solutions are modeled in the documentation and help(Checkpoint 3.8), and including suggested workflow instructions for using the tool to produce accessible content (Checkpoint 3.9).
Technique 3.7.1: Ensure that the help system can answer the following questions: "What features of the tool encourage the production of accessible content?" and "How are these features operated?". | |
Technique 3.7.2: Provide direct links from the features to context sensitive help on how to operate the features. (i.e., the link might originate with icons, outlining or other emphasis within the user interface). | |
Technique 3.7.3: Provide links from within the help text to relevant automated correction utilities. |
Technique 3.8.1: In the documentation, ensure that all code examples pass the accessibility checking mechanism required for checkpoint 3.1, regardless of what aspect of the code, the example is meant to show. | |
Technique 3.8.2: In the documentation, provide at least one model of each accessibility practice in the relevant WCAG techniques document for each language supported by the tool. Note: This includes all levels of accessibility practices, not just Level 1 or 2. | |
Technique 3.8.3: When the help files of a base tool do not meet this checkpoint, an accessibility plug-ins that updates the files is acceptable. | |
Technique 3.8.4: When explaining the accessibility issues related to elements that have not been officially deprecated, try to emphasize the solutions rather than explicitly discouraging the use of the element. | |
Technique 3.8.6: For tools that include context sensitive help, implement context-sensitive help for accessibility terms as well as tasks related to accessibility. | |
Technique 3.8.7: For tools that include tutorials, provide a tutorial on checking for and correcting Web accessibility problems. | |
Technique 3.8.8: Include pointers to more information on accessible Web authoring, such as WCAG and other accessibility-related resources, | |
Technique 3.8.9: Include current versions of, or links to relevant language specifications in the documentation. This is particularly relevant for languages that are easily hand edited, such as most XML languages. |
Technique 3.9.1: Document the sequence of steps that the author should take, using the tool, in order to increase the likelihood of producing accessible content. This should take account of any idiosyncrasies of the tool. | |
Technique 3.9.2: The section could be prefaced by an introduction that explains the importance of accessibility for a wide range of users, from those with disabilities to those with alternative viewers. | |
Technique 3.9.3: For tools that explain the reasons for accessibility, take a broad view. For example, do not refer to any particular accessibility feature as being "for blind authors" or label them with a "disability" icon. Instead, refer to them as being for "authors who are not viewing images". Consider emphasizing points in "Auxiliary Benefits of Accessibility Features", a W3C-WAI resource. | |
Technique 3.9.4: This documentation could be located in a dedicated section. |
Technique 3.9.5: Tools that lack an accessibility checking and/or repair feature may point to the relevant WCAG Techniques document for the language. Note: this will not suffice to meet the checkpoints related to accessibility checking (ATAG Checkpoint 3.1) and repair (ATAG Checkpoint 3.2). |
Contents | Guideline 1
| Guideline 2 | Guideline 3 | Guideline
4 | Glossary | References