WAI Accessibility Guidelines:
Authoring Tools

W3C Working Draft 13-October-1998

 

Abstract

 

Note. This document provides guidance on the development of Web authoring tools which produce accessible Web pages, consistent with the 'WAI Page Authoring Guidelines.

Status of this document

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.

Available formats

Comments

Table of Contents

1 Ratings and Classification

2 Terms and Definitions

3 Guidelines for Accessible Document Production

4 Guidelines for Ensuring an Accessible Authoring Environment

5 Appendices

6 Acknowledgments

7 References

1 Ratings and Classification

Some of the guidelines are classified according to the following rating system.

[Priority 1]
This guideline must be implemented by an authoring tool, or one or more groups of users will find it impossible to access either the tool or some of the information in documents produced by the tool. Implementing this guideline will significantly improve access to Web documents.
[Priority 2]
This guideline should be implemented by an authoring tool, or one or more groups of users will find it difficult to access either the tool or some of the information in documents produced by the tool. Implementing this guideline will improve access to Web documents.
[Priority 3]
This guideline should be implemented by an authoring tool to make it easier for one or more groups of users to access either the tool or some of the information in documents produced by the tool. Implementing this guideline is not critical to accessibility, however.

2 Terms and Definitions

2.1 Markup Authoring, Conversion and Generation Tools

Authoring Tool
An Authoring Tool is any application that is specifically designed to aid users in the editing of markup language documents. The editing processes covered by this definition may range from direct hand coding (with automated syntax support or other markup specific features) to WYSIWYG editors that allow markup to be produced from a browsing perspective. This definition does not include text editors and word processors that also allow HTML to be hand produced.
Conversion Tool
A Conversion Tool is any application or application feature that allows content in some other format (proprietary or not) to be converted automatically into a particular markup language. This includes dedicated Web publishers as well as "save as HTML"(or other markup format) features in non-markup applications.
Generation Tool
A Generation Tool is a program or script that produces automatic markup "on the fly" following a template or set of rules.

2.2 Inaccessible Markup

Inaccessible Markup, Inaccessible Element, Inaccessible Attribute, Inaccessible Authoring Practice and Access Barrier
All these terms are used in the context of inaccessibility as defined by the WAI Accessibility Guidelines: Page Authoring.

2.3 Documents, Elements, and Attributes

Document
A document is a series of elements that are defined by a language (e.g., HTML 4.0 or an XML application).
Element
Each element consists of a name that identifies the type of element, optional attributes that take values, and (possibly empty) content.
Attributes
Some attributes are integral to document accessibility (e.g., the "alt", "title", and "longdesc" attributes in HTML).
Rendered Content
The rendered content is that which an element actually causes to be rendered by the user agent. This may differ from the element's structural content. For example, some elements cause external data to be rendered (e.g., the IMG element in HTML), and in some cases, browsers may render the value of an attribute (e.g., "alt", "title") in place of the element's content.

2.4 Properties, Values, and Defaults

Properties
Properties describe the presentation of a document (e.g., font face, font sizes for different headers, paragraph justification, text color, etc.).
Current Value
Each property has a current value at any moment (e.g., "Helvetica" for font face, "12 point" for font size, "black" for text color, etc.) The current value comes from one of the following sources: browser, document, or user.
Default Value
The value given to a property when the browser is first "turned on" is called the default value. Browsers may allow users to change default values through a variety of mechanisms (e.g., the user interface, style sheets, initialization files, etc.). Setting the current value of a property does not change the default value.
Author Styles
A property may receive its current value when the user agent reads a document: through style sheets within the document or linked externally, through the presentation attributes of an element, via a server, etc. These values are called author styles.
User Styles
The user may set the current value through user style sheets or the user interface; these are called user styles.

2.5 Selection, Focus, and Events

Authoring tools allow users to interact with document through several mechanisms.

