Contents | Guideline 1 | Guideline 2 | Guideline 3 | Guideline 4 | References

W3C

Implementation Techniques for
Authoring Tool Accessibility Guidelines 2.0:

Guideline 1: Make the tool itself accessible

W3C Working Draft 22 November 2004

This version:
http://www.w3.org/TR/2004/WD-ATAG20-TECHS-20041122/tech1
Latest version:
http://www.w3.org/TR/ATAG20-TECHS/tech1
Previous version:
http://www.w3.org/TR/2003/WD-ATAG20-TECHS-20030314/tier1
Editors of this chapter:
Jutta Treviranus - ATRC, University of Toronto
Jan Richards - ATRC, University of Toronto
Matt May - W3C

Introduction to Guideline 1:

This guideline requires that the design of all aspects of the authoring tool, including the authoring interface, installation procedure, documentation, and help files, must be accessible. This entails following the all applicable accessibility guidelines (Checkpoint 1.1) as well as other considerations specific to authoring interfaces.

The special nature of authoring interfaces dictates that special consideration be paid to several specific functions of the authoring interface design. These include ensuring accessible editing of all properties (Checkpoint 1.2), allowing the editor display preferences to be changed independently of the markup (Checkpoint 1.3), making use of document structure for navigation and editing (Checkpoint 1.4), and providing an effective searching mechanism (Checkpoint 1.5).


Checkpoints in Guideline 1:


Notes:


ATAG Checkpoint 1.1: Ensure that the authoring interface follows applicable software accessibility guidelines. [Authoring Interface Checkpoints Relative to WCAG or Authoring Interface Checkpoints Relative to ISO-TS-16071]

Rationale: If the authoring tool interface does not follow these conventions, the author who depends upon the techniques associated with the conventions is not likely to be able to use the tool.

Techniques for Success Criteria 1: The authoring tool must satisfy at least one of the following conditions:

(a) At least one full-featured Web-based authoring interface must always conform to WCAG.

Technique 1.1.1: For Web-based applications, the authoring interface must conform to the requirements of WCAG. This means implementing the WCAG techniques for the format in which the authoring interface is constructed.[STRONGLY SUGGESTED]

Technique 1.1.2: Test Web-based authoring interfaces against WCAG using automated evaluation and repair tools for the format in which the authoring interface is constructed.

(b)At least one full-featured non-Web-based authoring interface must always conform to ISO-TS-16071.

Technique 1.1.3: Follow the guidance provided by the ISO TS 16071:2003 standard [ISO-TS-16071] to the desired level according to Authoring Interface Checkpoints Relative to ISO-TS-16071. The standard has guidelines organized into three priority levels (accessibility impact): core, primary, and secondary; in addition, two kinds of implementation responsibility are defined: OS (operating system), and application (productivity applications, development tools, web browsers, etc.). The requirements of this standard include, but are not limited to the list below. [STRONGLY SUGGESTED]

General Techniques for Checkpoint 1.1

Technique 1.1.5:Include authors with disabilities and authors using assistive technologies in focus groups and user testing throughout the design and development of the authoring interface.

Technique 1.1.4: A variety of other guidelines and best practice documents exist for specific technologies. Developers may find these sources informative:

ATAG Checkpoint 1.2: Ensure that the authoring interface enables accessible editing of element and object properties. [Authoring Interface Checkpoints Relative to WCAG or Authoring Interface Checkpoints Relative to ISO-TS-16071]

Rationale: Element or object properties displayed and edited through graphic means are not accessible to authors using screen readers, Braille displays, or screen enhancers. The explicit property value should be accessible to those technologies that read text and support authors editing text.

Techniques for Success Criteria 1: The authoring tool must satisfy at least one of the following conditions:

(a) In Web-based authoring interfaces, at least one editing method for each editable property must always conform to WCAG.

Technique 1.2.1(a): Allow the author to individually add and edit each and every valid property or attribute through an authoring interface that conforms to WCAG. [STRONGLY SUGGESTED]

(b) In non-Web-based authoring interfaces, at least one editing method for each editable property must always conform to ISO-TS-16071.

Technique 1.2.1(b): Allow the author to individually add and edit each and every valid property or attribute via an authoring interface that conforms to ISO TS 16071:2003. [STRONGLY SUGGESTED]

Applicable to 'what you see is what you get' authoring functions Example 1.2.1(b): This illustration shows an authoring interface that has two equivalent mechanisms for editing the height and width properties of an image: the keyboard accessible fields in the image properties dialog box (left) and a mouse-driven mechanism that lets the author manipulate the image size directly. (Source: mockup by AUWG)

General Techniques for Checkpoint 1.2:

Technique 1.2.2: For tools that display the source structure of markup document using graphic representations of tags, provide the author with the option of displaying the tag information as text.

Technique 1.2.3: When appropriate for a format, provide a code-level editing view that, by its nature, allows direct editing of all properties.

Technique 1.2.4: For tools that display collections of content using graphic representations of the objects, links, etc., provide the author with the option of displaying the information as text. (i.e., as a structured tree file).

Technique 1.2.5: Provide a method of transition between content structure navigation and element and object property editing.

Technique 1.2.6: Provide access to a list of properties via a "context menu" for each element.

ATAG Checkpoint 1.3 Allow the display preferences of the authoring interface to be changed without affecting the document markup. [Priority 1]

