2. Guidelines |
|
GUIDELINE 1: Ensure that the tool itself is accessible |
|
An authoring tool is a software program
with standard user interface elements and as such must be designed according
to relevant user interface accessibility guidelines. When custom interface
components are created, it is essential that they be accessible through
the standard access mechanisms for the relevant platform so that assistive
technologies can be used with them. Some additional user interface design considerations apply specifically to Web authoring tools. For instance, authoring tools must ensure that the author can edit (in an editing view) using one set of stylistic preferences and publish using different styles. Authors with low vision may need large text when editing but want to publish with a smaller default text size. The style preferences of the editing view must not affect the markup of the published document. Authoring tools must also ensure that the author can navigate a document efficiently while editing. Authors who use screen readers, refreshable Braille displays, or screen magnifiers can make limited use (if any) of graphical artifacts that communicate the structure of the document and act as signposts when traversing it. Authors who cannot use a mouse (especially people with physical disabilities or who are blind) must use the slow and tiring process of moving one step at a time through the document to access the desired content, unless more efficient navigation methods are available. Authoring tools should therefore provide an editing view that conveys a sense of the overall structure and allows structured navigation. Note: Documentation, help files, and installation are part of the software and need to be available in an accessible form. |
This guideline requires that the design of all aspects of the authoring tool, including the user interface, installation procedure, documentation, and help files, must be accessible. This entails following the all applicable accessibility guidelines (Checkpoint 1.1) as well as other considerations specific to authoring interfaces. |
|
Specific considerations when designing an accessible authoring interface: |
The special nature of authoring interfaces dictates several other accessible user interface design considerations. The checkpoint requirements for this section include ensuring accessible editing of all properties (Checkpoint 1.2), allowing the editor display preferences to be changed independently of the markup (Checkpoint 1.3), making the use of document structure for navigation and editing (Checkpoint 1.4), and providing an effective searching mechanism (Checkpoint 1.5). | |
GUIDELINE 2: Ensure that the tool is designed to produce accessible content |
|
The most basic determinant of the accessibility of Web content is the degree to which the authoring tool that produced it gives priority to markup validity and accessibility. Tools that generate and preserve high quality markup are well prepared to meet the other guidelines. | This guideline requires that authoring tools must generate standard markup and support accessible authoring practices. Meeting these requirements is an essential pre-requisite to the higher level functions required in the next guideline. |
Generating standard markup: |
|
Conformance with standards promotes
interoperability and accessibility by making it easier to create specialized
user agents that address the needs of users with disabilities. In particular,
many assistive technologies used with browsers and multimedia players are
only able to provide access to Web documents that use valid markup. Therefore,
valid markup is an essential aspect of the accessibility compliance of an
authoring tool. Where applicable use W3C Recommendations, which have been reviewed to ensure accessibility and interoperability and which are relied upon by assistive technology developers. If there are no applicable W3C Recommendations, use a published standard that enables accessibility. |
Conformance with standards enables content to be rendered more reliably by more user agents, including assistive technologies used by people with disabilities. The checkpoint requirements for this section include ensuring valid markup (Checkpoint 2.1) and using formats that have been formulated to enable accessible content (Checkpoint 2.2). |
Supporting accessible authoring practices: |
|
If the tool automatically generates markup, many
authors will be unaware of the accessibility status of the final content
unless they expend extra effort to review it and make appropriate corrections
by hand. Since many authors are unfamiliar with accessibility, authoring
tools are responsible for automatically generating accessible markup, and
where appropriate, for guiding the author in producing accessible content.
Many applications feature the ability to convert documents from other
formats (e.g., Rich Text Format) into a markup format specifically intended
for the Web such as HTML. Markup changes may also be made to facilitate
efficient editing and manipulation. It is essential that these processes
do not introduce inaccessible markup or remove other content intended
to increase accessibility, particularly when a tool hides the markup changes
from the author's view. |
Web content produced by an authoring tool is most likely to be accessible, if the content is created in accordance with the requirements of WCAG and preserved in that state throughout the authoring process. The checkpoint requirements for this section include ensuring the possibility of accessible content production (Checkpoint 2.3), preserving accessible or unknown content (Checkpoint 2.4 and 2.7), automatically generating accessible content (Checkpoint 2.5), and including accessible pre-authored content (Checkpoint 2.6). |
GUIDELINE 3: Support the author in the production of accessible content |
|
Most authoring tools provide the author with at least some measure of control over the produced content. This control may extend to the level of markup coding (e.g. authoring "by hand") or it may be limited to higher-level content, such as page layout and text content (e.g. WYSIWYG editing). In either case, the intervention of the author has the potential to effect the accessibility of content, either positively, if the author is purposefully following accessibility guidelines, or negatively, if the author is not. In order to manage these effects, authoring tools should support the author by guiding them to follow accessibility authoring practices as they produce that content that involves an element of human judgment or creativity, providing automated or semi-automated checking and correction facilities and by providing high quality accessibility-related documentation. | This guideline requires that authoring tools allowing author control over the produced content (e.g. authoring "by hand", controlling page layout and text content, etc.), must support those authors in creating content that is accessible. This support will include guiding them to follow accessibility authoring practices by providing automated or semi-automated checking and correction facilities and by providing documentation that is "accessibility-aware". |
Guiding the author to produce accessible content: [3.1-3.3] |
|
Conformance with accessibility authoring practices is an authoring constraint that is little different, in principle, from the constraint to produce valid code or grammatical text. Since the role of authoring tools is to facilitate satisfaction of authoring constraints, it is natural that tools should include features to facilitate the process of creating accessible content. For example, tools may assist authors to follow specific practices by suggesting accessible authoring practices or prompting for information that cannot be generated automatically, such as equivalent alternatives (alternate text, descriptions, captions, etc.). Many authoring tools already allow authors to create documents with little or no need for knowledge about the underlying markup. To ensure accessibility, authoring tools must be designed so that they can (where possible, automatically) identify inaccessible markup, and enable its correction when either the markup is hidden from the author or the author does not know how to correct it. Authoring tool support for the creation of accessible Web content should account for different authoring styles. Authors who can choose how to configure the tool's accessibility features to support their regular work patterns are more likely to feel comfortable with their use of the tool and be receptive to interventions from the tool. (see guideline 4). 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. This choice is analogous to that offered in programming environments that allow authors to decide whether to check syntax during editing or at compilation. |
Conformance with accessibility authoring practices is an authoring constraint, analogous to producing valid code or grammatical text. Since the role of any authoring tools is to facilitate satisfaction of authoring constraints, it is natural that 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). 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. |
Specific considerations when providing this guidance: [3.4-3.6] |
|
When guiding the author towards the creation of accessible content, several specific factors should must be considered. The checkpoint requirements for this section include taking care not to automatically include inappropriate equivalent alternatives (Checkpoint 3.4), providing automated means for managing equivalent alternatives (Checkpoint 3.5), and providing accessibility status summaries (Checkpoint 3.6). |
|
Promoting accessibility in help and documentation: [3.7-3.9] |
|
Some Web authors may not be familiar with accessibility issues that arise when creating Web content, while others may be authors familiar with these issues, but may not know how the tool can help to address them. Therefore, help and other supplied documentation must include explanations of accessibility problems, and should demonstrate solutions with examples. | 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). |
GUIDELINE 4: Promote and integrate accessibility solutions |
|
When a new feature is added to an existing software tool without proper integration, the result is often an obvious discontinuity. Differing color schemes, fonts, interaction styles, and even software stability can be factors affecting author acceptance of the new feature. In addition, the relative prominence of different ways to accomplish the same task can influence which one the author chooses. Therefore, it is important that creating accessible content be a natural process when using an authoring tool. | 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 availability of accessibility-related functions (Checkpoint 4.1), ensuring the priority for accessible means of completing for an authoring tasks (Checkpoint 4.2) and ensuring that accessibility-related functions fit into the overall look and feel of the tool (Checkpoint 4.3). |