Selecting and Using Authoring Tools for Web Accessibility
As of the last revision of this document, we were unaware of any singleauthoring tool that fully supports production of accessible websites. Somedevelopers are improving the support of accessibility in their authoringtools, and some utilities may help supplement gaps in existing authoringtools.
This document provides information which may help find improved authoringtools and/or work around the gaps in existing authoring tools. It includesquestions to ask software vendors regarding accessibility support in currentand upcoming product versions according to their conformance with W3C'sAuthoring Tool Accessibility Guidelines (ATAG).
ATAG addresses all kinds of authoring tools, including content management systems (CMS), WYSIWYG ("WhatYou See Is What You Get") tools, save-as-HTML conversion tools such as wordprocessors, database-generation tools, site management tools, etc. ATAG has a companion set of techniques to helpsoftware developers implement ATAG in their products. ATAG explainsto authoring tool developers how to make their products:
- support accessible authoring practices;
- generate standard markup;
- support the creation of accessible content;
- provide ways of checking and correcting inaccessible content;
- integrate accessibility support into the overall look and feel of the product;
- promote accessibility in help and documentation; and
- ensure that the tool is accessible to authors with disabilities.
Evaluating software currently in use by an organization:
- Do authoring tools currently in use support or hinder the production of accessible websites? Be sure to broadly consider content management systems (CMS), WYSIWYG ("What You See Is What You Get") HTML editors; conversion tools such as word processors or presentation software with "save as HTML" buttons; applications that generate web pages from databases; image editors; multimedia editors; site management tools, etc.
- Do authoring tools currently in use change or remove accessibility information (for instance, alternative text for images) that has been added by other tools or by hand mark-up?
- For authoring tools that do not support the creation of accessible content, are there plug-ins or other utilities that can be used with those products to better support the production of accessible websites?
Selecting new or replacement software:
- Which applications are more conformant with ATAG?
- For which applications are there plug-ins that fill gaps in accessibility support for the primary product?
- Which applications carry a developer's commitment to continue to improve ATAG conformance in future versions?
Reviewing software procurement practices:
- Do procurement policies within the organization encourage or require purchase of applications with more advanced support for accessibility?
- For organizations with a concentration of purchasing power, is there an avenue through which to communicate the organization's interest in ATAG-conformant software to vendors, so that they are aware of the demand for these features?
Questioning software vendors about product support:
- Does the product conform to W3C'sAuthoring Tool Accessibility Guidelines (ATAG)?
- If not, when does the company plan to release a conformant version?
- Can the vendor demonstrate the existing accessibility support in their product(s)?
- Are there plug-ins that can be used with their product(s) to more effectively support creation of accessible websites?
- Can a suite of tools be established to provide the accessibility that the specific authoring tool lacks?
- (In countries where there are government requirements for web accessibility) What features has the company added to their product(s) to support web accessibility requirements?
- Who would be a good contact person in the company for more information concerning products' accessibility?
Until authoring tools that more fully conform to ATAG are available,it is helpful to develop strategies to work around the limitations ofexisting tools. Steps to developing such strategies include:
- become familiar with the general concepts (at the guideline level, not necessarily the individual success criteria/checkpoints) in Web Content Accessibility Guidelines (WCAG) and ATAG;
- identify key limitations of authoring tools currently in use within an organization (by noting recurring problems in inaccessible output from those authoring tools; reading accessibility reviews of the products(s); noting feature support of ATAG success criteria/checkpoints; etc.);
- locate plug-ins or utilities which can be used in combination with a given authoring tool to correct inaccessible output;
- develop an in-house process or checklist for correcting accessibility problems generated by these tools.
Examples of strategies to work around limitations of existing authoringtools:
Note: ATAG 1.0 was the completed version when this document was published. To get updated information on later versions of ATAG, see theATAG Overview.
- If the templates provided with an authoring tool do not conform to WCAG [ATAG 1.0 Checkpoint 1.4], develop WCAG-conformant templates appropriate to your organization's needs, and distribute throughout the organization.
- If an authoring tool does not create valid markup [ATAG 1.0 Checkpoint 2.2] according to a published Document Type Definition (DTD), use it in conjunction with a clean-up tool such asHTML Tidy.
- If a multimedia authoring tool does not support the creation of captions for audio [ATAG 1.0 Checkpoint 1.1], use it in conjunction a caption editor such asMagpie.
- For authoring systems primarily designed to produce print media (for example, Acrobat, PageMaker, Quark Express), rich media (Director, Flash, ToolBook), word processing (Word, Word Perfect), presentations (PowerPoint, Freelance, Visio), go back to the original source material where possible and generate an accessible HTML or XHTML version from the source; or run file through a converter if available then check the accuracy of the conversion; or recreate the materials in a known accessible format; then also post the accessible format on the site [ATAG 1.0 Checkpoint 2.1].
- If an authoring tool being used to retrofit an existing site doesn't prompt for missing alternative text [ATAG 1.0 Checkpoint 3.1], use an accessibility-retrofitting tool that both prompts for missing accessibility information and provides a means to insert the missing information.
- If an authoring tool does not insert a Document Type Declaration (DTD) (necessary for validation of markup, and for conformant HTML, XHTML, etc.)[ATAG 1.0 Checkpoint 2.2], look for an extension which inserts the appropriate DTD, or insert the DTD by hand.
- If an authoring tool does not support cascading style sheets [ATAG 1.0 Checkpoint 3.2 &ATAG 1.0 Checkpoint 4.5], use it in conjunction with a compatible style sheet editor.
- If an authoring tool does not display a linearized version of tables [ATAG 1.0 Checkpoint 3.2], use it in conjunction withLynx orLynx-me, or someother text browser ortext browser emulator.
- If an authoring tool does not preserve all accessibility information during authoring, transformations, and conversions [ATAG 1.0 Checkpoint 1.2], either edit by hand and save straight to source, or get a new authoring tool.
- If an authoring tool automatically generates equivalent alternatives [ATAG 1.0 Checkpoint 1.3], e.g. by inserting file name as alternative text, turn off that function, or manually check and correct all alternative text.
TheAuthoring Tool Accessibility Guidelines WorkingGroup (AUWG) previouslyreviewed authoringtools for conformance with ATAG. As of the last revision ofthis document, the reviews were not up-to-date and therefore may not represent the latest progress in ATAGconformance. In the future, the AUWG may update product reviews on a collaborative basiswith developers; assistance and feedback on reviews is helpful.
In some cases developers have information on their own sites describing the degree of accessibility support in their products. Developers' accessibility pages may contain links to plug-ins which enhance the capability of an authoring tool to support the production of accessible web content.
Document Information
Status: Published October 2002, minor updates in November 2011 (to account for WCAG 2.0 publication; otherwise, not edited)
Editor: Judy Brewer and the Education and Outreach Working Group (EOWG).