-->
Contents | Guideline 1 | Guideline 2 | Guideline 3 | Guideline 4 | References
Copyright © 2003 W3C ® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
OVERALL NOTES ON FORMAT
@@Notes while editing@@
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)
Rationale: Authors are most likely to use the first and easiest options.
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.
@@???@@
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.
Technique 4.2.1: Make any continuously active processes related to accessibility that can be turned on or off (e.g. "as you type"-style checkers), active by default.@@rewording@@
![]()
![]()
![]()
Example 4.2.1: This illustration shows the preference setting area of an authoring tool, open to an "Accessibility" section. Settings that control processes that are continuously active (i.e. not triggered by the author at each instance) are circled in red. (Source: mockup by AUWG)
[longdesc missing]
Technique 4.2.2: Inform the author that disabling any continuously active process may cause accessibility problems that might not occur otherwise. @@rewording@@
![]()
![]()
![]()
Example 4.2.2: If the author unchecks a "highlighting accessibility related fields" feature, as shown in figure 4.2.1, the tool might display a warning that reads "You have just turned off the highlighting accessibility related fields feature. This feature is designed to inform you when information must be provided in order for your documents to comply with your target accessibility setting. Turning this feature off could cause your documents to be less accessible to many users. In some jurisdictions accessibility is a legal requirement. Are you sure you want to proceed?
![]()
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.
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.
Technique 4.2.6: Sometimes several input fields must be filled in order to make a single element accessible. Instead of dispersing these prompts over multiple dialog boxes, it can be more effective to draw them together into one group of controls with a visible tab or other method for accessing the group.@@new-from intro text@
Technique 4.2.7: When determining prominence, control grouping rules usually takes precedence. (e.g. including a fields for adding a label and a description to an image insertion dialog). @@from BAF comment@@
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.
Technique 4.3.1: Optimize the timing of prompting, checking, and repair functions. Authoring accessible documents should be as efficient as possible. Prompting, should be timed so that accessibility problems are prevented whenever possible and, when not possible, checking, and repair should occur when the accessibility problem is easily reversible. Integrated guidance in creating accessible content from the beginning of the workflow will avert the need for more disruptive checking and repair later in the workflow. Timing options include: Negotiated Interruption, Scheduled Interruption, and Immediate Interruption.
(a) Negotiated Interruption: A negotiated interruption is caused by interface mechanisms (e.g. icons or highlighting of the element, audio feedback) that alert the author to a problem, but remain flexible enough to allow the author to decide whether to take immediate action or address the issue at a later time. Since negotiated interruptions are less intrusive than immediate or scheduled interruptions, they can often be better integrated into the design workflow and have the added benefit of informing the author about the distribution of problems within the document. Although some authors may choose to ignore the alerts completely, it is not recommended that authors be forced to fix problems as they occur. Instead, it is recommended that negotiated interruption be supplemented by scheduled interruptions at major editing events (e.g., when publishing), when the tool should alert the author to the outstanding accessibility problems.
Example 4.3.1(a): This illustration shows an example of a negotiated interruption. The author is made aware of problems detected automatically by means of a blue squiggly line around or under rendered elements with accessibility problems. The author can decide to address the problems at a later time. (Source: mockup by AUWG)
[longdesc missing]
(b) Scheduled Interruption: A scheduled interruption is one in which the author has set the tool to alert them of accessibility issues on a configurable schedule. One option for the schedule might be to have prompts associated with the interface mechanisms for significant authoring events, such as opening, saving, closing, committing, or publishing files. At the significant authoring event, the author would be informed of the problem, while at the same time they would not be prevented from saving (see Figure 4.3.1(b)), publishing, printing, etc.. A potential downside of postponing corrective actions is that by the time the prompt is displayed, the author may not have sufficient time or inclination to make the required changes, especially if they are extensive.
![]()
![]()
Example 4.3.1(b): This illustration shows a "Publish" dialog box that is an example of a scheduled interruption. The author is alerted to the existence of content that does not meet a "standard of publishing" before being allowed to publish. This standard might include spelling and grammar standards as well as accessibility issues. (Source: mockup by AUWG)
[longdesc missing]
(c) Immediate Interruption: An immediate interruption is the most intrusive timing option because the attention of the author is actively diverted from the current editing task by the notification of some issue. This might be achieved, for instance, by an alert dialog. This type of alert presents multiple usability problems and should be used sparingly because it interferes with the normal design workflow. Intrusive warnings are probably only appropriate when the window of opportunity for correcting a serious accessibility problem is about to close, such as when an author decides to publish the content in question. In general, negotiated and scheduled interruptions are preferred.
Technique 4.3.2: When authoring tools produce content in real time, it is usually no longer possible to delay addressing accessibility problems until an arbitrary point in the future. At the same time, due to the time pressure, authors in real-time environments tend to be less receptive to intrusive prompts. Nevertheless, tools that allow this kind of authoring (see Figure 3.3.6) should still take accessibility issues into account by supporting the following:
(a) Determination of Participant Requirements: If real-time authoring is consumed by individuals with no special communicative needs, there may be no need for real-time prompting. However, as with any other Web content it is often impossible for the author to know all of the needs of the actual or potential participants. Therefore, the best practice is to create real-time content that conforms with WCAG to the greatest extent possible. However, when this is not possible, a real-time authoring tool might be able to facilitate graceful degradation of accessibility by polling the participants (see "Request whiteboard descriptions" checkbox in the figure) or in some cases checking the profiles of participants (e.g. using CCPP, ACCLIP) to determine which types of accessibility practices would offer the greatest advantage in the short time available. Once this information is compiled, the tool can prompt the author (or see Assistant/Peer Author) to correct problems appropriately (preferably during Preparation Time). When it is not possible to know, with certainty, the needs of all participants, the tool should still assume that accessible content is required. This is especially true if the results of the session will be archived.
(b) Assistant/Peer Author: In some cases, it may be possible to designate one or more secondary authors in the live community, who can receive and respond to prompts for supplemental information generated as the primary author proceeds uninterrupted. The secondary author might be an unrelated specialist, analogous to Sign language interpreter, a co-author (helpful for describing technical drawings, etc.), or in some situations any member of the session audience (i.e. a peer).
(c) Preparation Time: If the authoring tool allows the author time to pre-assemble materials for a live presentation (e.g. a professor preparing for an online class), this authoring is not considered real-time authoring. The authoring tool has the opportunity and the obligation to support accessible authoring as described elsewhere in this document.
(d) Archiving: If the session will be archived, there may be other opportunities to increase the accessibility of the content of the archive by guiding the author through a process to check for and repair accessibility problems after the real-time session has ended, but prior to archiving.
If it has been determined that the author must provide real-time supplements, but no preparation time or assistant author are available, then in addition to allowing the author control of the nature and timing of prompting, the authoring tool can facilitate the inclusion of supplements by:
- Implementing the management functionality for equivalent alternatives (see Checkpoint 3.5). This way, if the author uses an object that has been used before, the tool can suggest the previously stored alternative, which the author can quickly accept or decline without substantial workflow disruption.
- Providing a voice recognition capability so that the author's real-time speech input can be converted into captioning.
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.
@@ BAF: Wizards are the way to go: . Repair tools can address pre-existing content or content edits after use of a wizard (assuming you cannot reenter the wizard). @@ @@BAF: wizards etc should be a major prompting mechanism. Many samples should be shown such as the table example.@@ @@GP would like to de-emphasize wizards a bit.@@
@@JT: Maybe have an example showing a template....?NTS?@@
@@JT: We need to have new techniques for tools that could try to get author to put down structure first and separately than presentation - swappable styles@@
Technique 4.3.5: Integrate prompting into sequencing mechanisms (e.g. design aids, wizards, templates) at a point early enough in the authoring process that there is less chance that it will be bypassed.
Example 4.3.5: This illustration shows three screens of a page building wizard (indirect authoring). The wizard prompts the author for a few key pieces of information that are used to tailor the process, in this case to create a gallery page. Since the accessibility-related prompts ("label" and "description") occur on the third step of the wizard, the "Finish" button is unavailable until then to prevent the author from bypassing this step. (Source: mockup by AUWG)
[longdesc missing]
Technique 4.3.6: Integrate checking and repairing into sequencing mechanisms (e.g. design aids, wizards, templates).
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]
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.
@@BAF: This one tends to be the default case (one would rarely use a different style for accessibility prompting vs other prompting) so we need to make this more a thing to look out for vs a conscious design action. We should include other samples in the pattern below.@@
Technique 4.4.1: For accessibility prompting, use authoring interfaces similar to prompting for information that is required for proper functioning of the tool.
Example 4.4.1: This illustration shows a dialog box in which the prompting for a text label and a long description matches that for the required
src
attribute. The three three input fields match in terms of their size, font, color, label spacing, and operation (ex.src
andlongdesc
have matching abilities to browse for file names). When additional functionality for creating a new description is added to thelongdesc
field, the icon used is consistent with the visual style of other icons in the interface. (Source: mockup by AUWG )
[longdesc missing]
Technique 4.4.2: For accessibility checking and repair, use authoring interfaces similar to code syntax or spelling checking and repair.
Example 4.4.2(a): This illustration shows a code-level authoring tool with syntax and accessibility checking. In both cases, the mechanism used to alert the author to problems is text color highlighting. The design of the two mechanisms is thus identical, except that different colors are used to differentiate one type of problem from the other. A status line display at the bottom of the window provides some manual repair advice. (Source: mockups by AUWG )
[longdesc missing]
![]()
![]()
![]()
Example 4.4.2(b): This illustration compares a spell checker and an accessibility checker. Both checkers begin with a statement of the problem (i.e. "Word misspelled" vs. "Missing Alternate Text Label for an Image"), followed by a view of the problem area (i.e. the misspelled word ("eearth") vs. the image in question (pic123.gif). Then both checkers provide a suggestion (the system's best guess for the word vs. a label from the text equivalent registry) as well as some alternate suggestions (other words vs. some text label guidelines). The size, colors, fonts, styling, and buttons on the checker dialog boxes are also identical or very similar .(Source: mockups by AUWG )
[longdesc missing]
Technique 4.4.3: For accessibility accessibility-related documentation, use authoring interfaces similar to other documentation in the tool.
Technique 4.4.4: Provide a common toolkit to aid in designing additional tool functionality modules. This might be used internally or by third party developers to develop accessibility plug-ins with the same look and feel as other parts of the tool.
Technique 4.4.5: Design accessibility features as integral components of the authoring tool, not components that need to be separately installed or executed.
Rationale: A configurable tool is more likely to be adaptable to the work habits of more authors.
Technique 4.5.1: Provide author configurability. Author acceptance of the accessibility features of an authoring tool can depend on the degree to which these features are integrated into the existing workflows of authors.
Author configurability can help naturally incorporate accessibility-related authoring tasks into the regular workflow of the author. Useful configuration options include (see Figure 4.5.1):
- the nature of the accessibility guidance they wish to receive,
- the degree to which the prompts are highlighted in the interface,
- the nature and timing of any automated accessibility features (e.g. accessibility checking or repairing utilities), and
- which accessibility standards they wish to follow, and where applicable, to which level.
![]()
![]()
![]()
Example 4.5.1: 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)
[longdesc missing] @@other mockup removed@@
Technique 4.5.2:
Include alerts for high priority WCAG checkpoints in the default configuration.Technique 4.5.3: Allow authors to choose different alert mechanisms based on the priority of accessibility problems.
Technique 4.5.4:CSS classes can be used to indicate accessibility problems enabling the author to easily configure the presentation of errors.@@more detailed than usual@@Technique 4.5.4:
Contents | Guideline 1 | Guideline 2 | Guideline 3 | Guideline 4 | References