Techniques for Authoring Tool Accessibility Guidelines 1.0

For further information about Working Group decisions, please consult the minutes of AUWG Meetings.

A list of current W3C Recommendations and other technical documents including Working Drafts and Notes can be found at http://www.w3.org/TR.

Note on applicability of techniques: The following techniques are applicable to all kinds of authoring tools, including those that are insertable components of other authoring tools. For example, if an authoring tool for designing on-line courses (courseware) a pre-fabricated chat facility that the instructor can drag on to their page, this component must comply with all the techniques for accessible output (guidelines 1-6) and accessible user interface (guideline 7).

Proposed Authoring Tool Categories

Note: For the purposes of these techniques, authoring tools may fall into one or more of the following categories. For example, an HTML authoring tool that allows the user to create JavaScripts will fall under two categories, Markup Editing Tools and Programming Tools. A SMIL editor that includes a text-only view of the markup and a preview mode would be considered both a Markup Editing Tool and a Multimedia Creation Tool.

1. Markup Editing Tools: Tools that assist authors to produce markup documents. These include text-based and WYSIWYG markup editors for HTML, XHTML, SMIL, etc. and word processors that save as markup formats.

2. Multimedia Creation Tools: Tools that assist authors to create multimedia Web content without allowing access to the raw markup or code of the output format. These include multimedia production tools outputting SMIL or Quicktime as well as image editors, video editors, sounds editors, etc.

3. Content Management Tools: Tools that assist authors to create and organize specific types of Web content without the author having control over the markup or programming implementation. Good examples include courseware in which the author is prompted to enter various information which is then displayed in a format determined by the tool. Note: If the tool allows the author to control the markup that is actaully used to implement the higher-order content, then that functionality would be considered to be a Markup Editing Tool.

4. Programming Tools: Tools for creating all kinds of Web Applications, including Java applets, Flash, server and client-side scripts, etc.Also includes tools that assist authors to create markup languages (i.e. XML) and tools that assist authors to create user interfaces (i.e. UIML?).

2 Techniques by ATAG Guideline

Guideline 4. Provide ways of checking and correcting inaccessible content.

Checkpoints:

Evaluation Techniques for testing conformance

Is your tool:

specifically designed to edit and produce Web content?
equipped with the option of saving material in a Web format?
able to transform non-Web documents into Web formats (e.g., filters to transform desktop publishing formats to HTML)?
capable of producing multimedia, especially where it is intended for use on the Web?

If the answer to any of these questions is "yes", then the authoring tool accessibility guidelines apply to your software. This document will help you determine whether your tool complies with the guidleines or not.

IMPORTANT NOTE: Not all the checkpoints in the guidelines apply to all kinds of tools. Therefore, this conformance evaluation process has been split into sections:

If your the tool allow you to insert image elements into a markup document (ex. Web authoring tool, word processessor), then the tool is a "Markup Editor". You need to complete Section A.
If your tool allows you to create or edit images (ex. paint or drawing program), then the tool is a "Multimedia Editor".

General requirements:

[Priority 2]

Does the tool support the latest version of all the markup languages it can be used to produce? (2.1)

Documentation

Accessible Interface:

[Priority 1]

Does the tool allow you to edit all properties in an accessible fashion? (7.3)

Markup Editor

PART 1: Images (including Image Maps)

IMPORTANT DEFINITION: Equivalent Alternatives (EA)

An equivalent alternative (EA) is content that fulfills essentially the same function or purpose upon presentation to the user as the potentially inaccessible primary content. EAs play an important role in accessible authoring practices since certain types of content may not be accessible to all users (e.g., video, images, audio, etc.). For more information, see the Web Content Accessibility Guidelines WCAG 1.0.

