Contents | Part A | Part B | References

W3C

Implementation Techniques for
Authoring Tool Accessibility Guidelines 2.0:

Part A: Make the user interface accessible

Editor's Draft DD MM YYYY

Editors of this chapter:
Jutta Treviranus - ATRC, University of Toronto
Jan Richards - ATRC, University of Toronto

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.

Notes:

General Techniques for Checkpoints in Part A

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:

Technique A-2: Following other guidelines and best practice documents for specific technologies where they are relevant. These include:

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.

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

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

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

Guideline A.1 Authoring Interface must be Perceivable:

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.

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

Techniques for Success Criteria 1: All user interface non-text objects that are used to convey information (e.g., toolbar icon, graphical depiction of a tag, sound effect, etc.) must have a text alternative (e.g. alternative text label, long text description).

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

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.

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)

Applicable to 'what you see is what you get' authoring functions Example A.1.1-6: 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)

ATAG Checkpoint A.1.2 Provide synchronized alternatives for multimedia in the user interface. [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.

For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

Techniques for Success Criteria 1: All user interface multimedia that is used to convey information (e.g., tutorial videos, progress indicators, etc.) must have synchronized alternatives (e.g. captions, audio descriptions).

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]

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

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]

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

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.

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.

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]

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.

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]

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 display styles that they want to define 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.

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.

ATAG Checkpoint A.1.5 Ensure that information, functionality, and structure can be separated from presentation. [Priority 1]

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.

Techniques for Success Criteria 1: If information is conveyed by variations in the presentation of text (e.g. by the spatial location of text), then the information must also either be conveyed in text or be made available programmatically.

@@

Techniques for Success Criteria 2: If information is conveyed by color, then the information must also be: conveyed in text or be made available programmatically; and conveyed in a way that is visually evident when color is not available (e.g. by shape)

@@

Techniques for Success Criteria 3: If content is structured (e.g. form controls grouped), then that structure must be made available programmatically.

@@

Techniques for Success Criteria 4: If the sequence of content affects its meaning, then the sequencing information must be made available programmatically.

@@

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.

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

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

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

Applicable to 'what you see is what you get' authoring functions 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)
This illustration shows an authoring user interface that has two equivalent mechanisms for editing the height and width properties of an image - see description below.
Description:

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

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]

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

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]

Techniques for Success Criteria 4: Key-plus-modifier-key (or single-key) access must be provided to the following functionalities (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.

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

General Techniques for Checkpoint A.2.1:

Technique A.2.1-8: Following platform conventions when choosing keystrokes (see also Checkpoint A.3.1).

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.

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.

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]

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, palette, panel, etc).

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]

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

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

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.

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.

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]

General Techniques for Checkpoint A.2.3:

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

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.

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

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.

General Techniques for Checkpoint A.2.4

Technique A.2.4-4: Completely avoiding the use of flashing.

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

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.

Techniques for Success Criteria 1: For 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).

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.

Techniques for Success Criteria 2: For any structured element set, the author must always be able to select content and perform editing functions (e.g. cut, copy, paste, styling) on any element along with any content, including sub-elements.

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]

General Techniques for Checkpoint A.2.5:

Technique A.2.5-6: Providing other types of structure-based navigation:

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.

For Web-Based Interface Components: Web-based authoring tools may make use of the find function of the browsers to help perform the searches.

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

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]

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

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.

Applicable to Code-Level authoring functions 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:

General Techniques for Checkpoint A.2.6:

Technique A.2.6-4: Providing more advanced search options:

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.

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.

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.

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]

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

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]

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

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]

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 1: The authoring tool must provide the ability to save and reload all configuration settings related to visual or auditory output and keyboard operability.

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]

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

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.

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

Techniques for Success Criteria 1: If a preview is provided, then:

Applicability: This success criteria is not applicable to authoring tools that lack a preview function.

(a) The author must be able to choose an external browser to perform the preview;

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.

(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:

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]

(i) Any authoring tool user interface other than the content being previewed must meet the other requirements of Part A.,

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]

(ii) and, a means of exiting the preview must be provided that meet the other requirements of Part A;

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]

(c) or, the preview does not claim to emulate a specific browser, in which case it must meet all of the requirements of Part A. In other words, Note 1 does not apply.

Technique A.2.9-8: Ensuring that the preview meets all of the other requirements of Part A. [Sufficient]

Guideline A.3 : Authoring Interface must be Understandable

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

ATAG Checkpoint A.3.1 Observe the accessibility conventions of the platform.[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.

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

Applicability: This success criteria is applicable to all authoring tools.

Technique A.3.1-1: Following platform specific conventions for focus and selection: [Sufficient]

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.

Applicability: This success criteria is applicable to all authoring tools.

Technique A.3.1-2: Following platform specific conventions when choosing keystrokes: [Sufficient]

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.

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

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]

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

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]

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.

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]

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 the minimum requirements (Level 1) of WCAG (whether delivered on the Web, CD-ROM, etc.).

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]

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

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.

Techniques for Success Criteria 3: The current configuration of accessibility features 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).

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]

General Techniques for Checkpoint A.3.3:

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.

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.

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

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.

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

Applicability: This success criteria is applicable to all authoring tools.

Technique A.4.1-1: Implementing the relevant accessibility platform architecture(s) [Sufficient]:

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.

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