This document provides guidelines to authoring tool manufacturers for increasing the accessibility of user-authored Web pages for people with disabilities. Companion documents include guidelines for increading the accessibility of authoring tools themselves as well as techniques for implementing accessibility awareness in authoring tools.
This document is part of a series of accessibility documents published by the Web Accessibility Initiative.
This is [not yet] a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". This is work in progress and does not imply endorsement by, or the consensus of, either W3C or members of the WAI User Agent (AU) working group.
This document has been produced as part of the W3C WAI Activity, and is intended as a draft of a Proposed Recommendation for how to improve authoring tool accessibility. The goals of the WAI-AU Working Group are discussed in the WAI-AU charter. A list of the current AU working group members is available.
Please send comments about this document to the public mailing list: w3c-wai-au@w3.org.
The guidelines in this document are meant to guide authoring tool developers and vendors as they design their products. For the purposes of this document the term "authoring tool" will refer to authoring tools, generation tools and conversion tools. The authoring tool guidelines are designed to help developers guide users towards accessible authoring practices. This approach emphasizes the role of the user interface in informing, supporting, correcting and motivating authors during the editing process. For more detailed discussion of specific accessiblity issues of particular languages, see the WAI Guidelines: Page Author document.
In order to guide authorting tool developers more effectively, each guideline in this document is assigned a priority.
Authoring tools allow users to interact with document through several mechanisms.
Guiding Principle: The acceptance of Web accessiblity requires that accessibility become a fundamental part of authoring tools.
Different languages often contain different sets of accessibility features whose relative importances are determined by the capabilities of the languages themselves. Authoring tools must support all those accessibility features that have been defined for their language(s). This document will not list these solutions since they are stated elsewhere and are subject to clarification or change. Instead a partial list of links to language accessibility resources appears below:
Page Author Accessibility Features: (The actual accessible markup solutions)
Page Author Implementation Priorities: (The priorities placed on the accessibility markup solutions)
Accessibility-aware authoring tools must take into account the differing authoring styles of their users. Some users may prefer to be alerted to problems when they occur, whereas others may prefer to perform a check after the document is completed. This is analogous to programming environments that allow users to decide whether to check for correct code during editing or at compile time.
Techniques:
[Priority 1] Authoring tools should be designed so that
accessibility awareness is at least partially user configurable.
[Priority 2] The author should be given the freedom to customize
when and how the system detects accessibility problems within the priority level
constraints of the particular markup language. Specifically, the author should
decide which of the [Page-Author-Priority 2] and [Page-Author-Priority 3] items in the guidelines should
be flagged by the authoring tool.
[Priority 1] The author should be prevented from completely
disabling checking for [Page-Author-Priority 1]
items.
[Priority 2] The author should be given the option of disabling
tooltips, input prediction and other active accessibility system features.
[Priority 2] The author should be prevented from publishing
inaccessible pages to the Web via built in ftp capability.
All recommended page authoring accessibility features (and their priorities) must be taken into account during the design of relevant user interface components and program functionality.
Techniques:
[Priority 1] When more than one means of performing a
particular authoring task is available, the most accessible means of performing that task
should be the most visible and easily initiated.
[Priority 1] Where several mark-up options are available to the
user, authoring tools should always assume that the author intends to create
accessible pages.
[Priority 1] Authors must not be permitted to neglect
accessibility solutions that are prioritized as [Page-Author-Priority
1] by a particular markup language.
Authoring tools must be designed so that the all processes dealing with the manipulation of markup text are sensitive to the existence of inaccessible markup.
Techniques:
[Priority 1] Check existing documents when they are opened for
editing
[Priority 1] Check documents during all types of editing (including: hand-coding, paste operations and code
insertions)
[Priority 1] When problems are detected they should be advertised
to the author according to a user-configurable schedule (See Alert Techniques)
Language markup authoring tools are often integrated into Web publishing suites that also include peripheral tools for handling non-coding tasks.
Techniques: (A sample list of peripheral tools appear below along with recommendations for how they may assist in facilitating accessibility.)
[Priority 2] Site Management Tools: These tools already
routinely perform checks for site issues, such as broken links. The ability to check for
and correct [Page-Author-Priority 1] accessibility
problems should be added to these tools. Documents missing required accessibility
solutions, such as "alt"-text for HTML4.0, should be permitted to be published
on the Web until all [Page-Author-Priority 1]
accessibility problems are corrected.
[Priority 2] Image, Audio and Video Editors: Image editors
should be modified to encourage the writing of short "alt"-text and long
description text for any images created or edited. Audio and video editors should
encourage the user to create long descriptions, transcripts and captions. Once
created, these associated descriptions should then be cataloged where they can be used to
provide image/audio/video library search capability and default descriptive text, should
the described object be added to a Web document in the future.
When a new feature is added to an established software tool without proper integration, the result is often an obvious discontinuity. Differing color schemes, fonts, interaction styles and even application stability can be factors affecting user acceptance of the new feature.
Techniques:
[Priority 2] In order to gain user acceptance of accessible
authoring, it is imperative that any new functionality associated with accessibility be
properly integrated into the overall "look and feel" of the authoring tool.
[Priority 2] Accessibility features should never interfere with
any of the expected operations of an author's editing environment. For example, fundamental
operations such as document saves, closes, and pastes should not be cancelled or postponed
due to the existence of accessibility problems.
Guiding Principle: Help files, justifications and examples are critical if authoring styles and attitudes are to become more aware of Web accessibility.
The issues surrounding Web accessibility are often unknown to Web authors. The provision of convenient links to clear and concisely written help files, will contribute to author acceptance of, and education about, markup accessibility.
Techniques:
[Priority 1] When the user activates the help system, the
context for the help response should be provided by the user's focus or edit position
within the authoring environment.
[Priority 1] Implement context sensitive help for any special
accessibility icons, outlining or other emphasis within the user interface (initially
these may appear unfamiliar to new users).
[Priority 1] The accessibility help files, should explain the
accessibility problem or accessibility feature quickly, with emphasis placed on the
solutions available rather than placing emphasis on elements that have been incorrectly
marked up.
[Priority 1] The help files should include frequent examples as
well as links to any automated correction utilities (See Section 3.C.5).
As most users have little knowledge of accessibility issues, it is understandable that they will question the justification for abiding accessibility prompts. Authors must be made to understand why time and effort should be devoted to accessibility issues that they may feel are not relevant to themselves.
Techniques:
[Priority 1] The help system should provide some explanations
as to the importance of utilizing accessibility features.
[Priority 1] Explanations should emphasize the Universal Design
principle of supporting flexible display and control choices, which are critical for:
For more information on Universal Design, see the Trace Center.
Acheiving accessibility requires some extra effort and cooperation from the author. In order to maintain user good will and acceptance of accessible authoring practices, the user should receive positive reinforcement when accessibility objectives are satisfied.
Techniques:
[Priority 2] Users should be notified of the successful
implementation of accessibility objectives (ex. all images have "alt"-text in
HTML4 document) as they work towards full compliance.
[Priority 2] Avoid presenting long lists of remaining
inaccessible items.
Textual descriptions, including "alt"-text, long descriptions, video captions and transcripts, are absolutely necessary for the accessibility of all images, applets, video and audio files. However, the task of writing these descriptions is probably the most time consuming accessibility recommendation made to the author.
Techniques:
[Priority 2] Include professionally written descriptions for all multimedia files packaged with the authoring tool, in order to satisfy the following important objectives:
[Priority 2] The authoring tool should make use of the
pre-written descriptions by suggesting them as default text whenever one of the associated
files is inserted into the author's document.
[Priority 2] Allow authors to make keyword searches of the
description database in order to find relevant images.
In addition to a help section dedicated to accessibility, accessiblity principles should be followed for all applicable markup examples in the rest of the help system. This will increase integration and help show authors that accessibility is a normal part of authoring, rather than a separate concern.
Techniques:
[Priority 3] All markup practices that require accessible
solutions should appear with those solutions (ex. IMG elements should appear with
"alt"-text)
[Priority 3] Lower priority accessibility solutions should also
be included to increase the wider acceptance of these standards.
Guiding Principle: The power of automation should be utilized to free authors to concentrate on description writing and other higher-level aspects of Web accessibility.
Many authoring tools allow their users to create markup documents with little, or no knowledge about the underlying structure of the language.
Techniques:
[Priority 1] In order to ensure that documents are made
accessible according to the WAI Accessibility Guidelines: Page
Authoring every authoring tool must include an automated tool which identifies and
helps correct accessibility problems
[Priority 1] The correcting tool must be designed in such a way
that authors can correct accessibility problems without necessarily understanding either
the underlying structure of the language or the details of markup accessibility.
If markup is automatically generated by an invisible process, the author will be unaware of the accessiblity status of the final product unless they expend extra effort to make appropriate corrections by hand. Since most authors are unfamiliar with accessibility, these problems are likely to remain.
Techniques:
[Priority 1] Automated
markup insertion functions should always make use of appropriate accessible solutions,
even if this means presenting the author with extra prompts for
necessary information or structure.
[Priority 1] Automatic tools should always make use of
algorithms that produce accessible markup.
Many applications feature the ability to convert documents from other formats (e.g., Rich Text Format) or proprietary formats into a markup format, such as HTML. This process is usually hidden from the user's view and often creates inaccessible documents. Note: It is likely that the creation of accessible pages will necessitate requesting information from the author during the conversion process. In addition, changes may have to be made to the appearance of the document..
Techniques:
[Priority 1] Conversion utilities should avoid generating documents that contravene the WAI Accessibility Guidelines: Page Authoring.
When a document is created in one author tool and then opened in another, the markup is often changed to allow more efficient editing and manipulation. Unfortunately, these modifications often have the side-effect of removing markup required for accessibility.
Techniques:
[Priority 1] Authoring tools should never remove or modify
structure or content that is necessary for accessibility.
[Priority 1] Authoring tools are allowed to change a document to
make it more accessible.
[Priority 1] Authoring tools must allow users to know when any
changes are made.
Section Editors: J. Treviranus
Web authors have a broad range of skills and needs. Guidelines in this section address the accessibility of the authoring tools to web authors. Authoring tools, like other software applications can be made accessible in two ways:
Authoring tools are similar to and frequently include the functionality of user agents.
Most of the guidelines for providing access to the authoring tool are covered in the WAI Guidelines: User Agent. Authoring
tools should therefore comply with the User Agent Guidelines. Issues not addressed by the
User Agent Guidelines are related to the additional and unique functionality
of authoring tools.
When creating or editing a web page the desired ultimate rendering of the page may not be optimal for creating and editing.
[Priority 1] The authoring tools should support at least two views:
[Priority 1] In the authoring/editing view the font size, letter and line spacing and font and background color should be independent of the final format of the document.
Graphically represented tags cannot be identified by third party assistive technologies that translate text to Braille, speech or large print.
[Priority 1] Authors should be provided the option of
displaying the tags in a text format.
[Priority 1] The text format should include the greater than and
less than brackets to help to distinguish the tag from the remainder of the document.
Graphic representation of web pages or web site elements in site management tools cannot be identified by third party assistive technologies that translate text to Braille, speech or large print.
[Priority 1] Authors should be given the option of displaying the site map in text form (as a structured tree file).
To edit a document, authors require accurate and efficient control of cursor movement. Many authors are unable to use a mouse or similar pointing device.
[Priority 1] In addition to the standard cursor movement keys, authoring tools should provide keyboard commands to move the insertion cursor or begin and extend a selection, these keyboard commands should include movement or extension:
The common feature of automatically extending a selected block can be confusing to users who do not see the screen.
[Priority 1] Authors should be given the option of turning
this feature off.
[Priority 1] To allow third party assistive technologies to
find and follow the cursor, the cursor must be created using standard OS controls.
Dialog boxes and palletes depend upon visual conventions and visual placement to communicate function and structure. For users who cannot see the dialog box or who cannot see the dialog box in its entirety, this structure and functionality is not communicated.
[Priority 1] Be consistent in the placement of text labels
relative to the associated text input fields, radio buttons, check boxes or other controls
(i.e. always to the left, right, above or below). Also be consistent throughout the
authoring tool.
[Priority 1] Insure that the order of tabbing through the dialog
or pallete is logical.
[Priority 1] Provide keyboard shortcuts to directly select
controls or buttons.
[Priority 1] Use structural tools available in SDKs and APIs to
organize interface elements or controls.
[Priority 1] Provide text labels for graphically represented
controls or pallete choices (this can be done through mechanisms such as tool tips).
The act of attracting the user's attention is an important issue for this document. The way in which a user is alerted, prompted, warned, etc. will influence their view of the the tool as well as their opinion regarding the issue of accessibility itself. Within the document, emphasis is placed on integrating accessibility into the feel of the authoring tool's user interface (3.A.6 Integrate accessibility features naturally [Priority 2]) and allowing the author the freedom to decide when and how accessibility will be addressed (3.A.2 Allow authors to configure the level of accessibility awareness [Priority 1]).
The following is a partial list of sample alert possibilities with a short definition and a brief discussion of their advantages and disadvantages. These recommendations are meant only as a guide, since the actual implementation will depend on the look and feel of the authoring tool itself.
The following sample implementations are examples of how authoring tools might be modified to take accessibility into account. Each module deals with a serious accessible authoring issue: (1) "alt"-text, (2) tables, and (3) format conversion. Each module outlines possible strategies for supporting the production of documents that are accessible with respect to these issues. In addition, sample warning and help text is included.
Section Editors: Richards, Treviranus
"Alt"-text is generally considered the most important aid to accessibility. For this reason, the "alt"-text Section of the WAI Accessibility Guidelines: Page Authoring should receive special emphasis both within the user interface and within the Help system.
The following strategy deals exclusively with images. However, the strategy could just as easily apply to the other elements that require "alt"-text.
This tool does not have a visual window presence as far as the user is concerned. It works by saving an association between every "alt"-text label that a user writes with the name of the image, applet, image map, or image map link. Then, whenever one of these elements is inserted, the file name information of the object is checked against the registry association file. If a match is found, then the pre-written "alt" text is displayed as a default choice, allowing users to avoid the repetition of writing multiple descriptions for the same image. The ability to store several descriptions in different languages might also be supported. In more sophisticated implementations, the tool may include a prediction algorithm that takes into account the recency of the "alt"-text, name similarity, and target similarity when searching for matches.
This tool has the curb-cut advantage that the descriptions (especially the professionally written ones that come with bundled images) will allow users to search images using keyword searches, thereby simplifying the task of finding appropriate images.
This tool takes the page containing the Server-Side image map as well as the map file as input. It converts the information in the map file into AREA elements within a MAP element placed in the document. The author will be prompted for alt-text for the full image (if it is absent) and for each link. If the map file contains link comments, these will be used as default "alt"-text.
This tool is a dialog based utility that allows users to include descriptive text without necessarily knowing how to format it properly. The editor will prompt the author for a description, while displaying the image for easy reference. Then the author's description can be used (adter spell checking) to create a new HTML file which is linked from the image by way of the LONGDESC attribute of IMG. Legacy implementations may also choose to support d-links.
Section Editors: Bingham, ???
Section Editors: Richards, Treviranus, ???