Views
An authoring tool may offer several views of the same document. For instance, one view may show raw markup, a second may show a structured tree view, a third may show markup with rendered objects while a final view shows an example of how the document may appear if it were to be rendered by a particular browser.
Viewport
A user accesses the information in a view through a window, frame, or other viewport. The size of the viewport may prevent the user from accessing all of the information in the view at once; viewports may offer scrolling mechanisms to give access to all of the view's information.
Selection
A selection is a set of elements identified for a particular operation. The user selection identifies a set of elements for certain types of user interaction (e.g., cut, copy, and paste operations). The user selection may be established by the user (e.g., by a pointing device or the keyboard) or via an accessibility API. A view may have several selections, but only one user selection.
Current User Selection
When several views co-exist, each may have a user selection, but only one is active, called the current user selection. The selections may be rendered specially (e.g., visually highlighted). [Note: highlighted text is often used by third-party assistive technologies to indicate through speech or Braille output what the user wants read. Most screen readers are sensitive to highlight colors. Third-party assistive technologies may provide alternative presentation of the selection through speech, enlargement, or dynamic Braille display.]
Focus
The focus designates the element (link, form control, element with associated scripts) in a view that will react when the user next interacts with the document.
Activate
The user is said to activate the element with the focus. For instance, a user may activate a link (which usually causes the user agent to follow the link), a form control (which usually causes a change of state in the form control), or an element with associated scripts. A view has only one focus.
Current Focus
When several views co-exist, each may have a focus, but only one is active, called the current focus.
Current View
Both the current focus and the current user selection must be in the same view, called the current view.

2.6 Alternate Text and Description Links

Alternate Textual Representations
Certain types of content may not be accessible to all users (e.g., images), so authoring toold must ensure that alternate textual representations ("Alt-text") of information be available to the user. Alternate text can come from element content (e.g., the OBJECT element) or attributes (e.g., "alt" or "title").
Description Link (D-link)
A description link, or D-Link, is an author-supplied link to additional information about a piece of content that might otherwise be difficult to access (image, applet, video, etc.). The "WAI Accessibility Guidelines: Page Authoring" document (see [WAI-PAGEAUTH]) describes when and how to insert description links in a document. D-links should be identified in the document source by giving the "rel" attribute the value "dlink".

2.7 Inserting and Editing

Inserting an element
Inserting an element involves placing that element's markup within the markup of the file. This applies to all insertions, including, but not limited to, direct coding in a text editing mode, choosing an automated insertion from a pull down menu or tool bar button, "drag-and-drop" style insertions, or "paste" operations.
Editing an element
Editing an element involves making changes to one or more of an element's attributes or properties. This applies to all editing, including, but not limited to, direct coding in a text editing mode, making changes to a property dialog or direct UI manipulation.
 

2.8 Miscellaneous

Emphasis
Emphasis refers to the practice of drawing attention to an option or component within a user interface. This may be acheived with techniques including, but not limited to, placement, coloration, font, special icons, or layout.
Prompting
Prompting refers to requesting or encouraging the author to follow a given set of steps. In the context of this document, prompting will usually refer to requests for small amounts of descriptive information or organizational structure.
Automated authoring aids
Automated authoring aids are the features of an authoring tool that allow the user to produce markup without directly typing it. This defines a wide range of tools from simple markup insertion aids (such as a bold button on a toolbar) to markup managers (such as table makers that include powerful tools such as "split cells" that can make multiple changes) to high level site building wizards that produce almost complete documents on the basis of a series of user preferences.

3 Guidelines for Development of Web Authoring Tools that Support Accessibility

3.A Integration of accessibility awareness

3.A.1 [Priority 1] Support all accessiblity features of relevant languages (HTML, CSS, SMIL, XML, etc.)

Implementation Priorities:

Accessibility Features

3.A.2 [Priority 1] Emphasize accessible authoring practices

All recommended page author solutions (and their priorities) must be taken into account during the design of relevant user interface components and program functionality. In particular:

3.A.3 [Priority 1] Expose all inaccessible markup

Whenever the authoring tool processes markup text, it must check for and expose all inaccessible markup. This includes continuously checking documents during editing as well as checking previously existing documents (created by any means) if they are opened for further editing. Any problems should be advertised to the author immediately, even if the option of delaying the correction is left open. Suggested methods for alerting the user include:

3.A.4  [Priority 2] Promote accessibility awareness in tool suites

Language markup authoring tools often form part of integrated web publishing suites that also include peripheral tools for handling non-coding tasks. Examples of these tools and recommended roles they may play in an integrated accessibility approach appear below:

3.A.5  [Priority 2] Integrate accessibility features naturally

When a new feature is added to an established software tool without proper integration, color schemes, fonts, and interaction styles may differ and interface bugs may be more frequent.

