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


Implementation Techniques for
Authoring Tool Accessibility Guidelines 2.0:

Guideline 1: Make the tool itself accessible

Working Group Draft 25 June 2004

This version:
Latest version:
ATAG 1.0 Recommendation:
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 user 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 user 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:


ATAG Checkpoint 1.1: Ensure that the authoring interface follows applicable software accessibility guidelines. [ISO16071 Relative Priority]

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 interface* must conform to [*ISO16071*].


Technique 1.1.1: Follow the guidance provided by the ISO16071 standard to the desired level according to *ISO 16071 Relative Priority*. This requirements of this standard include, but are not limited to:

  • ensuring compatibility with assistive technology,
  • supporting keyboard input,
  • supporting software control of pointing devices,
  • properly displaying fonts,
  • ensuring customizable displays,
  • properly using colour,
  • supporting audio output,
  • proper handling of errors and user notification,
  • providing on-line documentation and help,
  • ensuring customization of user preferences,
  • ensuring proper window appearance and behaviour,
  • proper handling of keyboard input focus.

Technique 1.1.2: For Web-based applications, conformance of the user interface to the requirements of WCAG can be a reliable indicator of its accessibility.


Technique 1.1.3: A variety of other guidelines and standards exist for various formats. It is beneficial to consult these sources in addition to the ISO16071 standard:

  • Guidelines for specific platforms include:
    • Java: "IBM Guidelines for Writing Accessible Applications Using 100% Pure Java" [JAVA-ACCESS] R. Schwerdtfeger, IBM Special Needs Systems.
    • X Windows: "An ICE Rendezvous Mechanism for X Window System Clients" [ICE-RAP], W. Walker. A description of how to use the ICE and RAP protocols for X Window clients.
    • MS Active Accessibility: "Information for Developers About Microsoft Active Accessibility" [MSAA] Microsoft Corporation.
    • X Windows: "The Inter-Client communication conventions manual" [ICCCM]. A protocol for communication between clients in the X Window system.
    • Lotus Notes: "Lotus Notes accessibility guidelines" [NOTES-ACCESS] IBM Special Needs Systems.
    • Java: "Java accessibility guidelines and checklist" [JAVA-CHECKLIST] IBM Special Needs Systems.
    • Java Swing: "The Java Tutorial. Trail: Creating a GUI with JFC/Swing" [JAVA-TUT]. An online tutorial that describes how to use the Swing Java Foundation Class to build an accessible User Interface.
    • Macintosh: "Macintosh Human Interface Guidelines" [APPLE-HI] Apple Computer Inc.
    • MS Windows: "The Microsoft Windows Guidelines for Accessible Software Design" [MS-SOFTWARE].
  • Guidelines for specific software types include:
    • Authoring Tools: "Authoring Tool Support: The Best Place to Improve the Web". L. Harrison, J. Richards and J. Treviranus [ACCESS-AWARE].
    • User Agents: "User Agent Accessibility Guidelines (Working Draft)" J. Gunderson, I. Jacobs eds. (This is a work in progress) [UAAG10]
  • General guidelines for producing accessible software include:
    • Microsoft: "Accessibility for applications designers" [MS-ENABLE] Microsoft Corporation.
    • Trace: "Application Software Design Guidelines" [TRACE-REF] compiled by G. Vanderheiden. A thorough reference work.
    • Sun: "Designing for Accessibility" [SUN-DESIGN] Eric Bergman and Earl Johnson. This paper discusses specific disabilities including those related to hearing, vision, and cognitive function.
    • EITAAG: "EITAAC Desktop Software standards" [EITAAC] Electronic Information Technology Access Advisory (EITACC) Committee.
    • US Sept. of Education: "Requirements for Accessible Software Design" [ED-DEPT] US Department of Education, version 1.1 March 6, 1997.
    • IBM: "Software Accessibility" [IBM-ACCESS] IBM Special Needs Systems
    • "Towards Accessible Human-Computer Interaction" [SUN-HCI] Eric Bergman, Earl Johnson, Sun Microsystems 1995. A substantial paper, with a valuable print bibliography.
    • "What is Accessible Software" [WHAT-IS] James W. Thatcher, Ph.D., IBM, 1997. This paper gives a short example-based introduction to the difference between software that is accessible, and software that can be used by some assistive technologies.

@@this text could be useful:

[ISO16071] 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.).@@

ATAG Checkpoint 1.2 : Ensure that the authoring interface enables accessible editing of element and object properties. [ISO16071 Relative Priority]

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 which read text and support authors editing text.

