Contents | Guideline 1 | Guideline 2 | Guideline 3 | Guideline 4 | References
Copyright © 1994-2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.
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).
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.
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] @@rewording@@
Technique 1.1.2: Test the authoring interface against WCAG using automated evaluation and repair tools for the format in which the authoring interface is constructed.@@NEW@@
Technique 1.1.3: Follow the guidance provided by the ISO TS 16071:2003 standard [ISO16071] to the desired level according to ISO16071 Relative Priority (Authoring Interface). 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]
- ensuring compatibility with assistive technology,
- supporting keyboard input,
- supporting software control of pointing devices,
- properly displaying fonts,
- ensuring customizable displays,
- properly using color,
- 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 behavior,
- proper handling of keyboard input focus.
Technique 1.1.4: A variety of other guidelines and best practice documents exist for specific technologies. Developers may find these sources informative:
- 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.@@KM this link goes to REFS, which just leads to http://www-306.ibm.com/able/index.html. Since we are so specific, I think it should go to http://www-306.ibm.com/able/guidelines/java/accessjava.html. This is a REFS change - just mentioning it here.@@
- 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.
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.
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.
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]
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]
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)
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.@@reworded@@
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). @@reworded@@
Technique 1.2.5: Provide a method of transition between content structure navigation and element and object property editing.@@reworded+KM change@@
Technique 1.2.6: Provide access to a list of properties via a "context menu" for each element.
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.
Technique 1.3.1: Provide an option to toggle between rendered non-text content and text equivalents.
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)
Technique 1.3.2: Respect system display settings. @@reworded@@
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.@@rewording+KM@@
Technique 1.3.5:
A WYSIWYG editor mayAllow 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
(with accessible representation, of course).
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.
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. @@reworded@@
Technique 1.4.2: Allow the author to navigate via an "outline" or "structure" of the document being edited.@@reworded@@
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.
Technique 1.4.5: Allows the author to move among, select, copy, cut, or paste elements of the document. @@reworded+KM@@
Technique 1.4.6: Provide the option of retaining the original internal structure of content that is pasted after being cut or copied.@@reworded@@
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. @@reworded@@
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.
Technique 1.5.1: Allow the user to search for a sequence of characters @@new@@ 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.
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,
structured imagesuch 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.)
is useful and common in middle range and high end image processing software.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.
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.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. @@rewording@@
Technique 1.5.7: Provide the author with an option to search text equivalents.
Technique 1.5.8: Provide the author with an option to search the content only, the markup only, or both.
Contents | Guideline 1 | Guideline 2 | Guideline 3 | Guideline 4 | References