In order to gain user acceptance of accessible authoring, it is imperative that the any new functionality associated with accessibility be properly integrated into the overall "look and feel" of the authoring tool. By making small modificications to all the pre-existing interface components that are relevant to accessibility awareness , the need for dedicated components will be reduced, keeping the footprint of the accessibility changes to a minimum..

3.A.6  [Priority 3] Allow users to configure levels of accessibility awareness

Authoring tools should be designed so that accessibility awareness is at least partially user configurable. The author should be given the freedom to customize the system within the constraints of the priority levels defined by the WAI Accessibility Guidelines: Page Authoring. In particular:

3.B Provision of accessibility information

3.B.1  [Priority 1] Provide context-sensitive accessibility help to authors

The issue of web accessibility is 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.

The focus or edit position within the authoring environment when the Help system is activated should be used to provide the context for the help response. It is especially important to implement context sensitive help for any special accessibility icons, outlining or other emphasis within the user interface, since these may appear foreign.

The help files themselves, should explain the accessibility problem or accessibility feature quickly, with emphasis placed on the solutions available rather than the incorrectness of using a certain markup element. The help files should include frequent examples as well as links to any automated correction utilities (See Section 3.C.5).

The WAI Accessibility Guidelines: Page Authoring and WAI Accessibility Guidelines: Page Authoring Techniques have now been structured in a way that simplifies the task of writing help files, since the problem, rationale and solution techniques are all stated explictly.

3.B.2  [Priority 1] Provide rationales that stress Universal Design

Since most users probably have little knowledge of accessibility issues, it is understandable that they will question the justification for certain requests. The author attitude that accessibility means devoting time and effort to things they believe will never use is a major acceptance barrier. Therefore, justification should comprise an important part of the accessibility Help system. Within the justification area it will be important to emphasize the wider benefits of providing Universal Design. The major argument of these justifications should be that most authoring decisions that support access for users with disabilities also have benefits for users with other needs or abilities. The principles of supporting flexible display and control choices has obvious advantages for:

The justifications should also address:

For more information on Universal Design, see the WAI Justifications Document

3.B.3  [Priority 2] Ensure that all Help examples are accessible (Weak? - I. Jacobs)

In addition to the dedicated accessibility help section (see 3.B.1, 3.B.2), accessiblity principles should be followed for all applicable markup examples in the rest of the help system. In particular:

This will increase integration and help show authors that accessibility is a normal part of authoring, rather than a separate concern.

3.B.4 [Priority 2]  Package multimedia files with pre-written descriptions

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

Authoring tool developers should include professionally written descriptions for all multimedia files shipped with their tools in order to satisfy the following important objectives:

  1. users will be saved time and effort
  2. a significant number of professionally written descriptions will begin to circulate
  3. users will be provided with convenient models to emulate when they write their own descriptions
  4. users will see evidence of the importance of description writing

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.

The inclusion of descriptions has the additional benefit of allowing authors to make time-saving searches of the multimedia database.

 

3.C Accessibility Task automation

The key to increasing the accessibility of the web is to take advantage of the power of automation to free authors to concentrate on the higher-level aspects of web authoring.

3.C.1  [Priority 1] Allow the user to check for and correct accessibility problems automatically

Many authoring tools allow their users to create markup documents with little or no knowledge about the underlying structure of the language. Accessibility problems must be corrected in an analgous fashion. Every authoring tool must include some kind of automated tool for automatically traversing a document to identify and help correct accessibility problems as they are defined by the WAI Accessibility Guidelines: Page Authoring. The tool must be designed to allow authors the option of making corrections without necessarily understanding either the details of markup accessibility.

3.C.2  [Priority 1] Ensure that all markup inserted through the user interface is accessible

When markup is automatically generated, the author has, by definition, lost the ability to precisely specify the nature of the produced markup.If the automation results int inaccessible markup, authors who are aware of access issues will have to expend extra effort to make the appropriate corrections by hand. However, most authors will continue, unaware of the problem.

Automated authoring aids should always make use of appropriate accessible solutions, even if this means presenting the author with extra prompts for necessary information or structure. Under no circumstances should these tools make use of algorithms that automatically produce inaccessible markup.

3.C.3  [Priority 1] Ensure that conversion tools 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 often hidden from the user's view and creates inaccessible documents. Just as it is recommended that authoring aids not produce inaccessible markup (See Section 3.C.2), conversion utilities should also avoid generating documents that contravene the WAI Accessibility Guidelines: Page Authoring. Ensuring that accessible solutions are produced will most likely involve both prompting the author to supply alternative information as well as minor changes to the aesthetic appearance of the document.