Techniques for
Success Criteria 1: At least one editing method must conform to [ISO16071] for each element and object property that is editable by the tool.

  Allow the author to individually edit each attribute of the elements in an HTML or XML document, for example, through a menu. This must include the ability to add and edit later, values for all valid attributes. [T0287]
  For tools that graphically represented element start and end tags, text equivalent must be provided in order to be accessible to assistive technologies that render text as Braille, speech, or large print.[T0288]
  An authoring tool may offer several editing views of the same document, such as a source mode that allows direct editing of all properties. [T0289]
  For a site management tool, allow the author to render a site map in text form (i.e., as a structured tree file). [T0290 ]
  Allow the author to specify that alternative information (or identifiers such as a URI or filename) are rendered in place of images or other multimedia content while editing. [T0291]
  Include attributes / properties of elements in a view of the structure. [T0292]
  Provide access to a list of properties via a "context menu" for each element. [T0293]


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

This allows the author to edit the document according to personal requirements, without changing the way the document is rendered when published.

Techniques for
Success Criteria 1: All editing views must display text equivalents for any non-text content

Techniques for
Success Criteria 2: All editing views must either respect operating system display settings (for color, contrast, size, and font) or, from within the tool, provide a means of changing color, contrast, size and font, without affecting the content markup.

  Respect system settings (see Techniques for ATAG checkpoint 1.1). [T0438]@@new category and T####@@
  For tools with editing views, the author must have 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. [T0282]
  For tools that display the source structure of a document using graphic representations of tags, provide the author with the option of displaying the text of the elements, instead (i.e., <html> rather than a generic marker image). [T0283]
  An authoring tool that offers a "rendered view" of a document, such as a browser preview mode, may provide an editing view whose presentation can be controlled independently of the rendered view. [T0284]
  A WYSIWYG editor may allow an author to specify a local style sheet, that will override the "published" style of the document in the editing view. [T0285]
  Allow the author to create audio style sheets using a graphical representation rather than an audio one (with accessible representation, of course). [T0286]
Techniques: [@@from old 1.5@@]
  To minimally satisfy this checkpoint, allow navigation from element to element. [T0295]
  Allow the author to navigate via an "outline" or "structure" of the document being edited. This is particularly important for people who are using a slow interface such as a small Braille device, or 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. [T0296]
  In a hypertext document, allow the author to navigate among links and active elements of a document. [T0297]
  For time-based presentations (i.e., SMIL), allow the author to navigate temporally through the presentation. [T0298]
  For an image expressed in a structured language (i.e., SVG), allow the author to navigate regions of the image, or the document tree. [T0299]
  Implement the HTML "accesskey" attribute, and activate it in editing views. [T0294]

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 be able, with a device independent action, to move editing focus from any structural element to any element immediately above, immediately below or in the same level in the hierarchy.

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

  An authoring tool may offer a structured tree view of the document that allows the author to move among, select and cut, copy or paste elements of the document. [T0300]
  A WYSIWYG tool may allow elements to be selected, and copied or moved while retaining their structure. [T0301]
  A tool may allow transformation from one element type to another, such as: @@is this appropriate here? - CP is about accessibility of structure editing - tech is about transformation@@
  • HTML: Paragraphs to lists and back [T0302]
  • HTML: BR to P [T0303]
  • SMIL: Transformations between switch, excl, and par [T0304]
  • HTML: FONT (deprecated) into heuristically determined structure [T0305]
  • MathML: Transformations between semantic and presentation markup [T0306]
  • SVG: g to symbol [T0307]
  • Lists of lists to tables and back [T0308]
  • Giving a structural role to a part of an element, such as an SVG g or an HTML p element [T0309]


ATAG Checkpoint 1.5: Ensure the authoring interface allows the author to search within the editing views. [Priority 2]

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: The authoring tool must have a search function for all editing views.

  Technique 1.5.1: Allow the user to search for a sequence of characters as a minimal measure for meeting this checkpoint. [T0310]
  Technique 1.5.2: More powerful searches can include the ability to perform searches that are case sensitive or case-insensitive, the ability to replace a search string, the ability to repeat a previous search to find the next or previous occurrence, or to select multiple occurrences with a single search. [T0311]
  Technique 1.5.3: The ability to search for a particular type of structure is useful in a structured document, structured image such as a complex SVG image, etc. [T0312]
  Technique 1.5.4: In an image editor, the ability to select an area by properties (such as color, or closeness of color) is useful and common in middle range and high end image processing software. [T0313]
  Technique 1.5.5: The ability to search a database for particular content, or to search a collection of files at once (a simple implementation of the latter is the Unix function "grep") is an important tool in managing large collections, especially those that are dynamically converted into Web content. [T0314]
  Technique 1.5.6: The use of metadata (per WCAG 2.0 [WCAG20]) can allow for very complex 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. [T0315]

Techniques for:
Success Criteria 2: The author must be able to search for text within all text equivalents of any rendered non-text content.


Techniques for:
Success Criteria 3: The author must be able to specify whether to search content, markup, or both.


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