Contents | Part A | Part B | 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.
Technique A-1: Following the guidance provided by the "Ergonomics of human-system interaction -- Guidance on accessibility for human-computer interfaces" ISO standard [ISO-TS-16071]. The requirements in the standard are organized into three priority levels (accessibility impact): core, primary, and secondary. In addition, two kinds of implementation responsibilities 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 A-2: Following other guidelines and best practice documents for specific technologies where they are relevant. These include:
- Platform Specific:
- Eclipse: "Designing Accessible Plug-ins in Eclipse" [http://www.eclipse.org/articles/Article-Accessibility/accessibility.html] Tod Creasey, IBM OTI Labs.
- Gnome: "GNOME Accessibility for Developers" [http://developer.gnome.org/projects/gap/guide/gad/index.html] Calum Benson, Brian Cameron, Bill Haneman, Sharon Snider, Padraig O'Briain, The GNOME Accessibility Project.
- Java:
- "IBM Guidelines for Writing Accessible Applications Using 100% Pure Java" [JAVA-ACCESS] R. Schwerdtfeger, IBM Special Needs Systems.
- "Java accessibility guidelines and checklist" [JAVA-CHECKLIST] IBM.
- Lotus Notes: "Lotus Notes accessibility guidelines" [NOTES-ACCESS] IBM.
- MacOS: "Accessibility Documentation" [APPLE-ACCESS] Apple Computer Inc.
- Microsoft Windows:
- "Accessibility for applications designers" [MS-ENABLE] Microsoft Corporation.
- "The Microsoft Windows Guidelines for Accessible Software Design" [MS-SOFTWARE]
- General:
- "Application Software Design Guidelines" [TRACE-REF] compiled by G. Vanderheiden, TRACE Center. A thorough reference work.
- "Designing for Accessibility" [SUN-DESIGN] Eric Bergman and Earl Johnson. This paper discusses specific disabilities including those related to hearing, vision, and cognitive function.
- "EITAAC Desktop Software standards" [EITAAC] Electronic Information Technology Access Advisory (EITAAC) Committee.
- "Making Educational Software and Web Sites Accessible " [http://ncam.wgbh.org/cdrom/guideline/] Geoff Freed, Madeleine Rothberg and Tom Wlodkowski, National Center for Accessible Media, 2003. This document provides additional information for math and science software.
- "Software Accessibility" [IBM-ACCESS] IBM
- "Towards Accessible Human-Computer Interaction" [SUN-HCI] Eric Bergman, Earl Johnson, Sun Microsystems 1995. A substantial paper, with a valuable print bibliography.
- "User Agent Accessibility Guidelines 1.0" [UAAG10] I. Jacobs, J. Gunderson, E. Hansen, eds. W3C
- "Web Content Accessibility Guidelines 1.0" W3C
- "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 A-3: Including authors with disabilities and authors using assistive technologies in focus groups and user testing throughout the design and development of the authoring tool user interface.
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.
Applicability: This success criteria is not applicable if the authoring tool lacks any component that is accessed via a Web browser.
Technique A.0.1-1: For Web-based applications, following the requirements of WCAG. This means implementing the WCAG techniques for the technology in which the authoring interface is constructed. [Sufficient]
Technique A.0.1-2: Testing Web-based authoring interfaces against WCAG using automated evaluation and repair tools for the technology in which the authoring interface is constructed
This guideline requires that the user interface of the authoring tool be accessible by a variety of video, audio or tactile display devices that the author may choose.
Rationale: People who have difficulty perceiving non-text content can often access the same information if it is conveyed using a text alternative (by assistive technology or braille, for example).
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Applicability: This success criteria is not applicable if the authoring tool lacks any non-text objects within the user interface (rendering non-text objects in the content does not apply here).
Technique A.1.1-1: Ensuring all non-text objects in the user interface that are not strictly decorative have a text alternative that is available both on screen (e.g. by tool tip) and programmatically to assistive technologies. [Sufficient]
Technique A.1.1-2: For tools that display the source structure of markup document using graphic representations of tags, providing the author with the option of displaying the tag information as text.
Technique A.1.1-3: For tools that display collections of content using graphic representations of the objects, links, etc., providing the author with the option of displaying the information as text. (i.e., as a structured tree file).
Applicability: This success criteria is not applicable if the authoring tool does not allow non-text objects to be authored (e.g. the content type does not include non-text objects).
Technique A.1.1-4: In editing views that render non-text objects, displaying in an editable fashion any text alternatives (short text labels, long text descriptions) associated with the objects (e.g. within a properties dialog). [Sufficient]
Technique A.1.1-5: When appropriate for a content type, providing a code-level editing view that, by its nature, allows direct editing of all properties. [Sufficient]
Technique A.1.1-6: Providing an option to toggle between rendered non-text object and the text alternatives for the object. (see Example A.1.1-6)
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.
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Applicability: This success criteria is not applicable if the authoring tool lacks any multimedia objects within the user interface (rendering multimedia objects in the content does not apply here).
Technique A.1.2-1: For multimedia objects in the user interface that are not strictly decorative, providing synchronized alternatives (captions for videos that include audio of speech; captions for audio files that include speech; audio descriptions for videos with visual information that is not already described or read in the audio track). [Sufficient]
Applicability: This success criteria is not applicable if the authoring tool does not allow multimedia objects to be authored (e.g. the content type does not include multimedia objects).
Technique A.1.2-2: In editing views that render multimedia, also displaying any synchronized alternatives (captions for video; captions for audio files; audio descriptions for videos). [Sufficient]
Rationale: Some authors require alternative display configurations to use the authoring interface.
Note: The success criteria for this checkpoint are based on the capabilities of platforms (e.g. operating systems, browsers, GUI toolkits, etc. as defined in the conformance profile), however developers are free to provide additional configuration.
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Applicability: This success criteria is not applicable if the authoring tool relies on the visual display settings of the platform and supports the full setting range of the platform.
Technique: A.1.3-1: For authoring tools that do not rely on the platform settings, providing options to modify the same visual display parameters within the same range as the platform (e.g. for an authoring tool running on Windows XP this means supporting: a wide range of serif and non-serif fonts; text sizes between 6pt and 24pt; at least 256 colour choices for text and backgrounds; font face settings of regular, bold or italic; but no specific settings for text spacing or positioning) [Sufficient]
Applicability: This success criteria is not applicable if the authoring tool relies on the audio display settings of the platform and supports the full setting range of the platform.
Technique: A.1.3-2: For authoring tools that do not rely on the platform settings, providing options to modify the same audio display parameters within the same range as the platform (e.g. for an authoring tool running on Windows XP this means supporting: volumes between "mute" and the maximum allowed by the current setting of the physical speakers; the ability to substitute different sound files for any "alert" sound effect; at least three voice choices and a very wide reading speed range, if voice output is a feature) [Sufficient]
Rationale: Authors may require a set of display preferences to view and control the document that is different from the display styles that they want to define for the published document (e.g. a particular text-background combination that differs from the published version).
Applicability: This success criteria is applicable too all editing views, although WYSIWYG views are of most concern.
Technique A.1.4-1: Providing the author with the ability to change the fonts, colors, sizing (zoom), etc. within editing views (or by changing the platform display settings), independently of the ability to control the markup that is actually produced. [Sufficient]
Technique A.1.4-2: For authoring tools that offers a "rendered view" of a document, such as a browser preview mode, providing an editing view that has a presentation that can be controlled independently of the rendered view.
Technique A.1.4-3: Allowing the author to specify a local style sheet that will override the "published" style of the document in the editing view.
Technique A.1.4-4: Allowing the author to create audio style sheets using a graphical representation rather than an audio one
.
Rationale: Separating content and structure from presentation allows user interfaces of authoring tools to be presented differently to meet the needs and constraints of different authors without losing any of the information or structure. For example, information can be presented via speech or braille (text) that was originally intended to be presented visually. It can also facilitate automatic emphasis of structure or more efficient navigation. All of these can benefit authors with cognitive, physical, hearing, and visual disabilities.
@@
@@
@@
@@
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.
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 accommodation for individuals with limited mobility or those with visual disabilities who cannot rely on hand eye coordination for navigating the user interface.
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Applicability: This success criteria is applicable to all authoring tools.
Technique A.2.1-1: Providing sequential keyboard access (with different keystrokes) for moving the focus between user interface areas (e.g. from the menus to the editing view to the floating toolbars, etc.) and editing views. Also provide sequential keyboard access (with different keystrokes) for moving the focus within all of the controls within each user interface area (e.g. the menu items, the editing view objects, the floating toolbar controls) and editing view. Also provide the ability to operate any control with the keyboard alone. [Sufficient]
Technique A.2.1-2: Providing direct keyboard access to frequently used functions or to functions that may be located further along in the sequential tab order than its frequency of use would warrant.
Technique A.2.1-3: Providing mouse only controls only when equivalent keyboard accessible functionality is also provided (see Example A.2.1.3).
Example A.2.1-3: This illustration shows an authoring user 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)
Description:
Applicability: This success criteria is applicable to all authoring tools.
Technique A.2.1-4: For sequential keyboard access, ensuring that as each control receives focus, no activation is made automatically that would prevent further sequential navigation. For direct keyboard access, ensuring that as the control receives focus, it is only activated if the controls has only one setting (e.g. a particular menu item). Ensuring that when controls with more than one setting (e.g. drop down menus) receive the focus no setting is automatically activated. [Sufficient]
Applicability: This success criteria is applicable to all authoring tools.
Technique A.2.1-5: For sequential keyboard access (moving focus backwards and forwards through the user interface and editing views), ensuring a logical reading order when the feature is used (e.g. if a button operates on the contents of a textbox, ensure that the textbox occurs before the button. [Sufficient]
Applicability: This success criteria is applicable to all authoring tools that include the listed functionalities.
Technique A.2.1-6: Providing key-plus-modifier-key (or single-key) access for moving the content focus to the previous enabled control (e.g. shift-TAB); navigate between panels or windows (e.g. ctrl-TAB); opening help system (e.g. F1); open new content (e.g. ctrl-N); open existing content (e.g. ctrl-O); save content (e.g. ctrl-S); close content (e.g. ctrl-W); cut/copy/paste (e.g. ctrl-X, ctrl-C, ctrl-V); undo/redo (e.g. ctrl-Z, ctrl-Y); open find/replace function (e.g. ctrl-F, ctrl-H); and navigate to the start and end (e.g. ctrl-Home, ctrl-End). [Sufficient]
Technique A.2.1-7: Expanding direct keyboard access beyond the functions listed in this success criteria to other frequently used functions of a tool (e.g. to perform text formatting, move quickly between windows, etc.).
Technique A.2.1-8: Following platform conventions when choosing keystrokes (see also Checkpoint A.3.1).
- MacOS: http://docs.info.apple.com/article.html?artnum=75459
- Windows: http://support.microsoft.com/default.aspx?scid=kb;en-us;q126449
- Gnome/KDE: http://www.novell.com/coolsolutions/tip/2289.html
Technique A.2.1-9: Documenting the keystrokes chosen for all keyboard access features (see also Checkpoint A.3.3 ).
Technique A.2.1-10: Providing a mode in which the author can navigate the editing view of content by the same accesskeys that are defined in that content.
Rationale: Authors who have limited mobility require quick access to the actions that they use frequently.
Applicability: This success criteria is not applicable to authoring tools that lack selectable actions.
Technique A.2.2-1: Listing each selectable action (e.g. all of the controls in the menu system and button bars that can be activated with a single selection) and allowing the author to select a keystroke for that action from a pool of available keystrokes. [Sufficient]
Applicability: This success criteria is not applicable to authoring tools that lack selectable actions.
Technique A.2.2-2: Listing all of the control items available to be displayed in at least one area of the user interface that is controllable by a single selection (e.g. button bar, palette, panel, etc) and allowing the author to specify which items are displayed and specify the order of the displayed items. [Sufficient]
Rationale: Authors who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits.
Note: Some time limits may be imposed by external systems. This checkpoint only applies to time limits within the control of the authoring tool.
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Applicability: This success criteria is not applicable to authoring tools that lack interface time limits.
Technique A.2.3-1: Allowing every time limit that is not controlled by a time-sensitive external processes to be configured by the author [Sufficient]
Technique A.2.3-2: Providing a single area in the options for setting any time limits.
Applicability: This success criteria is not applicable to authoring tools that lack interface time limits that are under the control of the authoring tool.
Technique A.2.3-3: Ensuring that if a configuration setting is available for a time limit, then the highest setting is larger than or equal to 20 seconds. [Sufficient]
Technique A.2.3-4: Completely avoiding arbitrary time limits.
Technique A.2.3-5: If an time-sensitive external process is causing a time limit, considering ways to reduce the impact on the author (e.g. giving advance warning, assisting with the time-limited action, etc.).
Rationale: Flashing can cause seizures in people with photosensitive epilepsy.
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Applicability: This success criteria is not applicable to authoring tools that lack flashing user interface controls and do not render objects in the editing view in a way that will cause flashing.
Technique A.2.4-1: Once flashing begins, providing a single input action that stops the flashing immediately. [Sufficient]
Technique A.2.4-2: Providing a single area in the options for disabling all flashing.
Technique A.2.4-3: Ensuring "no flashing" is the default setting.
Technique A.2.4-4: Completely avoiding the use of flashing.
Rationale: It is often efficient to make use of the structure that may be inherent within Web content in order to navigate editing views and perform edits. 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.
Applicability: This success criteria is not applicable when authoring content types that do not contain structured element sets.
Technique A.2.5-1: Providing the ability to move focus from any element to the element that contains it (i.e. parent element), if any. Also providing the ability to move focus from any element to the first sub-element that it contains (i.e. first child element), if any. Also providing the ability to move focus from any element to the element immediately preceding it as a sub-element of the same parent element (i.e. previous sibling). Also providing the ability to move focus from any element to the element immediately following it as a sub-element of the same parent element (i.e. next sibling). [Sufficient]
Technique A.2.5-2: Providing an "outline" or "structure" view of the document that organizes the structured element set into a document tree or graph.
Technique A.2.5-3: If loops are possible within the structured element set, providing a mechanism for alerting the author when they have completed a loop.
Technique A.2.5-4: Ensuring that a smooth transition exists between navigation via the content structure to a particular element and commencing to edit that element.
Applicability: This success criteria is not applicable when authoring content types that do not contain structured element sets.
Technique A.2.5-5: Ensuring that when an element is selected, any content, including sub-elements, of the element are also selected. Then, ensuring that when a selected element with content, including sub-elements, is the subject of an operation (cut, copy, styling, delete) the element's content should also be subject to the same operation unless the operation targets the element only. For example, if an element is selected and the "delete" operation is performed, the element's content including sub-elements are also be deleted. However, if the element is selected and the "strip element tags" operation is performed, the element's contents including sub-elements are not affected (other than having the containing element tags removed). [Sufficient]
Technique A.2.5-6: Providing other types of structure-based navigation:
- Navigation between headings.
- Navigation between and within table cells, columns, and rows.
- Navigation between elements of particular roles.
- Navigation between frames.
- Navigation through the timeline of the time-based presentations (e.g. expressed by SMIL).
- Navigate between the regions of the image (e.g. expressed in SVG).
- Navigate between interactive structure elements (e.g. links, form elements, etc.) of hypertext documents (e.g. expressed in HTML).
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.
For Web-Based Interface Components: Web-based authoring tools may make use of the find function of the browsers to help perform the searches.
Applicability: This success criteria is not applicable to authoring tools that prevent the author from to editing content.
Technique A.2.6-1: Supporting searching for plain text sequences within the content (e.g. text between the open and close tags of an element, text in a content management database) and within text alternatives for non-text content (e.g. short text labels, long text descriptions, etc.) even when this information is encoded as markup (e.g. as an attribute value). [Sufficient]
Applicability: This success criteria is not applicable to authoring tools that prevent the author from directly editing markup.
Technique A.2.6-2: Support searching for plain text sequences within author-editable markup (e.g. element name, attribute value, etc.). [Sufficient]
Technique A.2.6-3: Provide structure-based searching that takes into account structural roles and relationships.
Example A.2.6-3: 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)
Description:
Technique A.2.6-4: Providing more advanced search options:
- text search options such as replacement, case (in)sensitivity, wildcard characters, whole word matching, search repetition, and highlighting of all occurrences.
- option to search the content only, the markup only, or both.
- use metadata (per WCAG 2.0 [WCAG20]) to 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)
- for tools that manage a database or multiple files, provide a search function that can search through the different pieces of content at once.
- allow the author to select an area by similarity to the search probe (e.g. closeness of color in an image editor, etc.)
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.
For Web-Based Interface Components: Web-based authoring tools may rely on the undo function of the browser to perform the undo function for editing actions that do not involve server communication (e.g. typing in a text area). Therefore, all Web-based interface components, that meet Checkpoint A.0.1 will serve to meet this checkpoint as long as the user agent(s) specified in the conformance profile have the ability to perform at least one level of text entry undo.
Applicability: This success criteria is applicable to all authoring tools (except see note on Web-Based tools above).
Technique A.2.7-1: Ensuring that all actions that modify Web content (e.g. typing, adding an element, changing an attribute value, etc.) are reversible by means of an undo function or warn the the author that the action is irreversible (e.g. closing without saving). [Sufficient]
Applicability: This success criteria is not applicable to authoring tools that have not met Success Criteria 1 for this checkpoint.
Technique A.2.7-2: Maintainig a queue of recent actions (from most to least recent) and providing a function that can reverse the actions one-by-one starting with the most recent. [Sufficient]
Applicability: This success criteria is not applicable to authoring tools that have not met Success Criteria 2 for this checkpoint.
Technique A.2.7-3: Maintaining a queue of undo actions (but cleared if a non-undo action is made) and providing a function that can reverse the undo actions one-by-one starting with the most recent. [Sufficient]
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.
Applicability: This success criteria is not applicable to authoring tools that rely on the platform to set the visual and auditory display settings and do not include any keyboard access configuration settings.
Technique A.2.8-1: Providing a mechanism for saving and reloading configuration settings for the visual display (if these are not set by the platform), for the auditory display (if these are not set by the platform), and for the keyboard access configuration settings (if configuration settings exist). The saving and reloading may be invisible to the author. [Sufficient]
Applicability: This success criteria is not applicable to authoring tools that have not met Success Criteria 1 for this checkpoint.
Technique A.2.8-2: Providing the ability for the author to select from multiple configuration set options when they begin a session. Each set contains the configuration settings for the visual display (if these are not set by the platform), for the auditory display (if these are not set by the platform), and for the keyboard access configuration settings (if configuration settings exist). [Sufficient]
Technique A.2.8-3: Providing the ability for the author to select from multiple configuration set options from within a session.
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 feature(s) 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. For example, an incomplete document may not be renderable by the preview.
Applicability: This success criteria is not applicable to authoring tools that lack a preview function.
Technique A.2.9-1: Allowing the author to locate a browser on the platform with which to perform the preview. (Note: Clearly, this is the most efficient way to satisfy this checkpoint). [Sufficient]
Technique A.2.9-2: Allowing the author to save a list of browsers (or auto-generate the list) to save time.
Technique A.2.9-3: Ensuring that the preview feature has the same UAAG 1.0 conformance rating as the emulated browser. [Sufficient]
Technique A.2.9-4: Documenting all of the accessibility features of the preview feature as compared to the emulated browser. [Sufficient]
Technique A.2.9-5: For Web-based authoring tools, allowing the platform browser to be the preview browser. [Sufficient]
Technique A.2.9-6: Ensuring that all of the menus, toolbars, dialog boxes etc. is accessible (i.e. meet the other requirements of Part A), even if this departs from the functionality of the emulated browser. [Sufficient]
Technique A.2.9-7: Providing an accessible method for exiting the preview and returning to the editing views (i.e. meets the other requirements of Part A), even if this departs from the functionality of the emulated browser. [Sufficient]
Technique A.2.9-8: Ensuring that the preview meets all of the other requirements of Part A. [Sufficient]
This guideline requires that the user interface of the authoring tool be understandable.
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.
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Applicability: This success criteria is applicable to all authoring tools.
Technique A.3.1-1: Following platform specific conventions for focus and selection: [Sufficient]
- MacOS: "Accessibility Documentation" [APPLE-ACCESS] Apple Computer Inc.
- Microsoft Windows: "Accessibility for applications designers" [MS-ENABLE] Microsoft Corporation.
- 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.
Applicability: This success criteria is applicable to all authoring tools.
Technique A.3.1-2: Following platform specific conventions when choosing keystrokes: [Sufficient]
- MacOS: http://docs.info.apple.com/article.html?artnum=75459
- Windows: http://support.microsoft.com/default.aspx?scid=kb;en-us;q126449
- Gnome/KDE: http://www.novell.com/coolsolutions/tip/2289.html
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.
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Applicability: This success criteria is applicable to all authoring tools.
Technique A.3.2-1: Ensuring that user interface controls that are labeled with the same text (e.g. OK, Cancel, Save, Bold, Paste, etc.) or icon graphic (e.g. icon of a disk, icon of a pair of scissors, etc.) always perform the same function. [Sufficient]
Applicability: This success criteria is applicable to all authoring tools.
Technique A.3.2-2: Ensuring that the same text (e.g. "Image Properties", etc.) or icon graphic (e.g. icon of a blank image, etc.) is not used to label more than one function or type of object. [Sufficient]
Applicability: This success criteria is applicable to all authoring tools.
Technique A.3.2-3: Always being consistent in the way controls appear . [Sufficient]
Technique A.3.2-4: Ensuring that functions that are available in multiple areas of a tool, are labeled consistently in at least once in each area. [Sufficient]
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.
Applicability: This success criteria is applicable to all authoring tools.
Technique A.3.3-1: Providing a complete version of the documentation (on the Web or bundled on the CD-ROM) as Web content that conforms to WCAG Level A. [Sufficient]
Applicability: This success criteria is applicable to all authoring tools.
Technique A.3.3-2: Documenting all aspects of the user interface covered by Part A of these guidelines (including keyboard accessibility, display configurability, etc.). [Sufficient]
Technique A.3.3-3: Providing a documentation index to accessibility features.
Applicability: This success criteria is applicable to all authoring tools.
Technique A.3.3-4: Displaying the current configuration of accessibility features (i.e. keyboard shortcuts, visual display (if applicable), auditory display (if applicable)) either centrally or in a distributed fashion. [Sufficient]
Technique A.3.3-5: Making context sensitive help and other forms of support accessible, in addition to the larger help pages.
Technique A.3.3-6: Providing installation codes in accessible electronic format, not just in the paper documentation or printed on the installation media.
This guideline requires that the user interface of the authoring tool be compatible with a variety of access systems that the author may choose.
Rationale: While intuitive authoring interface design is valuable to many authors, some authors may still not be able to understand or be able to operate the authoring interface without thorough documentation. For instance, an author who is blind may not find a graphical authoring interface intuitive without supporting documentation.
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Applicability: This success criteria is applicable to all authoring tools.
Technique A.4.1-1: Implementing the relevant accessibility platform architecture(s) [Sufficient]:
- Gnome Accessibility:
- Java Accessibility:
- 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.
- MacOS X Accessibility: "Accessibility Documentation" [APPLE-ACCESS] Apple Computer Inc.
- Microsoft Windows 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.
- 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.
Applicability: This success criteria is not applicable to authoring tools that conform fully to the relevant accessibility platform architectures.
@@
Contents | Part A | Part B | References