• Guideline A.1 Authoring Interface must be Perceivable
• Guideline A.2: Authoring Interface must be Operable
• Guideline A.3 : Authoring Interface must be Understandable
• Guideline A.4: Authoring Interface must be Access System Friendly

Notes:

• These techniques are informative (non-normative). There are no claims made, implicit or explicit, that by following any of the techniques in this document any conformance requirements of the ATAG2.0 WD will be satisfied. Rather, these techniques represent an illustrative sampling of approaches that might be useful in considering the subject of authoring tool accessibility. There may be many other ways a tool might be designed and still meet the normative criteria contained in the success criteria. It should be noted that some techniques are so important to meeting their respective success criteria, that for all practical purposes, the techniques are required. These techniques have been marked with the term "STRONGLY SUGGESTED".
• For purposes of clarity, the techniques are phrased using an imperative voice. Nevertheless, the techniques remain informative (non-normative)

• A.0.1 Ensure that browser-accessed functionality conforms to WCAG. [Priority RP]

ATAG Checkpoint A.0.1 Ensure that browser-accessed functionality conforms to WCAG. [Priority RP]

Rationale:Authors must be able to have access to authoring tool functionality that is implemented as Web content.

Note: For non-Web-based authoring tools, this is a relatively straightforward requirement, likely covering only a few areas of the interface (i.e. Web-based help features, etc.). However, for most Web-based authoring tools the requirement will cover the majority of functionality in the tool and overlap most of the other requirements in Part A of the guidelines.

Techniques for Success Criteria 1: Any component of an authoring tool that is accessed by the author within a Web browser must conform to WCAG

Technique 1.1.1: For Web-based applications, follow 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

Guideline A.1 Authoring Interface must be Perceivable:

This guideline requires that the user interface of the authoring tool be accesible by a variety of video, audio or tactile display devices that the author may choose. This entails: providing text alternatives to non-text content such as images or sounds (Checkpoint A.1.1); providing synchronized alternatives such as captions and described video for multimedia (Checkpoint A.1.2); ensuring that displays are configurable (e.g. colour and size of visual diplay, volume of audio displays) (checkpoint A.1.3); allowing the author to work with display preferences without affecting the display characteristics of the content that they are authoring (Checkpoint A.1.6); and ensuring that all user interface labels are clearly associated with the controls that they are intended to label (Checkpoint A.1.7).

• A.1.1 Provide text alternatives for all non-text content in the user interface. [Priority 1]
• A.1.2 Provide synchronized alternatives for multimedia. [Priority 1]
• A.1.3 Ensure that all displays are configurable. [Priority 1]
• A.1.4 Allow the display preferences for the editing view to be changed without affecting the document markup. [Priority 1]

ATAG Checkpoint A.1.1 Provide text alternatives for all non-text content in the user interface. [Priority 1]

Rationale: People who have difficulty perceiving non-text content in the authoring interface can have text in text alternatives for such non-text content made available to them (by assistive technology or braille, for example).

Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Techniques for Success Criteria 1: All non-text objects in the authoring tool user interface that have information value (e.g., toolbar icon, placeholder image, sound effect, etc.) must have a text alternative.

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

Techniques for Success Criteria 2: All editing views must always include an option to display any available text alternatives for non-text objects in the content.

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.

General Techniques for Checkpoint A.1.1 (Note: also applicable to most of the checkpoints in Part A)

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.

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

ATAG Checkpoint A.1.2 Provide synchronized alternatives for multimedia. [Priority 1]

Rationale: People who have difficulty accessing or interpreting multimedia- supported information in the authoring interface can have the information made available to them by other means. For example, people who are deaf or have a hearing loss can access auditory information through captions, and people who are blind or have low vision, as well as those with cognitive disabilities, who have difficulty interpreting visually what is happening, can receive audio descriptions of visual information.

Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Techniques for Success Criteria 1: All multimedia in the authoring tool user interface that has information value (e.g., progress indicators, etc.) must have synchronized alternatives.

???

Techniques for Success Criteria 2: All editing views must always include an option to display any available synchronized alternatives for multimedia in the content.

???

ATAG Checkpoint A.1.3 Ensure that all displays are configurable. [Priority 1]