The Images Part of this document will refer to two priorities (1 and 3; there are 2's) of EAs according to the priority assigned to it by the WCAG 1.0 recommendation. If a priority is not specified then both priority levels are assumed. The following is a list of EAs followed by their priority and the relevant WCAG checkpoint that assigned the priority.

for Images:

img:alt, img:longdesc, input:alt (HTML) - [Priority 1] (wcag 1.1)
g:title, g:desc (SVG) - [Priority 1] (wcag 1.1)
img:alt, img:longdesc, img:text (SMIL) - [Priority 1] (wcag 1.1)

for Image Maps:

area:alt (HTML) - [Priority 1] (wcag 1.1)
server-side image map regions:redundant text links (HTML) - [Priority 1] (wcag 1.2)
client-side image map regions:redundant text links (HTML) - [Priority 3] (wcag 1.5)

for Objects displaying Images:

object: text equivalent in the element content (HTML) - [Priority 1] (wcag 1.2)

NOTE: It is assumed that the term EA will refer to those EAs appropriate to the type of markup or image produced. (ex. an HTML editor only needs to be checked for the EAs relevant to HTML)

Inserting an Image:

INSTRUCTIONS: Use the tool to insert an image into a document and then answer questions X to Y. If the tool is capable of inserting an image by drag and drop, test this method as well. Answer questions Q1 to Q4.

[Priority 1]

Did the tool allow you to add the Equivalent Alternatives (EAs) for the image (including typing one by hand after insertion)? (1.1)

Did the tool automatically generate EAs based on the file name, size or other information that is not necessarily related to the function of the image.?(note: different scoring - the tool must not do this) (3.4)

[Priority 2]

Did the tool support the PNG format for inserting raster images and the SVG format for inserting vector graphics? (2.1)

[Priority 3]

Does the tool let you search for, reuse or otherwise manage the EAs of images? (3.5)

Saving:

INSTRUCTIONS: Use the tool to save the document. Answer questions Q5 and Q6.

[Priority 1] Did the tool prompt (require, suggest or notify you of the absence of information and then provide a means for rectifying the situation) you to add Priority 1 EAs for all the images at some point during the creation of the document (ex. at insertion of each image, after the successful save, etc.)? (3.1)

[Priority 3]

Did the tool prompt (require, suggest or notify you of the absence of information and then provide a means for rectifying the situation) for the addition of Priority 3 EAs for all the images at some point during the creation of the document (ex. at insertion of each image, after the successful save, etc.)? (3.1)

Re-saving and Reformatting:

INSTRUCTIONS: Create a new file with the following markup (appropriate to the tool). The EAs are shown in bold. Open the file using the authoring tool. Save the file and re-open it in a text editor.

HTML:

<html> <head> <title> </title> </head> <body>

<img src="map.gif" alt="Map of the world" longdesc="mapdesc.html">

<form method="POST" action="http://somesite.com/prog/someprog"> <p><input type="image" src="map.gif" name="mapbutton" alt="Buy map"></form>

<img src="map.gif" alt="Image map of the world" usemap="#map1"> <p>[<a href="na.html">North America</a>] [<a href="sa.html">South America</a>]</p> <map name="map1"> <area shape="rect" coords="0,0,30,30" href="na.html" alt="North America"> <area shape="rect" coords="34,34,100,100" href="sa.html" alt="South America"></map>

<a href="http://myserver.com/cgi-bin/imagemap/my-map"> <img src="map.gif" alt="World map (Text links follow)" ismap></a> <p>[<a href="na.html">North America</a>] [<a href="sa.html">South America</a>]</p>

<object data="magnify.gif" type="image/gif">Search</object>

</body> </html>

[Priority 1]

Does the tool preserve the values of the EAs during re-saving? (1.2)

INSTRUCTIONS: Create a new file with the markup above (appropriate to the tool). Then "Round-trip" the file by saving it as another format and then saving it back to the original (note: for this to work, the other format chosen must include equivalent EAs, ex. HTML to XHTML and back).

[Priority 1]

Does the tool preserve the values of the EAs during reformatting? (1.2)

INSTRUCTIONS: Create a new file with the following markup (appropriate to the tool). Open the file using the authoring tool. Save the file and re-open it in a text editor.

HTML:

<html> <head> <title> </title> </head> <body> <img src="test.gif" alt="test alt" longdesc="test.html" testattr="test for preserving unknown attributes"> </body> </html>

[Priority 2]

Does the tool preserve the unrecognized markup? ( 4.3)

[Priority 3]

Does the tool notify you that the output of the tool does not conform to W3C specifications (due to the new attribute)? (2.3)

Automatic Markup Generation:

INSTRUCTIONS: If the tool has the ability to add entire elements (ex. IMG), a groups of elements (toolbar generator) or even build a page for you (ex. a wizard), then use it to generate a page that contains at least one image. Save the file and re-open it in a text editor.

[Priority 1]

Does the tool automatically generate valid image markup (ex. is the required ALT attribute present for all HTML4 IMG elements)? (2.2)

Are meaningful Priority 1 EAs included for the generated images? (1.3)

[Priority 3]

Are meaningful Priority EAs included for the generated images? (1.3)

Bundled Web Content:

INSTRUCTIONS: If the tool includes templates, open one that has at least one image. Answer questions Q14 and Q15.

[Priority 1]

Are Priority 1 EAs included for the images in the template? (1.4)

[Priority 3]

Are Priority 3 EAs included for the images in the template? (1.4)

INSTRUCTIONS: If the tool includes bundled images (ex. clipart) , insert some into the document. Answer questions Q16 and Q17.

[Priority 1]

Do the images include pre-written Priority 1 EAs? (3.3)

[Priority 3]

Do the images include pre-written Priority 3 EAs? (3.3)

Checking for Accessibility:

INSTRUCTIONS: Create a new file with the following markup (appropriate to the tool) that has had its EAs removed. Open the file using the authoring tool.

HTML:

<html> <head> <title> </title> </head> <body>

<img src="map.gif">

<form method="POST" action="http://somesite.com/prog/someprog"> <p><input type="image" src="map.gif" name="mapbutton"></form>

<img src="map.gif" alt="Image map of the world" usemap="#map1"> <map name="map1"> <area shape="rect" coords="0,0,30,30" href="na.html"> <area shape="rect" coords="34,34,100,100" href="sa.html"></map>

<a href="http://myserver.com/cgi-bin/imagemap/my-map"> <img src="map.gif" ismap></a>

<object data="magnify.gif" type="image/gif"></object>

</body> </html>

[Priority 1]

Does the tool check for and notify you when Priority 1 EAs for images are absent? (4.1)

Does the tool assist you to add Priority 1 EAs for images when they are found to be absent? (4.2)

[Priority 3]

Does the tool check for and notify you when Priority 3 EAs for images are absent? (4.1)

Does the tool assist you to add Priority 3 EAs for images when they are found to be absent? (4.2)

Documentation:

[Priority 1]

Is there documentation for all the features of the tool concerned with adding EAs for images? (6.1)

[Priority 2]

Does the documentation regarding the EAs for images appear well integrated with the rest of the documentation (ex. do all images in the examples include EAs)? (6.2)

[Priority 3]

Is there a dedicated section that documents all the features of the tool concerned with addding EAs for images? (6.3)

User Interface Presence:

INSTRUCTIONS: Insert another image into a document. Then select the image and edit its EAs.

[Priority 2]

Does functionality for adding and editing the EAs for images appear well integrated with the overall look and feel of the tool (ex. included within standard image insertion and properties dialogs)? (5.1)

Priority 3: Only required for level Triple-A conformance

Are meaningful Priority 3 EAs included when multimedia content is part of markup generated by the tool (ex. wizard)? (1.3)

Are Priority 3 EAs included for multimedia content that appear as part of templates included with the distribution of the tool (ex. a video album template)? (1.4)

Does the tool prompt (require, suggest or notify the user of the absence of information and then provide a means for rectifying the situation) for the addition of Priority 3 EAs when an multimedia content is inserted? (3.1)

Does any multimedia content (ex. media clipart, etc.) that are included with the distibution of the tool include pre-written Priority 3 EAs? (3.3)

If the multimedia content-related output of the tool does not conform to W3C specifications , does the tool notify the author? (2.3)

Does the tool include the ability to search and reuse or otherwise manage the EAs of multimedia content? (3.5)

Does the tool check for and notify the author when Priority 3 EAs for multimedia content is absent? (4.1)

Does the tool assist the author in adding Priority 3 EAs for multimedia content when they are found to be absent? (4.2)

Forms

Insert a form and each of the following 7 types of control:

A text input
A textarea input
A set of radio buttons
A set of checkboxes
A drop down menu (html select element)
A graphic button
A submit button

Priority 1 tests

Is the control validly coded? in a valid way? (2.2)

Do template examples of forms work without scripts or applets? (1.4 and 3.3 WCAG 6.3)

For each control:

Can you specify an explicit label? (1.1)
Does the control work without scripts or applets (client-side) for processing? (1.3, WCAG 6.3)
Is there a check for this? (4.1)
Is there help on how to fix it? (4.2)
Is it documented how to add a label to a control?
How to group controls? (6.1)
Can you edit all the properties of the control? (7.3)
Is the control validly coded? in a valid way? (2.2)

Priority 2 tests

If there are scripts, does the tool preserve them where it doesn't recognise them? (4.3)

Perform each of the following three tests once for each control, and then answer the next set of 4 questions about the features tested by each task.

Does the form control work according to W3C specifications (2.1)
Are you prompted to add labels to form controls? (3.2, WCAG 12.4)
If there are scripts to handle the forms, do they have device-independent triggers? (1.3 WCAG 6.4, 9.2, 9.3)

The following 4 tests should be made for each of the 3 features tested above

Are the features checked for? (4.1, WCAG as above)
Is there help to fix them? (4.2, WCAG as above)
Are they included in documentation (and examples)? (6.2)
Are they present in prepackaged examples / templates? (1.4, 3.3 WCAG as above)

Priority 3 test

If the code does not conform to W3C specifications, does the tool inform you? (2.3)

Multimedia Tool

Note: Equivalent Alternatives (EA) for Image Editors

The meaning of the term equivalent alternative (EA) is slightly different for image editors than for markup editors. For markup editors, image EAs refer to those markup structures that convey alternative content about images in a document. These structures are specific to the markup language produced. For image editors, some of the EAs, those placed in the text tracks of images, are stored in set structures, however other EAs may be stored separately as plain text, RTF, or other format that may be retreived and used by markup editors when the image is inserted into a document.

Therefore, in this section the term Equivalent Alternative (EA) will refer more generally to short descriptive labels and long descriptive text. Both have priority 1, since that is their maximum priority once imported into HTML.

Short Descriptive Labels[Priority 1]:

May be stored in image formats with text tracks (i.e. PNG, SVG, WebCGM, JPEG, GIF)
Suitable for: img:alt (HTML, SMIL), img:longdesc (HTML), input:alt (HTML), g:title (SVG)

Long Descriptive Text [Priority 1]:

May be stored ???
Suitable for: img:longdesc (HTML, SMIL), g:desc (SVG)

Priority 1: Required for all levels of conformance (i.e. A, Double-A, Triple-A)

Is it possible to add the Equivalent Alternatives (EAs) for multimedia using the tool (includes typing them manually)? (1.1)

Does the tool preserve the values of the EAs during re-saving, reformatting, etc.? (1.2)

Are meaningful Priority 1 EAs included when multimedia content is part of markup generated by the tool (ex. wizard)? (1.3)

Are Priority 1 EAs included for multimedia content that appears as part of templates included with the distribution of the tool (ex. a photo album template)? (1.4)

Does the tool automatically generate valid markup with regard to multimedia content (ex. is the required ALT attribute present for all HTML4 IMG elements)? (2.2)

Does the tool prompt (require, suggest or notify the user of the absence of information and then provide a means for rectifying the situation) for the addition of Priority 1 EAs when an multimedia content is inserted? (3.1)

Does any multimedia content (ex. clipart, etc.) that is included with the distibution of the tool include pre-written Priority 1 EAs? (3.3)

Does the tool automatically generate EAs based on the file name, size or other information that is not necessarily related to the content or function of the multimedia content.? (3.4)

Does the tool resuse previously authored EAs without author confirmation when the function is not known with certainty (ex. the tool automatically uses the same ALT value for two copies of the same multimedia content that is linked to different locations)? (3.4)

Does the tool check for and notify the author when Priority 1 EAs for multimedia content is absent? (4.1)

Does the tool assist the author in adding Priority 1 EAs for multimedia content when they are found to be absent? (4.2)

Does the tool allow the author to edit all properties (attributes, styles, etc.) of multimedia content-related elements in an accessible fashion (i.e. using the keyboard)? (7.3)

Priority 2: Required for level Double-A and Triple-A conformance

Are meaningful Priority 2 EAs included when multimedia content is part of markup generated by the tool (ex. wizard)? (1.3)

Are Priority 2 EAs included for multimedia content that appear as part of templates included with the distribution of the tool (ex. a photo album template)? (1.4)

Does the tool prompt (require, suggest or notify the user of the absence of information and then provide a means for rectifying the situation) for the addition of Priority 2 EAs when multimedia content is inserted? (3.1)

Does any multimedia content (ex. clipart, etc.) that are included with the distibution of the tool include pre-written Priority 2 EAs? (3.3)

Does the tool support the latest version of all the markup languages it can be used to produce? (2.1)

Does the tool check for and notify the author when Priority 2 EAs for multimedia content is absent? (4.1)

Does the tool assist the author in adding Priority 2 EAs for multimedia content when they are found to be absent? (4.2)

Does the tool allow unrecognized markup to be preserved through the editing and re-saving process (ex. will the LONGDESC attribute of IMG be preserved if the tool does not support LONGDESC)? ( 4.3)

Does functionality for adding and editing the EAs for multimedia content appear well integrated with the overall look and feel of the tool (ex. included within standard multimedia content insertion and properties dialogs)? (5.1)

Does the documentation regarding the EAs for multimedia content appear well integrated with the rest of the documentation (used in examples throughout, not confined to a separate section)? (6.2)

Creating a New Image:

INSTRUCTIONS: Use the tool to create a new image file. Answer questions Q27 to Q31.

[Priority 1]

Is it possible to use the tool to author short or long descriptive EAs for the image (stored either separately or in text tracks)? (1.1)

Did the tool automatically generate EAs based on the file name, size or other information that is not necessarily related to the content or function of the image?(note: different scoring for this - the tool must not do this) (3.4)

[Priority 2]

If the tool is intended to produce raster images, does the tool support the Portable Network Graphics (PNG) format? (2.1)

If the tool is intended to produce vector graphics, does the tool support the Scalable Vector Graphics (SVG) format? (2.1)

[Priority 3]

Does the tool let you search for, reuse or otherwise manage the EAs of images? (3.5)

Saving:

INSTRUCTIONS: Use the tool to make a change to the image. Then save the image. Answer question Q32.

[Priority 1]

Does the tool prompt (require, suggest or notify you of the absence of information and then provide a means for rectifying the situation) you to add Priority 1 EAs at some point during the creation of the image (ex. after the successful save)? (3.1)

Re-saving and Reformatting:

INSTRUCTIONS: Open the test image "re-saving_test". Save a copy of the image file to "re-saving_test2". Open this file using the image EA viewer tool provided. Answer question Q33.

[Priority 1]

Are EAs (in text tracks or separate files) preserved during re-saving? (1.2)

INSTRUCTIONS: Open the test image "re-saving_test". Save a copy of the image file to another format. Open this file using the image EA viewer tool provided. Answer question Q34.

[Priority 1]

Are EAs (in text tracks or separate files) preserved during conversion to another format, where possible (i.e. EAs in text tracks placed in text track of new format or separate associated file if the new format does not include text tracks)? (1.2)

INSTRUCTIONS: Open a new image or save an image in order to check which imgae formats are available.

[Priority 3]

If the tool produces a raster image in a format besides PNG, does the tool inform you? (2.3)

If the tool produces a vector graphic image in a format besides SVG, does the tool inform you? (2.3)

Bundled Web Content:

INSTRUCTIONS: If the tool includes bundled images (ex. clipart), then insert some into the document. Answer questions Q37.

[Priority 1]

Do the images include pre-written Priority 1 EAs? (3.3)

Checking for Accessibility:

INSTRUCTIONS: Open and save "image_noEA". Answer questions Q38 and Q39.

[Priority 1]

Does the tool check for and notify you when Priority 1 EAs for an image are absent? (4.1)

Does the tool assist you to add Priority 1 EAs when they are found to be absent? (4.2)

Documentation:

[Priority 1]

Is there documentation for all the features of the tool concerned with addding EAs for images? (6.1)

[Priority 2]

Does the documentation regarding EAs appear well integrated with the rest of the documentation (ex. do all the image editing process examples include EAs)? (6.2)

[Priority 3]

Is there a dedicated section that documents all the features of the tool concerned with addding EAs? (6.3)

User Interface Presence:

INSTRUCTIONS: If it is possible to edit the EAs of an image, do so now. Answer question Q43

[Priority 2]

Does functionality for adding and editing the EAs appear well integrated with the overall look and feel of the tool (ex. included within standard properties dialogs)? (5.1)

Accessible Interface:

INSTRUCTIONS: This time, try and edit all the properties (not just the EAs) of the image using only the keyboard. Answer question Q44.

[Priority 1]

Does the tool allow you to edit all properties in an accessible fashion? (7.3)

Section C (Tool is an Multimedia Editor)

Priority 1: Required for all levels of conformance (i.e. A, Double-A, Triple-A)

If the tool supports multimedia content formats with text tracks (i.e. SVG, QuickTime, Flash), is it possible to use the tool to add Equivalent Alternatives (EAs) to the text tracks? (1.1)

Is it possible to use the tool to author Equivalent Alternatives (EAs) for the multimedia content that can be stored in separate files (ex. short (ALT) and long (LONGDESC) descriptive text files)? (1.1)

If the tool supports multimedia content formats with text tracks, are the text track values preserved during re-saving, conversion to another format that includes text tracks, etc.? (1.2)

If the tool supports separate descriptive files for multimedia content, are those files preserved during re-saving or conversion to another format, etc.? (1.2)

Does the tool prompt (require, suggest or notify the user of the absence of information and then provide a means for rectifying the situation) for the addition of separate or text track Priority 1 EAs at some point during the creation of multimedia content (ex. after a successful save)? (3.1)

Does the multimedia content (ex. video clipart, etc.) included in the tool's distibution packages include pre-written Priority 1 EAs stored in their text tracks or as separate descriptive files? (3.3)

Does the tool automatically generate EAs based on the file name, size or other information that is not necessarily related to the content or function of the multimedia content? (3.4)

If the tool supports multimedia content formats with text tracks, does the tool check for and notify the author when Priority 1 EAs are absent from this track? (4.1)

Does the tool check for and notify the author when separate descriptive files storing the Priority 1 EAs for multimedia content are absent? (4.1)

If the tool supports multimedia content formats with text tracks, does the tool assist the author in adding Priority 1 EAs when they are found to be absent? (4.2)

Does the tool assist the author in adding Priority 1 EAs to separate descriptive files when they are found to be absent? (4.2)

Does the tool allow the author to edit all properties (colour, size, transparency, etc.) of the multimedia content in an accessible fashion (i.e. using the keyboard)? (7.3)

Priority 2: Required for level Double-A and Triple-A conformance

If the tool is intended to produce vector graphics, does the tool support the Scalable Vector Graphics (SVG) format? (2.1)

Does the tool prompt (require, suggest or notify the user of the absence of information and then provide a means for rectifying the situation) for the addition of separate or text track Priority 2 EAs at some point during the creation of multimedia content (ex. after a successful save)? (3.1)

Does the multimedia content (ex. media clipart, etc.) included in the tool's distibution packages include pre-written Priority 2 EAs stored in their text tracks or as separate descriptive files? (3.3)

If the tool supports multimedia content formats with text tracks, does the tool check for and notify the author when Priority 2 EAs are absent from this track? (4.1)

Does the tool check for and notify the author when separate descriptive files storing the Priority 2 EAs for the multimedia content are absent? (4.1)

If the tool supports multimedia content formats with text tracks, does the tool assist the author in adding Priority 2 EAs when they are found to be absent? (4.2)

Does the tool assist the author in adding Priority 2 EAs to separate descriptive files when they are found to be absent? (4.2)

Does functionality for adding and editing the EAs stored in separate descriptive files or text tracks appear well integrated with the overall look and feel of the tool? (5.1)

Does the documentation regarding the adding and editing the EAs stored in separate descriptive files or text track appear well integrated with the rest of the documentation (used in examples throughout, not confined to a separate section)? (6.2)

Priority 3: Only required for level Triple-A conformance

If the tool produces a vector graphic image in a format besides SVG, does the tool inform the author? (2.3)

Does the tool prompt (require, suggest or notify the user of the absence of information and then provide a means for rectifying the situation) for the addition of separate or text track Priority 3 EAs at some point during the creation of multimedia content (ex. after a successful save)? (3.1)

Does the multimedia content (ex. video clipart, etc.) included in the tool's distibution packages include pre-written Priority 3 EAs stored in their text tracks or as separate descriptive files? (3.3)

Does the tool include the ability to search and reuse or otherwise manage the EAs stored in separate descriptive files or text track? (3.5)

If the tool supports multimedia content formats with text tracks, does the tool check for and notify the author when Priority 3 EAs are absent from this track? (4.1)

Does the tool check for and notify the author when separate descriptive files storing the Priority 3 EAs for multimedia content are absent? (4.1)

If the tool supports multimedia content formats with text tracks, does the tool assist the author in adding Priority 3 EAs when they are found to be absent? (4.2)

Does the tool assist the author in adding Priority 3 EAs to separate descriptive files when they are found to be absent? (4.2)

Appendices:

Appendix A: Techniques for User Prompting

Instances of the term "prompting"

The term "prompting" appears in the following locations in the authoring tool guidelines.

Unfotuantely, a potential ambiguity in the meaning of the term has been identified. This section will attempt to clarify the issue. Also, remember that although the following guidelines and checkpoints make explicit use of the term, other guidelines may be best implemented using some form of prompting as well.

What does "prompting" mean?

The term "prompting" is used in the document to denote all user interface methods by which the author is given an opportunity to add accessible content. Developers are often concerned that prompting requires them change their products in ways that their users will not accept. To address these concerns the following statements should make clear, what prompting is not:

Prompting on a user configurable schedule

Authoring tool support for the creation of accessible Web content should account for different authoring styles. When authors are able to configure the tool's accessibility features to support their regular work patterns, they will be more likely to accept accessible authoring practices (ATAG Checkpoint 5.1). 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 is analogous to programming environments that allow users to decide whether to check for correct code during editing or at compilation.

A user configurable schedule allows individual authors to determine how and when they will be prompted about accessibility issues. For example, authors should have control over the stringency of the checks (i.e. WCAG conformance level) and the scheduling of prompting (i.e. as problems occur, following saves, or prior to Web publishing). Of course, the extent of this configurability should be appropriate to each tool, as determined by the developer. Some tool developers may decide to restrict authors to several global settings, while others might allow authors to make fine grained distinctions, such as different scheduling for different types of problems. For example, in Microsoft Word 2000, spelling errors can be flagged and corrected in several ways depending on the preferences that the author has set on the "Spelling & Grammar" property card (Figure A-1).

Types of Prompting

All authoring tools will have ways of conveying information to users and collecting information in return. These methods vary according to the design of the tool and the user interface conventions for the platform upon which it is implemented. For the sake of this document we have attempted to divide the methods roughly between prompts and alerts. The following is relatively generic overview of how these methods can be used for accessibility prompting. Keep in mind that these categories may overlap. For example, an intrusive alert may contain a prompt edit field.

Prompts:

Prompts are interface mechanisms that request information from the user, or at least provide an opportunity for user to provide information if they wish. On most GUI platforms, prompts commonly take the form of dialog box controls. The author answers the requests by modifying the states of the controls (i.e. typing text in a textbox or selecting a checkbox).

A prompt can be viewed as either intrusive or unintrusive depending on whether the user has requested that it be displayed or not. For example, when the author activates the "Save As..." menu item, an unintrusive dialog is typically displayed to prompt the user for a file name and location. On the other hand, if the user presses activates the "Save" command and the program detects a problem (ex. saving to a media that has been removed), an intrusive dialog is usually displayed prompting the user to replace the media or select a new saving location.

The main drawback of using unintrusive prompts for ensuring accessible authoring is that once the author has dismissed the prompt, its message is unavailable unless the user requests it again. This may be avoided by the use of intrusive prompts, however, displaying too many of these can quickly annoy the author and one of the goals of this document is to suggest techniques for implementing ATAG that preserve author cooperation.

Therefore, when implementing the ATAG, unintrusive prompts are recommended to encourage authors to provide information required for accessibility when the user inserts or inspects an element. For example, in the case of HTML, a prominently displayed alt-text entry field in an image insertion dialog, would constitute a prompt (Figure A-3).

Priority of Prompt Fields:

In ATAG, the interface priority of controls related to accessibility is governed by ATAG checkpoint 5.2 (Ensure that accessible authoring practices supporting Web Content Accessibility Guidelines 1.0 [WCAG10] Priority 1 checkpoints are among the most obvious and easily initiated by the author. [Priority 2]). This checkpoint does not require that accessibility concerns obscure the other editing tasks. The checkpoint merely emphasizes that these controls should be allotted screen presence that is appropriate for their importance. For example, in Macromedia's Dreamweaver 2 HTML authoring tool, a property toolbar is displayed with fields that are appropriate to the currently selected element. In some cases, including the image element, the author can toggle the toolbar between a limited and extended set of properties. Due to the importance of the alt attribute, it is recommended that the edit field for this property be available in the limited set. In the case of Dreamweaver, this is precisely what has been done (Figure A-2).

Prompt Highlighting:

Conformance with checkpoint 5.2 may be reinforced by visually highlighting accessibility features with colour, icons, underlining, etc. For example, in Allaire's HomeSite authoring tool, attention is drawn more explicitly to accessibility-related prompt fields. In this case, the HomeSite tag editor dialog contains symbols, colour changes and explanatory text that highlight the alt-text field and remind the author that it is required for HTML 4.0 and necessary for accessibility.

Grouping Related Prompts:

Sometimes several editing tasks are required to make a single element accessible. Instead of dispersing these prompts over multiple dialog boxes, it may be more effective to draw them together into one group of controls. In the following example from Allaire HomeSite, the prompt fields pertaining to multiple accessibility requirements of the HTML input form control (i.e. Access Key, Tab Index, Title and Label Text) are organized into the same dialog box.

Sequential Prompts:

In cases where there are many pieces of information required, authors may benefit from a sequential presentation of prompts. This technique usually takes the form of a wizard or a checker. In the case of a wizard, complex interactions are broken down into a series of simple steps. The later steps can then be updated on the fly to take into account information provided by the user in earlier steps. A checker is a special case of a wizard in which the number of detected errors determines the number of steps. For example, Microsoft Word 2000 has a checker that displays all the spelling and grammar problems one at a time (Figure A-5). Notice how all the problems are displayed in a standard way: type of problem (i.e. "not in dictionary"), the problem instance (i.e. "There are a few spellling mistakes") and suggested fixes (i.e. a list of suggested correct words). The user also has several correcting options, some of which can store responses to affect how the same situation is handled later.

In an accessibility checker, the same is true, however the dialog template has to be somewhat more flexible since the problems can range from a missing text string for a multimedia object to missing structural information for a table to improper use of colour. In the following example, from A-Prompt, the author is prompted to add alternate text for an image as part of a correction run. Notice that, like the spell checker, the prompt includes a statement of the problem (i.e. "missing alternate text for an image"), the problem instance (i.e. earthrise.gif), and suggested fixes (i.e. a suggestion from the alt-text registry, "An earth-rise as seen from the surface of the moon"). In addition, the dialog also has some instructive text to aid the author in writing text if necessary.

Alerts:

Alerts warn the author that there are problems that need to be addressed. Since addressing these problems usually requires adding information, it may be argued that the distinction between an alert (warning) and a prompt (information request) is confusing. For the purpose of this document, an alert is essentially a warning without an immediate means (i.e. a text box) for adding the missing information (although a well-designed warning should link intuitively to a prompt wherever possible), whereas a prompt is an opportunity to add missing information that may or may not include a warning. Still confused? Fortunately, in general, it doesn't really matter as long as the tool succeeds in convincing authors to add the required information at some point before Web publishing occurs.

Note: The method by which a tool attracts the author's attention is a tricky issue because it can influence the author's view of the tool and even their opinion of accessible authoring as a whole. That's why the ATAG includes checkpoint 5.1 (Integrate accessibility solutions into the overall "look and feel" [Priority 2]).

Intrusive Alerts

Intrusive alerts are informative messages that interrupt the editing process for the author. For example, intrusive alerts are often presented when an author's action could cause a loss of data. Intrusive alerts allow problems to be brought to the author's attention immediately. However, authors may resent the constant delays and forced actions. Many people prefer to finish expressing an idea before returning to edit its format.

If the tool developer chooses to use intrusive alerts for some or all of the alerts, the simplest implementation might to present the author with a single option that channels them to a prompt where they may or may not be forced to enter the missing information. This is not a recommended strategy. Instead, the alert should include two or more options that linking to a prompt for correcting the problem, an option to return directly to editing and perhaps even a link to relevant help (Figure A-7). In addition, the author may be presented with an option to prevent similar intrusive warnings in the future.

Although intrusive alerts are the least user-friendly form of prompting, there are some situations in which they may become necessary. For example, when the editing process is complete and publishing to the Web appears imminent, unintrusive alerts are not an option since there is simply no editing process left. This may always be the case when a document composed in a proprietary (non-Web format) is being converted to a Web format for publishing. This does not mean that unintrusive alerts are not also possible in these situations. For example, an alert might be added directly to the "Save" dialog (Figure A-8).

Unintrusive Alerts

Unintrusive alerts are interface methods such as icons, underlines, and gentle sounds that can be presented to the author without requiring immediate action. For example, in some authoring tools misspelled text is highlighted within the document, identifying the location of problems without forcing the author to make corrections immediately. As an example, Microsoft Word 2000 includes the option to underline spelling errors (Figure A-9) in red and grammatical errors in green (for author accessibility the user must be able to change the default presentation - users who are red-green colorblind, for example, will not be able to perceive the information being conveyed by red and green underlines). When the user right-clicks on the highlighted text, they are presented with several correction options.

Another Microsoft product, FrontPage 2000, uses unintrusive alerts in its HTML editing environment to indicate syntax errors. As the author types, the syntax is automatically checked (Figure A-10). The system is unintrusive because the author is allowed to make as many syntax errors as they like, but the colour of the text signals that one or more errors have been made.

In the context of the Authoring Tool guidelines, these unintrusive alert techniques could be used to indicate which parts of a document or site contain accessibility problems. This will inform the author about the type and number of errors without interrupting their editing process. Of course, these are just two examples of the techniques that developers might choose. Other implementations might include in-line icons as the BOBBY evaluation tool does or even accessibility problem density displays for power users.

The downside of unintrusive alerts is that the author may choose to ignore the alerts completely. Therefore, the optimum strategy might be to emphasize unintrusive solutions until a critical point (i.e. publishing) at which time an effective intrusive alert, such as a problem summary, can be displayed.

Status of this document

Table of Contents

Proposed Authoring Tool Categories

2 Techniques by ATAG Guideline

Guideline 1. Support accessible authoring practices.

Reference:

Reference:

Reference:

Reference:

Sample(s):

Guideline 2. Generate standard markup.

Reference:

Reference:

Sample(s):

Guideline 3. Support the creation of accessible content.

Reference:

Reference:

Sample(s):

References:

Guideline 4. Provide ways of checking and correcting inaccessible content.

Checkpoints:

Reference:

Sample(s):

Sample(s):

Sample(s):

Samples:

Further techniques for this guideline are given in the appendix Techniques for User Prompting

Guideline 5. Integrate accessibility solutions into the overall "look and feel".

Sample(s):

Sample(s):

Guideline 6. Promote accessibility in help and documentation.

Checkpoints:

Guideline 7. Ensure that the authoring tool is accessible to authors with disabilities.

Checkpoints:

References:

Sample(s):

Sample(s):

Sample(s):

Sample(s):

Sample(s):

Evaluation Techniques for testing conformance

General requirements:

Documentation

Accessible Interface:

Markup Editor

PART 1: Images (including Image Maps)

IMPORTANT DEFINITION: Equivalent Alternatives (EA)

for Images:

for Image Maps:

for Objects displaying Images:

Inserting an Image:

Saving:

Re-saving and Reformatting:

Automatic Markup Generation:

Bundled Web Content:

Checking for Accessibility:

Documentation:

User Interface Presence:

Priority 3: Only required for level Triple-A conformance

Forms

Priority 1 tests

Priority 2 tests

Priority 3 test

Multimedia Tool

Note: Equivalent Alternatives (EA) for Image Editors

Priority 1: Required for all levels of conformance (i.e. A, Double-A, Triple-A)

Priority 2: Required for level Double-A and Triple-A conformance

Creating a New Image:

Saving:

Re-saving and Reformatting:

Bundled Web Content:

Checking for Accessibility:

User Interface Presence:

Accessible Interface:

Section C (Tool is an Multimedia Editor)

Priority 1: Required for all levels of conformance (i.e. A, Double-A, Triple-A)

Priority 2: Required for level Double-A and Triple-A conformance

Priority 3: Only required for level Triple-A conformance

Appendices:

Appendix A: Techniques for User Prompting