3.C.4  [Priority 1] Avoid removing or modifying any of the existing structure or descriptive content of documents

When a document is opened by an authoring tool that did not create it, changes often need to be made to the markup to allow efficient functionning of the tool.   Unfortunately these modifications often have the effect of removing markup required for accessibility. Therefore:

4 Guidelines for Ensuring an Accessible Authoring Environment

Section Editors: Treviranus

Closely related to UA group because editing is very similar to browsing.  This group also does a good job of pointing to resources.

Some original stuff about an authoring UI - accessible dialogs, alternatives to icons etc.

Also needs links to resources for making software accessible.

5 Appendices: Authoring Tool Techniques (May Form a separate Techniques document)

The following appendices are examples of how authoring tools might be modified to take accessibility into account. Each module deals with a serious accessible authoring issue: "alt"-text, tables, forms and 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.

Appendix A: HTML4.0 "Alt"-Text Module

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.

A.1 Sample Support Strategies

The following strategy deals exclusively with images. However, the strategy could just as easily apply to the other elements that require "alt"-text.

A.2 Images (IMG)

Sample Warning Text:
"The IMG element that has just been inserted requires "alt"-text."
Important Points for Help File Text:
Images are the most common inaccessible elements on the web.
Screen readers, used by people with visual disabilities, cannot access the image content (including any graphically presented text).
Users of text only browsers or slow connections often navigate with Image Loading turned off.
Images can be made more accessible using the "alt" (alternate text) attribute of the IMG element to add a short textual description, which can be displayed in place of the image by text-based browsers and graphical browsers whose image loading has been disabled.
Refer to WAI Accessibility Guidelines: Page Authoring Techniques Document for ""alt""-text help file authoring tips:

A.3 Applets

Sample Warning Text
"The APPLET element that has just been inserted requires "alt"-text"
Important Points for Help File Text
The APPLET element is deprecated, so it should be avoided.
If it is used, the APPLET element should include an "alt"-text that describes its function and content.
Alternate textual presentations of the content should also be made available.

A.4 Image Maps (Client-Side and Server-Side)

Sample Warning Text
"The image map that has just been inserted requires "alt"-text"
Important Points for Help File Text
Image maps are a very popular and effective way of conveying information.
To access an image map, a user requires a graphical browser, a fast connection as well as the physical ability to see the screen and move a mouse pointer.
Client-side image maps (that use the AREA element to define their links) can be accessed by keyboard control within several browsers.  If "alt"-text is provided for each link then these image maps become accessible to people with visual impairments.   Therefore, it is recommended that you convert any server-side image maps into client-side image maps.
It is always recommended that a textual listing of the links within all server-side and client-side image maps for users with older browsers or slow connections be provided..

A.5 Image Map Links (AREA)

Sample Warning Text
"The image map link (AREA) that has just been inserted requires "alt"-text"
Important Points for Help File Text
The AREA element defines the individual link hotspots within a client-side image map.
Some browsers have a keyboard function that allows users to TAB through all the links on a page, including each AREA. This feature is important for users with visual or mobility disabilities, who have difficulty controlling a mouse effectively.
In order for a client-side image map to be accessible, each AREA element must have an "alt"-text description that describes the function of the link.
"Alt"-text for the full image map is still required to tell the user that the image is an image map. This text should also emphasize whether there are alternative text links or if the reader should rely on the alt-text for the AREAs.
A descriptive text file may also be used to give users the full flavour of the image map's design and purpose.

A.6 Sample Automated Tools

A.6.1 ALT Text Registry

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.

A.6.2 Server-Side to Client-Side Image Map Converter

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.

A.6.3 Description Text Editor

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.

Appendix B: HTML4.0 Tables Module

Section Editors: Bingham, ???

[Priority 2] Authors should be aided in providing proper structure for tables.

B.1 Sample Support Strategies

B.2 Tables

B.3 Sample Automated Tools

Appendix C: HTML4.0 Forms Module

Section Editors: Richards, Treviranus

Improvements in access and user agent technologyhave meant that forms are not as inaccessible as they once were (for those users with the newest technology). However, the practice of good organization and labelling is always necessary because it helps all users.

C.1 Sample Support Strategies

C.2 Forms

