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 6 March 2006

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

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:

Applicability: Techniques in this section are not necessarily applicable to any one checkpoint or success criteria, and may apply more generally to Part A as a whole.

Technique A-0.1 [Advisory]: 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 following:

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

Technique A-0.3 [Advisory]: 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 | Note)

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.1 [Sufficient]: 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. @@add benchmark doc ref to Guideline doc@@

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Example A.01-1.1: Throughout tool development the templates and other mechanisms that are used to generate the authoring interface are designed with WCAG conformance as a goal and are periodically checked to ensure conformance.

Technique A.0.1-1.2 [Advisory]: Testing Web-based authoring interfaces against WCAG using automated evaluation and repair tools.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Example A.01-1.2: Throughout development, with the authoring tool in various states that are representative of the range of tasks that the tool is able to perform, "snap-shots" of the tool are captured with the user agent. These snap-shots, containing both the editing interface and the content being authored are then examined with WCAG evaluation software. Problems are corrected and the process continues to iterate.

Guideline A.1 Authoring Interface must be Perceivable:

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

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.1 [Sufficient]: Ensuring all non-text objects (images and sounds) 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.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Example A.1.1-1.1: A given tool has images in several places (toolbar buttons, small explanatory images in several dialog boxes, and large screenshots in the on-line documentation). Each toolbar button is labelled in a with a tooltip in a standard fashion. The small explanatory image is properly labelled and the large screenshots are accompanied by both alternative text labels and long text descriptions.

Technique A.1.1-1.2 [Advisory]: For tools that display the source structure of markup documents using graphic representations of tags, providing the author with the option of displaying the tag information as text.

Applicable to 'what you see is what you get' authoring functions Example A.1.1-1.2: A given tool as a view that is WYSIWYG exept that graphics are added to the editing view to show where elements start and end. In the author preferences of the tool, there is a option to "Show tags as text", which replaces the tag graphics in the "almost" WYSIWYG view with the text of the tags (e.g. <img> and </img>).

Technique A.1.1-1.3 [Advisory]: 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. (e.g. as a structured tree).

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-2.1 [Sufficient]: 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).

Applicable to 'what you see is what you get' authoring functions

Technique A.1.1-2.2 [Sufficient]: When appropriate for a content type, providing a code-level editing view that allows direct editing of all properties.

Applicable to Code-Level authoring functions A text edito provides only one way of editing content, via a code-level editing view that provides access to all markup and content.

Technique A.1.1-2.3 [Advisory]: Providing an option to toggle between rendered non-text object and the text alternatives for the object.

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

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 does not have any multimedia objects within the user interface. Tthis checkpoint does not apply to multimedia objects in the content display since the presence or lack of synchronized alternatives for author content is not under tool control (however, see Checkpoint B.1.4 if pre-authored content is provided).

Technique A.1.2-1.1 [Sufficient]: 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).

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.1 [Sufficient]: In editing views that render multimedia, also displaying any synchronized alternatives (captions for video; captions for audio files; audio descriptions for videos).

ATAG Checkpoint A.1.3 Ensure that all displays are configurable. [Priority 1] (Rationale | Note)

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.1 [Sufficient]: 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)

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.1 [Sufficient]: 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)

ATAG Checkpoint A.1.4 Allow the display preferences for the editing view to be changed without affecting the document markup. [Priority 1] (Rationale)

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.1 [Sufficient]: 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.

Technique A.1.4-1.2 [Advisory]: 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-1.3 [Advisory]: 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-1.4 [Advisory]: 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)

Techniques for Success Criteria 1 (For author-controlled presentation (e.g. author has used a style class) in rendered editing views , all characteristics of the presentation (e.g. color, boldness, positioning, etc.) must be available programmatically.):

Technique A.1.5-1.1 [Sufficient]: Providing information on the size, font, foreground and background color, font weight, and position of any text, that is under the control of the author, via an accessibility platform architecture or another published interoperability mechanism.@@

Techniques for Success Criteria 2 ( For authoring tool-controlled presentation in editing views (e.g. coloring misspelled words, identifying tag text in a code view), the semantic description of the presentation must be available programmatically.):

Technique A.1.5-2.1 [Sufficient]: Providing sematic labels and descriptions for any presentation, that is added to the editing view by the authoring tool, via an accessibility platform architecture or another published interoperability mechanism.@@

Techniques for Success Criteria 3 ( For the presentation of controls within the editing interface of the authoring tool user interface (e.g. dialog boxes, menus, button bars, user interface elements in the editing view), the semantic description of the presentation must be available programmatically.):

Technique A.1.5-3.1 [Sufficient]: Providing sematic labels and descriptions for any presentation, that is that is part of the editing interface, via an accessibility platform architecture or another published interoperability mechanism.@@