@@put saving personlized configurations as a technique AND under operability@@

Rationale: Some authors require alternative display configurations to use the authoring interface.

Note 1: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Note 2: The success criteria for this checkpoint are based on the capabilities of platforms (e.g. operating systems, browsers, GUI toolkits, etc.), however developers are free to provide additional configuration.

Techniques for Success Criteria 1: If the visual display (fonts, sizes, colors, spacing, positioning, etc.) is controlled by the authoring tool rather than by the platform, then the authoring tool must provide at least the same configurable properties with at least the same configuration ranges as the platform.

???

Techniques for Success Criteria 2: If the audio display (volume, speech voices, etc.) is controlled by the authoring tool rather than by the platform, then the authoring tool must provide at least the same configurable properties with at least the same configuration ranges as the platform.

???

ATAG Checkpoint A.1.4 Allow the display preferences for the editing view 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: The author must be able to configure the presentation settings of editing views without affecting the Web content being edited.

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 may 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 (with accessible representation, of course).

Guideline A.2: Authoring Interface must be Operable

This guideline requires that the user interface of the authoring tool be operable by the various input devices (mouse, keyboard, etc.) that the author may choose. This entails:

• A.2.1 Ensure that all functionality is operable via a keyboard or a keyboard interface. [Priority 1]
• A.2.2 Ensure user configurable access to selectable actions. [Priority 3]
• A.2.3 Allow authors to control time limits. [Priority 1]
• A.2.4 Allow users to avoid content that could cause seizures due to photosensitivity. [Priority 1]
• A.2.5 Ensure that editing views enable the author to navigate the structure and perform structure-based edits. [Priority 2]
• A.2.6 Allow the author to search content and markup within the editing views. [Priority 2]
• A.2.7 Provide an undo function. [Priority 2]
• A.2.8 Provide personalized configuration. [Priority 2]
• A.2.9 Ensure previews emulate accessible rendering features of target browsers [Priority 2]

ATAG Checkpoint A.2.1 Ensure that all functionality is operable via a keyboard or a keyboard interface. [Priority 1]

Rationale: Some individuals have difficulty manipulating graphical input devices such as a mouse or trackball. Providing alternate means of navigating the user interface that does not rely on such devices provides an accomodation for individuals with limited mobility or those with visual disabilities who cannot rely on hand eye coordination for navigating the user interface.

Note 1: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Techniques for Success Criteria 1: The author must be able, through keyboard input alone, to perform any authoring task (e.g. navigating, selecting, and editing content within editing views, operating the authoring tool user interface, installing and configuring the authoring tool, and accessing documentation) that is available through the user interface. (Note: an authoring task may have multiple user mechanisms, e.g. a menu item and a button bar item, at least one of which must satisfy this success criteria)

Technique 1.2.1(a): Allow the author to individually add and edit each and every valid property or attribute. [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)

Techniques for Success Criteria 2: There must be an option that ensures that selection is separate from activation (e.g. navigating through the items in a dropdown menu without activating any of the items).

???

Techniques for Success Criteria 3: Follow @@operating environment conventions for keyboard control.

???

Techniques for Success Criteria 4: Single-key access must be provided to the following functionalities: move @@content focus to the next enabled control in authoring tool user interface; navigate forward and backward through editing views.

???

Techniques for Success Criteria 5: Key-plus-modifier-key (or single-key) access must be provided to the following functionalities in the user interface (if present): move content focus to the previous enabled control; navigate between panels or windows; open help system; open new content; open existing content; save content; close content; cut/copy/paste; undo/redo; open find/replace function; and navigate to the start and end.

???

ATAG Checkpoint A.2.2 Ensure user configurable access to selectable actions. [Priority 3]

Rationale: Authors who have limited mobility require quick access to the actions that they use frequently.