Rationale: Authors may require a set of display preferences to view and control the document that is different from the desired default display style for the published document (e.g. a particular text-background combination that differs from the published version).

Techniques for Success Criteria 1: All editing views must always include an option to display any available equivalent alternatives.

Technique 1.3.1: Provide an option to toggle between rendered non-text content and text equivalents.

Applicable to 'what you see is what you get' authoring functions Example 1.3.1: This illustration shows an authoring interface that allows full rendered images to be toggled with the text equivalent of the content. A small preview rendering of the image is displayed in the text equivalents view for context. (Source: mockup by AUWG)

Techniques for Success Criteria 2: All editing views must always include an option to keep the display settings of the authoring interface from affecting the Web content being edited.

Technique 1.3.2: Respect system display settings.

Technique 1.3.3: For tools with editing views, provide the author with the ability to change the fonts, colors, sizing (zoom), etc. within the editing view, independently of the ability to control the markup that is actually produced. [STRONGLY SUGGESTED]

Technique 1.3.4: For authoring tools that offers a "rendered view" of a document, such as a browser preview mode, provide an editing view that has a presentation that can be controlled independently of the rendered view.

Technique 1.3.5: Allow the author to specify a local style sheet that will override the "published" style of the document in the editing view.

Technique 1.3.6: Allow the author to create audio style sheets using a graphical representation rather than an audio one.

ATAG Checkpoint 1.4: Ensure that the authoring interface enables the author to navigate the structure and perform structure-based edits. [Priority 2]

Rationale: Efficient authoring requires that the author be able to move quickly to arbitrary locations in the content and, once there, make modifications beyond character-by-character edits. This is usually best accomplished by making use of any explicit structure that may have been encoded with hierarchy-based markup. When explicit structure is unavailable, the implicit structure in the visual look and layout of content may sometimes be used.

Techniques for Success Criteria 1: In any element hierarchy, the author must always be able, with a device independent action, to move the editing focus from any element to any of the following elements, if they exist: the element immediately above (i.e. parent), the first element immediately below (i.e. child), the element immediately preceding at the same level (i.e. previous sibling), and the element immediately following at the same level (i.e. next sibling).

Technique 1.4.1: Provide keyboard shortcuts for moving focus up, down, and across hierarchical structured content. This is particularly important for people who are using a slow interface such as a small Braille device, speech output, or a single switch input device. It is equivalent to the ability provided by a mouse interface to move rapidly around the document.

Technique 1.4.2: Allow the author to navigate via an "outline" or "structure" of the document being edited.

Technique 1.4.3: For time-based presentations (i.e., SMIL), allow the author to navigate through the timeline of the presentation.

Technique 1.4.4: For an image expressed in a structured language (i.e., SVG), allow the author to navigate regions of the image or the document tree.

Techniques for Success Criteria 2: In any element hierarchy, the author must always be able, with a device independent action, to select, copy, cut and paste any element along with any content, including subelements.

Technique 1.4.5: Allows the author to move among, select, copy, cut, or paste elements of the document.

Technique 1.4.6: Provide the option of retaining the original internal structure of content that is pasted after being cut or copied.

General Techniques for Checkpoint 1.4:

Technique 1.4.7: In a hypertext document, allow the author to navigate among interactive elements of content (e.g. links, form elements).

Technique 1.4.8: Allow editing view navigation of content by any accesskeys defined in that content.

Rationale: Search functions facilitate author navigation of content as it is being authored by allowing the author to move focus quickly to arbitrary points in the content. Including the capability to search within text equivalents of rendered non-text content increases the accessibility of the search function.

Techniques for Success Criteria 1: All editing views must always include a search function that meets these conditions:

(a) provides search within any rendered Web content

Technique 1.5.1: Allow the user to search for a sequence of characters within any editing view. [STRONGLY SUGGESTED]

Technique 1.5.2: More powerful searches may include the ability to perform searches that are case sensitive or case-insensitive, to replace a search string, to repeat a previous search to find the next or previous occurrence, or to select multiple occurrences with a single search.

Applicable to Code-Level authoring functions Example 1.5.2: This illustration shows a search facility that makes effective use of structure. This eliminates the potential confusion of markup with content that is possible in basic text search (Source: mockup by AUWG)

Technique 1.5.3: The ability to search for a particular type of structure is useful in a structured document such as a complex SVG image, etc.

Technique 1.5.4: In an image editor, allow the author to select an area by properties (e.g. color, or closeness of color, etc.).

Technique 1.5.5: For tools that manage a database or multiple files, provide a search function that can search through the different pieces of content at once.

Technique 1.5.6: The use of metadata (per WCAG 2.0 [WCAG20]) may assist searching of large collections, or of timed presentations. Refer also to the paper "A Comparison of Schemas for Dublin Core-based Video Metadata Representation" [SEARCHABLE] for discussion specifically addressing timed multimedia presentations.

(b) provides the option to search markup when the tool allows direct editing of markup (e.g. when authored "by hand").

Technique 1.5.8: Provide the author with an option to search the content only, the markup only, or both.

(c) provides the option to search for text within all text equivalents of any non-text content.

Technique 1.5.7: Provide the author with an option to search text equivalents (e.g. short text labels, long text descriptions, etc.).


Contents | Guideline 1 | Guideline 2 | Guideline 3 | Guideline 4 | References