Techniques for Success Criteria 4 ( Any information that is conveyed by color (e.g. red underlining for spelling error vs. green underlining for grammar error) is either visually evident when color is not available (e.g. by the shape of the underlining) or is provided by an alternative version that meets Part A (e.g. spell and grammar checking utilities).):

Technique A.1.5-4.1 [Sufficient]: Ensuring (by design, testing on monochrome displays, including color blind individuals in testing, etc.), that color alone is not required to identify any single element of the editing interface of the tool.@@

Technique A.1.5-4.2 [Sufficient]: Providing an alternative route to the information or functionality that is accessed via an element of the editing interface of the tool that requires color discrimination to understand or access.@@

Guideline A.2: Authoring Interface must be Operable

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

For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet success criteria 1 and 2 of this checkpoint. Browser functionality (e.g. for "cut/copy/paste") or access keys (e.g. for "open new content") may be relied on to achieve success criteria 3 and 4 as long as the applicable user agent(s) are specified in the conformance profile. Also see Checkpoint A.3.1 when choosing keystrokes.

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.1 [Sufficient]: 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.

Technique A.2.1-1.2 [Advisory]: 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-1.3 [Advisory]: Providing mouse only controls only when equivalent keyboard accessible functionality is also provided.

Applicable to 'what you see is what you get' authoring functions Example A.2.1-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-2.1 [Sufficient]: 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.

Techniques for Success Criteria 3 (There must be an option to enable single-key access 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-3.1 [Sufficient]: 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.

Techniques for Success Criteria 4 ( There must be an option to enable key-plus-modifier-key (or single-key) access 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-4.1 [Sufficient]: 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).

Technique A.2.1-4.2 [Advisory]: 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:

Applicability: Techniques in this section are not necessarily applicable to any one success criteria, and may apply more generally to the checkpoint as a whole.

Technique A.2.1-0.1 [Advisory]: Following platform conventions when choosing keystrokes (see also Checkpoint A.3.1), such as:

Technique A.2.1-0.2 [Advisory]: Documenting the keystrokes chosen for all keyboard access features (see also Checkpoint A.3.3 ).

Technique A.2.1-0.3 [Advisory]: 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)

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.1 [Sufficient]: 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.

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-1.2 [Sufficient]: 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.

ATAG Checkpoint A.2.3 Allow authors to control time limits. [Priority 1] (Rationale | Note)

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.1 [Sufficient]: Allowing every time limit that is not controlled by a time-sensitive external processes to be configured by the author.

Technique A.2.3-1.2 [Advisory]: 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-2.1 [Sufficient]: Ensuring that if a configuration setting is available for a time limit, then the highest setting is larger than or equal to 20 seconds.

General Techniques for Checkpoint A.2.3:

Applicability: Techniques in this section are not necessarily applicable to any one success criteria, and may apply more generally to the checkpoint as a whole.

Technique A.2.3-0.1 [Advisory]: Completely avoiding arbitrary time limits.

Technique A.2.3-0.2 [Advisory]: 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)

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.1 [Sufficient]: Once flashing begins, providing a single input action that stops the flashing immediately.

Technique A.2.4-1.2 [Advisory]: Providing a single area in the options for disabling all flashing.

Technique A.2.4-1.3 [Advisory]: Ensuring "no flashing" is the default setting.

General Techniques for Checkpoint A.2.4:

Applicability: Techniques in this section are not necessarily applicable to any one success criteria, and may apply more generally to the checkpoint as a whole.

Technique A.2.4-0.1 [Advisory]: 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)

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 support structured element sets, collections of elements related by some organization (e.g. hierarchy, graph).

Technique A.2.5-1.1 [Sufficient]: 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).

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Example: A.2.5-1.1: The element with current focus (e.g. tr) is highlighted and the element’s place in the structure of the content is explicit (e.g. in a hierarchy, by breadcrumbs, showing parent elements, grand-parent elements, etc.). Keystrokes are available to move the focus to the parent element that points to the current element (e.g. table), to any element pointed to by the cureent element (e.g. td) and to the next and previous element pointed to by the same parent element (e.g. previous and following tr elements).

Technique A.2.5-1.2 [Advisory]: 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-1.3 [Advisory]: 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-1.4 [Advisory]: 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-2.1 [Sufficient]: 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).

Note: Various editing functions intrinsically apply differently when performed on a selected element. These differences might be classified according to their scope, as follows:

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functionsExample A.2.5-2.1: An element with sub-elements (e.g. p with several span elements) is selected. The author chooses “copy” from a dropdown menu and then sets a new insertion point and selects “paste”. The authoring tool inserts a copy of the p element with identical information within and between its tags, including the span sub-elements fully intact.

General Techniques for Checkpoint A.2.5:

Applicability: Techniques in this section are not necessarily applicable to any one success criteria, and may apply more generally to the checkpoint as a whole.