Sample Warning Text
"The form control element that has just been inserted requires an associated LABEL element."
Important Points for Help File Text
Forms are becoming more universally accessible as browsing technology advances.
However, forms with many controls that rely on visual layout for their organization can be exteremly difficult to navigate without a screen.
For example, the association between an edit box and the text label, that identifies the type of information the reader should enter, is often purely visual.
The new LABEL element in HTML4.0 allows labels to be logically associated with form controls.
The FIELDSET element allows controls to be grouped within dialog type organizational boxes.
HTML4.0  includes the TABINDEX and ACCESSKEY elements.  TABINDEX allows authors to define a keyboard navigation order for links and form controls and ACCESSKEY allows quick keys to be defined for frequently used links and form controls.
In order to ensure full accessibility, alternative contact information should always be provided (e.g. email, phone numbers, fax numbers and postal addresses).

C.3 Sample Automated Tools

C.3.1 LABEL Maker

Whenever a form control without an implict label (e.g. edit box, pull down menu, etc.) is inserted, this tool automatically defines a default ID for the form control and uses this to link an associated LABEL element (using the "for" attribute). The tool immediately places the LABEL to the right of the form control with focus. Tooltip text informs the user that a label text should be entered and that the position of the label can be changed. If the user changes the form controls ID, the tool will ask the user if they wish to update the LABEL's "for" attribute as well. After a LABEL has been created, selection of the LABEL or FORM control will cause a visual emphasis of both elements in the associated pair.element.

C.3.2 FIELDSET Grouper

This tool will suggest the creation of a FIELDSET group box whenever an ungrouped set of five or more form controls is inserted by the author. If the author agrees, a FIELDSET element will be inserted to enclose the controls. The LEGEND element that defines a heading of the group box will receive focus at the end of the operation and a tool tip will instruct the author to enter a heading for the controls.

C.3.3 TABINDEX and ACCESSKEY Assignment Mode

This tool is a mode that allows the user to define either tab order or a hotkey. Once the mode is activated (by menu item or toolbar button), the present tab order and any existing hot keys are displayed. The author can the change the tab order by selecting the links or form controls in the preffered order, with the mouse or keyboard. Holding a key while selecting a link or form contol will create an ACCESSKEY shortcut.

Appendix D: HTML4.0 File Conversion Module

Section Editors: Richards, Treviranus, ???

[Priority 1] Avoid removing or modifying existing structure (especially "alt"-text) without user notification.

[Priority 1] Avoid automated use of any inaccessible markup.

D.1 Sample Support Strategies

D.2 Sample Automated Tools

6 Acknowledgments

7 References

[HTML40]
"HTML 4.0 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds. The HTML 4.0 Recommendation is available at:
http://www.w3.org/TR/REC-html40/.
[CSS1]
"CSS, level 1 Recommendation", B. Bos, H. Wium Lie, eds. The CSS1 Recommendation is available at:
http://www.w3.org/TR/REC-CSS1-961217/.
[CSS2]
"CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, eds. The CSS2 Recommendation is available at:
http://www.w3.org/TR/REC-CSS2/.
[WAI-PAGEAUTH]
"WAI Accessibility Guidelines: Page Authoring", G. Vanderheiden, W. Chisholm, and I. Jacobs, eds. These guidelines for designing accessible documents are available at:
http://www.w3.org/TR/WD-WAI-PAGEAUTH.
[Page Authoring Techniques]
"WAI Accessibility Guidelines: Page Authoring Techniques", G. Vanderheiden, W. Chisholm, and I. Jacobs, eds. These guidelines for designing accessible documents are available at:
http://www.w3.org/WAI/wai-gl-techniques.
[CSS2-ACCESS]
"WAI Resources: CSS2 Accessibility Improvements", I. Jacobs and J. Brewer, eds. This document, which describes accessibility features in CSS2, is available at:
http://www.w3.org/WAI/References/CSS2-access.
[HTML4-ACCESS]
"WAI Resources: HTML 4.0 Accessibility Improvements", I. Jacobs, J. Brewer, and D. Dardailler, eds. This document, which describes accessibility features in HTML 4.0, is available at:
http://www.w3.org/WAI/References/HTML4-access.
[Access Aware Authoring Tools]
"The Three -tions of Accessibility-Aware HTML Authoring Tools", J. Richards. Available at:
http://www.utoronto.ca/atrc/rd/hm/3tions.htm.

Copyright © 1998 W3C (MIT, INRIA, Keio ), All Rights Reserved.