Techniques for Success Criteria 1: There must be an option to add and modify key-plus-modifier-key (or single-key) access to all selectable actions (@@Def'n: Any items that are designed to be activated from within a menu, toolbar, pallette, etc.@@).

???

Techniques for Success Criteria 2: There must be an option to customize the items (from the set of all selectable actions) and their order within at least one area of the user interface that is controllable by a single selection (e.g. button bar, pallette, panel, etc).

???

ATAG Checkpoint A.2.3 Allow authors to control time limits. [Priority 1]

Rationale: Authors who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits.

Note 1: Some time limits may be imposed by external systems. This checkpoint only applies to time limits within the control of the authoring tool.

Note 2: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Techniques for Success Criteria 1: All user interface time limits must be configurable unless they are controlled by time-sensitive external processes (e.g. time-outs of systems outside of the authoring tool).

???

Techniques for Success Criteria 2: If a time limit is under the control of the authoring tool, it must not be less than 20 seconds and must be extendible with a single input action.

???

ATAG Checkpoint A.2.4 Allow users to avoid content that could cause seizures due to photosensitivity. [Priority 1]

Rationale: Flashing can cause seizures in people with photosensitive epilepsy.

Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Techniques for Success Criteria 1: Authors must be able to turn off flashing in the user interface that violates international health and safety standards for general flash or red flash.

ATAG Checkpoint A.2.5: Ensure that editing views enable the author to navigate the structure and perform structure-based edits. [Priority 2]

@@add technique on indicating to user that they are in loop@@

Rationale: It is often more efficient to navigate and edit via the structure in Web content.

Techniques for Success Criteria 1: In any structured element set, the author must always be able to move the editing focus from any element to any other element with the following relationship (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 A.2.5.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 A.2.5.2: Allow the author to navigate via an "outline" or "structure" of the document being edited.@@reworded@@

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

Technique A.2.5.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 structured element set, the author must always be able to select content and perform editing functions on any element along with any content, including sub-elements.

Technique A.2.5.5: Allows the author to move among, select, copy, cut, or paste elements of the document. @@reworded+KM@@

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

Technique 1.2.5: Provide a method of transition between content structure navigation and element and object property editing.@@reworded+KM change@@

General Techniques for Checkpoint A.2.5:

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

Technique A.2.5.8: Allow editing view navigation of content by any accesskeys defined in that content. @@reworded@@

ATAG Checkpoint A.2.6: Allow the author to search content and markup within the editing views. [Priority 2]

Rationale: Search functions within the editing views 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 efficiency of the search function.

Techniques for Success Criteria 1: The author must be able to perform text searches of all content that is editable by the author.

Techniques for Success Criteria 2: The author must be able to perform text searches of all markup that is editable by the author.

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

Technique A.2.6.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 A.2.6.1: 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 A.2.6.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.

Technique A.2.6.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 A.2.6.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 A.2.6.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 A.2.6.8: Provide the author with an option to search the content only, the markup only, or both.

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

ATAG Checkpoint A.2.7 Provide an undo function. [Priority 2]

Rationale: Authors who have difficulty making fine movements may be prone to making unintended actions. All authors benefit from the ability to easily recover from mistakes.

Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Techniques for Success Criteria 1: Actions that modify content must be either reversible with an undo function or include a warning to the author that the action is irreversible.

???

Techniques for Success Criteria 2: The author must be able to perform multiple undos.

???

Techniques for Success Criteria 3: The author must be able to undo any series of undos

???

ATAG Checkpoint A.2.8 Provide personalized configuration. [Priority 2]

Rationale: When a large number of configuration settings are available, authors working on shared systems benefit from the ability to save and later reload a personal settings file.

Techniques for Success Criteria 2: The authoring tool must provide the ability to save and reload all configuration settings related to visual or auditory output and keyboard operability.

???

Techniques for Success Criteria 2: The author must be able to select, within the application, from multiple configuration sets.

???

ATAG Checkpoint A.2.9 Ensure previews emulate accessible rendering features of browsers [Priority 2]

Rationale: The workflow of many authoring tools includes periodically checking a preview of how content will appear to end users in a browser. Authors with disabilities need to have access to a preview so that they can check all aspects of their work (i.e. not just the accessibility of that work). For this reason the preview needs to be as, but not more, accessible than the target browser(s).

Note 1: This requirement serves, for the preview features only, in lieu of the other user interface accessibility requirements in Part A.

Note 2: In addition, it is expected that the operation of the preview accessibility features will be constrained by the accessibility and/or completeness of the content.

Techniques for Success Criteria 1: If a preview is provided, then: (a) The author must be able to choose an external browser to perform the preview; (b) or, the preview must provide the same accessibility features as a target browser (which must be identified in the conformance profile) that is being emulated and the following must be true: (i) Any authoring tool user interface other than the content being previewed must meet the other requirements of Part A of ATAG 2.0, (ii) A means of exiting the preview must be provided that meet the other requirements of Part A of ATAG 2.0; (c) or, the preview does not claim to emulate a specific browser, in which case it must meet the other Part A requirements of ATAG 2.0 (i.e. Note 1 does not apply).

???

Guideline A.3 : Authoring Interface must be Understandable

This guideline requires that the user interface of the authoring tool be understandable.... This entails:

• A.3.1 Observe the accessibility conventions of the platformn. [Priority 2]
• A.3.2 Maintain consistency within the authoring tool user interface. [Priority 2]
• A.3.3 Document the authoring interface including all interface accessibility features. [Priority 1]

ATAG Checkpoint A.3.1 Observe the accessibility conventions of the platformn. [Priority 2]

Rationale: Authors are often familiar with accessibility conventions employed by the other applications built on a platform. Departures from those conventions have the tendency to disorient authors by creating an unfamiliar environment.

Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Techniques for Success Criteria 1: Focus and selection conventions for the current platform (specified in the conformance profile) must be followed.

???

Techniques for Success Criteria 2: Keyboard accessibility configuration conventions (e.g. default accelerator key bindings) for the current platform (specified in the conformance profile) must be followed.

???

ATAG Checkpoint A.3.2 Maintain consistency within the authoring tool user interface. [Priority 2]

Rationale: Authors who may become disoriented easily will have less difficulty when consistent and predictable responses to author actions are provided. In general, consistent interfaces will benefit all authors to some degree.

Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Techniques for Success Criteria 1: User interface controls with the same text label or icon must perform the same function.

???

Techniques for Success Criteria 2: Any text label or icon must not have more than one function.

???

Techniques for Success Criteria 3: When the same function (e.g. saving, running a checker or canceling an action) is available in multiple areas of an authoring tool user interface, at least one method of controlling the function must be implemented for each area using identical user interface elements.

???

ATAG Checkpoint A.3.3 Document the authoring interface including all interface accessibility features. [Priority 1]

Rationale: While intuitive authoring interface design is valuable to many users, some users may still not be able to understand or be able to operate the authoring interface without thorough documentation. For instance, a user with blindness may not find a graphical authoring interface intuitive without supporting documentation.

Techniques for Success Criteria 1: At least one version of the documentation must conform to WCAG (whether delivered on the Web, CD-ROM, etc.).

???

Techniques for Success Criteria 2: All features that benefit the accessibility of the authoring interface must be documented in the help system (e.g., keyboard shortcuts).

???

Techniques for Success Criteria 3: The current configuration of selectable actions must be displayed in either a centralized fashion (e.g., a list of keyboard shortcuts) or a distributed fashion (e.g., by listing keyboard shortcuts in the user interface menus).

???

Guideline A.4: Authoring Interface must be Access System Friendly

This guideline requires that the user interface of the authoring tool be compatible with a variety of access systems that the author may choose. This entails:

• A.4.1 Support interoperability with assistive technologies. [Priority 1]

ATAG Checkpoint A.4.1 Support interoperability with assistive technologies. [Priority 1]

Rationale: Assistive technologies (e.g. screen readers, screen magnifiers, etc.) used by many authors with disabilities rely on software applications to provide data and control via prescribed communication protocols.

Note: For all Web-based interface components, meeting checkpoint A.0.1 will serve to meet this checkpoint.

Techniques for Success Criteria 1: The authoring tool must conform to accessibility platform architectures (e.g. MSAA, Java Access, etc.).

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]

Techniques for Success Criteria 2: If there is any authoring tool functionality or information that is not addressed by available accessibility platform architectures, an interoperability mechanism must be provided (and published) so that all authoring tasks can be accomplished in at least one way by an assistive technology implementing the mechanism.

???

Contents | Part A | Part B | References