Technique A.2.5-0.1 [Advisory]: Providing other types of structure-based navigation, such as:

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

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.1 [Sufficient]: 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).

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.1 [Sufficient] : Support searching for plain text sequences within author-editable markup (e.g. element name, attribute value, etc.).

Technique A.2.6-2.2 [Advisory]: Provide structure-based searching that takes into account structural roles and relationships.

Applicable to Code-Level authoring functions Example A.2.6-2.2: This illustration shows a search facility that makes effective use of structure. This eliminates the potential confusion of markup with content that is possible in basic text search (Source: mockup by AUWG)

Description:

General Techniques for Checkpoint A.2.6:

Applicability: Techniques in this section are not necessarily applicable to any one success criteria, and may apply more generally to the checkpoint as a whole.

Technique A.2.6-0.1 [Advisory]: Providing more advanced search options, such as:

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

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.1 [Sufficient] : 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).

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.1 [Sufficient] : 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.

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.1 [Sufficient]: 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.

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

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.1 [Sufficient]: 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.

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.1 [Sufficient]: 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).

Technique A.2.8-3.1 [Advisory]: 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 | Note 1 | Note 2)

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: Any other part of the authoring tool user interface other than the content being previewed must meet the other requirements of Part A and a means of exiting the preview must be provided that meet the other requirements of Part A; (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.

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

Technique A.2.9-1.1 [Sufficient for (a)]: Allowing the author to locate a browser on the platform with which to perform the preview).

Technique A.2.9-1.2 [Sufficient for (a)]: For Web-based authoring tools, that are already running in a browser, allow that browser to be the preview.

Technique A.2.9-1.3 [Sufficient for (b)]: Providing conformance tests to show that the preview feature has the same UAAG 1.0 conformance rating as the target browser being emulated and ensuring that all of the menus, toolbars, dialog boxes etc. that are not part of the content display, including the method of exiting the preview meet the relevant requirements of Part A (i.e. not A.2.5, A.2.6, A.2.9, A.3.2), even if this means a departure from the functionality of the emulated browser.

Technique A.2.9-1.4 [Sufficient for (b)]: Documenting all of the accessibility features of the preview feature as compared to the emulated browser.

Technique A.2.9-1.5 [Sufficient for (c)]: Ensuring that the entire preview (content view and the rest of the user interface) meets all of the relevant requirements of Part A (i.e. not A.2.5, A.2.6, A.2.9, A.3.2).

Technique A.2.9-1.6 [Advisory]: Allowing the author to save a list of user agents to save time.

Technique A.2.9-1.7 [Advisory]: Helping the author to find a user agent to perform the preview, by auto-scanning the system for known user agents.

Technique A.2.9-1.8 [Advisory]: Bundling user agent installer files or providing a list of download sites for appropriate user agents.

Guideline A.3 : Authoring Interface must be Understandable

ATAG Checkpoint A.3.1 Observe the accessibility conventions of the platform.[Priority 2] (Rationale)

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.1 [Sufficient]: Following platform specific conventions for focus and selection, such as:

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.1 [Sufficient]: Following platform specific conventions when choosing keystrokes, such as:

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

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.1 [Sufficient]: 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.

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.1 [Sufficient]: 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.

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.1 [Sufficient] : Always being consistent in the way controls appear .

Technique A.3.2-3.2 [Sufficient]: Ensuring that functions that are available in multiple areas of a tool, are labeled consistently in at least once in each area.

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

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.1 [Sufficient]: 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.

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.1 [Sufficient]: Documenting all aspects of the user interface covered by Part A of these guidelines (including keyboard accessibility, display configurability, etc.).

Technique A.3.3-2.2 [Advisory]: Providing a documentation index to accessibility features.

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

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

Technique A.3.3-3.1 [Sufficient]: 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.

General Techniques for Checkpoint A.3.3:

Applicability: Techniques in this section are not necessarily applicable to any one success criteria, and may apply more generally to the checkpoint as a whole.

Technique A.3.3-0.1 [Advisory]: Making context sensitive help and other forms of support accessible, in addition to the larger help pages.

Technique A.3.3-0.2 [Advisory]: 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

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

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.1 [Sufficient]: Implementing the relevant accessibility platform architecture(s), such as:

Techniques for Success Criteria 2 ( If there is any authoring tool functionality or information that is not addressed by available accessibility platform architectures, another published interoperability mechanism must be provided 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.

Technique A.4.1-2.1 [Sufficient]: Extend an existing API, if the API is extensible or the source is available.

Technique A.4.1-2.2 [Sufficient]: Create a new API.

Technique A.4.1-2.3 [Advisory]: Expose the internal application data model of the content being authored through an API. Consult "Accessibility requirements for systems design to accommodate users with vision impairments" [API-DESIGN]

Contents | Part A | Part B | References