Part A: Make the user interface accessible

Notes:

• These techniques are informative (i.e., non-normative).
• The lists of techniques for each success criteria are not exhaustive. Rather, these techniques represent an illustrative sampling of approaches. There may be many other ways a tool might be designed and still meet the normative criteria contained in the success criteria.
• Some techniques are labeled as "[Sufficient]". These techniques are judged by the Working Group to meet the success criteria to which they apply. Conditional wording may limit the applicability of any given sufficient technique to a particular type of content or authoring tool. Inclusion does not imply that the description will be verified or is verifiable.
• Some techniques are labeled as "[Advisory]". These techniques are included as additional information.
• Use of mock screenshots is for general illustrative purposes only. They do not imply endorsement of similar tools by the Working Group or suggests that these screenshots represent the best or only implementations.

ATAG Checkpoint A.0.1 For the authoring tool user interface, ensure that Web-based functionality conforms to WCAG. [Relative Priority] (Rationale | Note)

Techniques for Success Criterion 1 (All Web-based authoring tool user interface functionality must conform to WCAG.):

Applicability: This success criterion is only applicable to any authoring tool that includes components accessed via a user agent.

Technique A.0.1-1.1 [Sufficient]: Following the requirements of WCAG when developing Web-based authoring tools. This means implementing all of the requirements of the Content Type-Specific WCAG Benchmark (specified in the conformance claim) for the content-type(s) in which the authoring interface is implemented.

Example A.0.1-1.1: Throughout development of an authoring tool, the templates and other mechanisms that are used to generate the user 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 tools using automated evaluation and repair tools.

Example A.0.1-1.2: Throughout development of an authoring tool, with the tool in various representative states, "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 evaluation software. Problems are corrected and the process continues to iterate.

Guideline A.1 Authoring Tool User Interface must be Perceivable:

ATAG Checkpoint A.1.1 For the authoring tool user interface, provide text alternatives for all non-text objects. [Priority 1] (Rationale)

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet success criteria 1 of this checkpoint.

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

Applicability: This success criterion is only applicable if the authoring tool includes any non-text objects within the editing interface (i.e., rendering non-text objects that are part of the content does not apply).

Technique A.1.1-1.1 [Sufficient]: Ensuring all non-text objects (i.e., images, videos, sounds) in the editing interface that are not strictly decorative have a text alternative that is detailed enough to completely describe the role/purpose/action of the non-text object. The text alternative is available on screen permanently (e.g., label) or temporarily (e.g., by tool tip) and is available programmatically to assistive technologies.

Example A.1.1-1.1: An authoring tool has images in several places (e.g., toolbar buttons, small explanatory images in several dialog boxes, and large screenshots in the on-line documentation). Each toolbar button is labeled with a tooltip in a standard fashion. The small explanatory image is properly labeled 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.

Example A.1.1-1.2: An authoring tool has a view that is WYSIWYG except that graphics are added to the editing view to show where elements start and end. In the author preferences of the tool, there is an 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 Criterion 2 (The author must have the option to access an accessible multimedia alternative to any multimedia in the editing interface.):

Applicability: This success criterion is only applicable if the authoring tool includes any multimedia within the editing interface (i.e., rendering multimedia that is part of the content does not apply).

Technique A.1.1-2.1 [Sufficient]: Ensuring that any information or interactive options available via multimedia in the editing interface are also available via an accessible multimedia alternative (e.g., making use of text, forms and links).

Techniques for Success Criterion 3 (All editing views must always include an option to display any available text alternatives for non-text objects in the content being edited.):

Applicability: This success criterion is only applicable if the authoring tool ever renders non-text objects in the content being edited.

Technique A.1.1-3.1 [Sufficient]: In editing views that render non-text objects, displaying in an editable fashion any text alternatives (e.g., short text labels, long text descriptions) associated with the objects (e.g., within a properties dialog).

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

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

Example A.1.1-3.3: A quasi-WYSIWYG "design" editing interface includes an option to toggle fully rendered images with their text alternatives. On the left is the image (of the "earthrise" as seen from the moon) rendered as usual. On the right is a different rendering, this one including an area for editing the alt-text and a link to edit the long description. A small preview rendering of the image is included to provide context. (Source: mockup by AUWG)

ATAG Checkpoint A.1.2 For the authoring tool user interface, provide synchronized alternatives for multimedia. [Priority 2] (Rationale)

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

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

Applicability: This success criterion is only applicable if the editing interface includes multimedia (i.e., rendering multimedia that is part of the content does not apply).

Technique A.1.2-1.1 [Sufficient]: For multimedia in the editing interface (e.g., documentation, etc.) that are not strictly decorative, providing synchronized alternatives (e.g., 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 Criterion 2 (All editing views must always include an option to display any available synchronized alternatives for multimedia in the content being edited.):

Applicability: This success criterion is only applicable if the authoring tool ever renders multimedia in the content being edited.

Technique A.1.2-2.1 [Sufficient]: In editing views that render multimedia, also displaying any associated synchronized alternatives (e.g., captions for video, captions for audio files, audio descriptions for videos).

ATAG Checkpoint A.1.3 For the authoring tool user interface, ensure that all displays are configurable. [Priority 1] (Rationale | Note)

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

Techniques for Success Criterion 1 (If the visual display (e.g., fonts, sizes, colors, spacing, positioning) 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 criterion is only applicable if the authoring tool has its own visual display settings rather than relying on platform-wide settings.

Technique A.1.3-1.1 [Sufficient]: Providing options to modify the same visual display parameters within the same range as the platform specified in the conformance profile (e.g., in terms of font settings 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 color 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 Criterion 2 (If the audio display (e.g., volume, speech voices) 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 criterion is only applicable if the authoring tool has its own audio display settings rather than relying on platform-wide settings.

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

Techniques for Success Criterion 3 (Editing views that have their display characteristics set by rendering the content being edited (e.g., WYSWYG editing views) must override these characteristics if the author explicitly sets visual or audio display preferences as described in the previous two success criteria.):

Applicability: This success criterion is only applicable if the authoring tool sets some display characteristics according to the content (i.e. renders the content).

Technique A.1.3-3.1 [Sufficient]: Providing an option to override the rendering of content in editing views with the current display characteristics (set either at the authoring tool or platform level - see success criteria 1 and 2, above).

Techniques for Success Criterion 4 (Any visual or audio display settings must be saved between authoring sessions.):

Applicability: This success criterion is only applicable if the authoring tool has its own visual or audio display settings rather than relying on platform-wide settings.

Technique A.1.3-4.1 [Sufficient]: Saving all author settings between sessions, so that the settings remain the same when the author begins a new session.

ATAG Checkpoint A.1.4 For the authoring tool user interface, ensure changes to the display settings of editing views do not affect the content being edited. [Priority 1] (Rationale)

Techniques for Success Criterion 1 (The author must be able to configure the display settings of editing views without affecting the content being edited.):

Applicability: This success criterion is applicable to all editing views, although WYSIWYG editing 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 rendered editing views (or by changing the platform display settings), independently of the ability to control the markup that is actually produced.

Example A.1.4-1.1: A WYSIWYG authoring tool includes editing interface controls for setting the text and background colors as they will appear to the end user, but also includes a "View" area in its preference settings, where the author can choose to override the WYSIWYG rendering with their own text and background color settings.

Technique A.1.4-1.2 [Advisory]: Allowing the author to specify a preferred style sheet that is used in the editing view to override the actual "published" style of the document.

Technique A.1.4-1.3 [Advisory]: Allowing the author to create audio style sheets using a graphical representation rather than an audio one.

ATAG Checkpoint A.1.5 For the authoring tool user interface, ensure that information, functionality, and structure can be separated from presentation. [Priority 1] (Rationale)

Techniques for Success Criterion 1 (For rendered editing views (e.g., WYSIWYG editing view), all characteristics of the presentation (e.g., color, boldness, positioning) 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, if available, or otherwise another published interoperability mechanism.

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

Technique A.1.5-2.1 [Sufficient]: Providing semantic (i.e., text that conveys the meaning that is intended by the presentation) labels and descriptions for any presentation that is added to the editing view by the authoring tool, via an accessibility platform architecture, if available, or otherwise another published interoperability mechanism.

Techniques for Success Criterion 3 (For the presentation of controls within the editing interface (e.g., dialog boxes, menus, button bars, user interface controls in the editing view), the semantic description of the presentation (e.g., "paragraph tag" instead of "blue-colored <p>") must be available programmatically.):

Technique A.1.5-3.1 [Sufficient]: Providing semantic (i.e., text that conveys the meaning that is intended by the presentation) labels and descriptions for any presentation, that is that is part of the editing interface, via an accessibility platform architecture, if available, or otherwise another published interoperability mechanism.

Techniques for Success Criterion 4 (Any information that is conveyed by color (e.g., different colored underlines to indicate spelling and grammar errors) must meet at least one of the following: (a) visually evident when color is not available (e.g., by the shape of the underlining), or (b) provided by an alternative version that meets Part A (e.g., spelling and grammar checking utilities that provide the same functionality as the colored underline)):

Technique A.1.5-4.1 [Sufficient for (a)]: 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.

Example A.1.5-4.1: A multimedia authoring tool has toolbar buttons controls to stop and start the playing of the timed content. Instead of using a red circle for "stop" and a green circle for "go", the tool observes the "video" control conventions and uses redundant shape information: a red square for "stop" and a green "triangle for "go".

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

Example A.1.5-4.2: An authoring tool has a multimedia tutorial that plays lessons. At various places the author is able to click the presentation to make decisions about what to see next. The tool makes this feature accessible by providing an HTML-based accessible version that contains all of the same information.

Guideline A.2: Authoring Interface must be Operable

ATAG Checkpoint A.2.1 For the authoring tool user interface, ensure that all functionality is operable via a keyboard or a keyboard interface. [Priority 1] (Rationale | Note 1 | Note 2)

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet success criteria 1 and 2 of this checkpoint. User agent 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.

Techniques for Success Criterion 1 (The author must be able, through keyboard input alone, to perform any authoring task that is available through the authoring tool user interface (e.g., navigating, selecting, and editing content within editing views, operating the editing interface, installing and configuring the tool, and accessing documentation), except freeform drawing. This applies to at least one mechanism per task, allowing non-keyboard accessible mechanisms to remain available (e.g., inserting an image with an "insert image" menu item vs. drag-and-dropping the image file's icon into the document).):

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

Sufficiency: Technique A.2.1-1.1, Technique A.2.1-1.2, and Technique A.2.1-1.3, in combination, are sufficient to meet this checkpoint.

Technique A.2.1-1.1 [Sufficient in combination]: 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.

Technique A.2.1-1.2 [Sufficient in combination]: Providing 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.

Technique A.2.1-1.3 [Sufficient in combination]: Providing the ability to operate any control with the keyboard alone.

Technique A.2.1-1.4 [Advisory]: Providing direct keyboard access (such as via keyboard accelerators) 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.5 [Advisory]: Providing mouse only controls only when equivalent keyboard accessible functionality is also provided.

Example A.2.1-1.5: An authoring user interface has both mouse-driven and keyboard-driven mechanisms for editing the height and width properties of an image. On the left is the keyboard-driven version, which takes the form of height and width attribute fields in the image properties dialog box. On the right is the mouse-driven mechanism, which takes the form of graphical handles surrounding a rendering of the image (of the "earthrise" as seen from the moon). These let the author manipulate the image size directly. (Source: mockup by AUWG)

Techniques for Success Criterion 2 (The author must have the option to ensure 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 criterion is applicable to all authoring tools.

Sufficiency: Technique A.2.1-2.1, Technique A.2.1-2.2, and Technique A.2.1-2.3, in combination, are sufficient to meet this checkpoint.

Technique A.2.1-2.1 [Sufficient in combination]: For sequential keyboard access, ensuring that as each control receives focus, no activation is made automatically that would prevent further sequential navigation.

Example: A.2.1-2.1: An authoring tool offers several style templates within a dropdown list. Because the activation button is separate from the dropdown control, authors are able to use the keyboard to scan the possibilities before making a selection.

Technique A.2.1-2.2 [Sufficient in combination]: 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).

Technique A.2.1-2.3 [Sufficient in combination]: 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 Criterion 3 (The author must have the option to enable single-key access to both of the following functionalities: (a) move content focus to the next enabled control in the editing interface (e.g., using "tab" key), and (b) navigate forward and backward within editing views (e.g., using "arrow" keys).):

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

Technique A.2.1-3.1 [Sufficient]: Providing sequential keyboard access (i.e., moving focus backwards and forwards through the user interface and editing views).

Technique A.2.1-3.2 [Advisory]: Ensuring a logical reading order for sequential keyboard access (e.g., if a button operates on the contents of a textbox, ensure that keyboard navigation puts focus on the textbox before the button).

Techniques for Success Criterion 4 (The author must have the option to enable key-plus-modifier-key (or single-key) access to all of the following functionalities (if present): (a) move content focus to the previous enabled control (e.g., using "shift-tab" key), (b) navigate between panels or windows, (c) open help system, (d) open new content, (e) open existing content, (f) save content, (g) close content, (h) cut/copy/paste, (i) undo/redo, (j) open find/replace function, and (k) navigate to the start and end of the content being edited.):

Applicability: This success criterion 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 all of the functions listed here.

Example A.2.1-4.1: An authoring tool uses the following keyboard commands: 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 criterion to other frequently used functions of a tool (e.g., to perform text formatting, move quickly between windows, etc.).

Techniques for Success Criterion 5 (Any keyboard operability settings must be saved between authoring sessions.)

Applicability: This success criterion is applicable to all authoring tools that include keyboard settings.

Technique A.2.1-5.1 [Sufficient]: Saving all keyboard related author settings between sessions.

Techniques for Success Criterion 6 (The current keyboard settings must be available to the author at all times (e.g. in either a central location such as a list, or a distributed location such as associating shortcuts with menu items)).

Applicability: This success criterion is applicable to all authoring tools that include keyboard settings.

Technique A.2.1-6.1 [Sufficient]: Providing a documentation page that lists all of the keystrokes.

Technique A.2.1-6.2 [Sufficient]: Providing the keystrokes throughout the authoring tool user interface according to the platform conventions (e.g. listing associated shortcut keys with menu items).

General Techniques for Checkpoint A.2.1:

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

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

• MacOS: "Mac OS X keyboard shortcuts" [MACOSX-KEYS]
• Windows: "Keyboard shortcuts for Windows" [MS-KEYS]
• Gnome/KDE: "Gnome/KDE Keyboard Shortcuts" [GNOME-KDE-KEYS]

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

Technique A.2.1-General.3 [Advisory]: Providing a mode in which any accesskeys defined in the content can be used by the author to navigate the editing view of the content.

ATAG Checkpoint A.2.2 For the authoring tool user interface, ensure author configurable access to selectable items. [Priority 3] (Rationale)

Techniques for Success Criterion 1 (The author must have the option to set (and later modify) key-plus-modifier-key (or single-key) access for each selectable item.):

Applicability: This success criterion is only applicable to authoring tools that include selectable actions.

Technique A.2.2-1.1 [Sufficient]: Providing an access key utility that lists each selectable action (e.g., all of the controls in the menu system and button bars) and allows the author to select a keystroke for each action from a pool of available keystrokes.

Techniques for Success Criterion 2 (There must be at least one editing interface area in which selectable items can be activated by a single action (e.g., toolbar, palette), where both of the following are true: (a) the author can change the order of the items, and (b) the author can select which items are available from the set of all selectable items.):

Applicability: This success criterion is only applicable to authoring tools that include selectable actions.

Technique A.2.2-2.1 [Sufficient]: Providing a user-defined palette that is controlled by a customization utility that lists all of the control items available in the toolbars and menus and allows the author to specify which items to display on the palette and in which order.

Technique A.2.2-2.2 [Sufficient]: Providing a customization utility that controls all of the toolbars.

ATAG Checkpoint A.2.3 For the authoring tool user interface, allow authors to control time limits. [Priority 1] (Rationale | Note)

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

Techniques for Success Criterion 1 (If a time limit is not controlled by time-sensitive external constraints (e.g., actions of another author in a collaborative authoring system, external connection time-outs), then the time limit must meet at least one of the following: (a) the author is able to deactivate the time limit, (b) the author is able to adjust the time limit over a wide range that is at least ten times the length of the default setting, or (c) the author is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (e.g., "hit any key"), and the author is allowed to extend the time limit at least ten times.):

Applicability: This success criterion is only applicable to authoring tools that include time limits that are not controlled by time-sensitive external constraints (e.g., content is changed by the actions of another author in a collaborative authoring system or an external connection time-outs, preventing further authoring)

Technique A.2.3-1.1 [Sufficient]: Completely avoiding arbitrary time limits (i.e., limits that are not controlled by time-sensitive external constraints).

Technique A.2.3-1.2 [Sufficient for (a)]: Allowing the author to deactivate any time limit that is not controlled a time-sensitive external process.

Technique A.2.3-2.3 [Sufficient for (b)]: Ensuring that if a configuration setting is available for a time limit, then the highest setting is larger than or equal to 10 times the default interval.

Technique A.2.3-2.4 [Sufficient for (c)]: Warning the author at least 20 seconds before time expires and providing them with an option to extend the time limit with a simple action (e.g., "hit any key") by at least ten times the default interval.

Technique A.2.3-1.5 [Advisory]: Providing a single area in the options for setting any time limits.

Technique A.2.3-1.6 [Advisory]: Even if a 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 For the authoring tool user interface, allow authors to avoid flashing that could cause seizures due to photosensitivity. [Priority 1] (Rationale)

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

Techniques for Success Criterion 1 (If flashing occurs in any part of the user interface (e.g., within a WYSIWYG editing view) that violates international health and safety standards for general flash or red flash, then the author must be able to do at least one of the following: (a) the author is able to deactivate the flashing, or (b) the author is able to adjust the rate of flashing so that it no longer violates international health and safety standards for general flash or red flash.):

Applicability: This success criterion 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 for (a)]: If flashing begins, providing a single input action that stops the flashing immediately and for at least the rest of the session.

Technique A.2.4-1.2 [Sufficient for (b)]: If flashing begins, providing a single input action that stops the flashing immediately, but temporarily until the author adjusts the rate of flashing so that it no longer violates international health and safety standards for general flash or red flash.

Technique A.2.4-1.3 [Advisory]: Providing an option for disabling all flashing (or setting the allowed flashing parameters) in the preference settings and save these settings between sessions.

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

Technique A.2.4-1.5 [Advisory]: Completely avoiding the use of flashing in the editing interface.

ATAG Checkpoint A.2.5 For the authoring tool user interface, ensure that editing views enable the author to navigate the structure and perform structure-based edits. [Priority 2] (Rationale)

Techniques for Success Criterion 1 (If editing content that is a structured element set, the author must always be able to move the editing focus from any element to other elements in the set with any of the following relationships (if they exist): (a) the element immediately above (i.e., parent), (b) the first element immediately below (i.e., child), (c) the element immediately preceding at the same level (i.e., previous sibling), and (d) the element immediately following at the same level (i.e., next sibling).):

Applicability: This success criterion is applicable to authoring tools that support authoring of structured element sets (i.e., HTML documents by "code-level" or "WYSIWYG" editing views, but not necessarily by an "indirect" editing view).

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

Example: A.2.5-1.1: A code-level authoring tool in which a <tr> element has current focus and is therefore highlighted in the editing view. As well, breadcrumbs in the status bar trace the path from the root element to the current element, <html> <body> <table> <tr>. A pop-up menu from the selected element shows that keystrokes are available to move the selection focus to the parent element, <table>, of the current element, to the child elements, in this case two <td> elements and to the next and previous element pointed to by the same parent element (in this case to preceding and following <tr> elements). (Source: mockup by AUWG)

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 Criterion 2 (If editing content that is a structured element set, the author must be able to select any element in the set and perform editing functions (e.g., cut, copy, paste, presentation) on that element, its contents, and its sub-elements):

Applicability: This success criterion is applicable to authoring tools that support authoring of structured element sets (i.e., HTML documents by "code-level" or "WYSIWYG" editing views, but not necessarily by an "indirect" editing view).

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.

Example: A.2.5-2.1(a): When a <table> element is selected and the "delete" operation is performed, the entire table is deleted including sub-elements (<tr> and <td>) and any text content etc. within the table.

Example: A.2.5-2.1(b): When a <table> element is selected and the "strip element tags" operation is performed, the operation targets the <table> only, so this set of tags is removed, leaving sub-elements (<tr> and <td>) and any text content etc.

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

• "element, content and sub-elements": These functions target the entire selection. Examples of these functions include cut, copy, and delete.
• "element only": These functions only target the top level element of the selection, even if the effect cascades down to sub-element content when it is rendered. Examples of functions of this type include, "Emphasis" which should apply styling to the top level element (e.g., p) while not making any source changes to sub-elements (e.g., strong) (even though the content of sub-elements may be rendered differently) and “strip element tags” that deletes the markup of the top level element without affecting its sub-element.
• "content and sub-elements only": These functions target the content, including sub-elements of the top level element of the selection without having any affect on the markup of that top level element. An example of this might be a “Replace Contents” function:

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-General.1 [Advisory]: Providing other types of structure-based navigation, such as:

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

ATAG Checkpoint A.2.6 For the authoring tool user interface, allow the author to search content, including markup, within the editing views. [Priority 2] (Rationale)

For Web-based authoring tool user interface functionality: Web-based authoring tools may rely on the "find" function of the user agent to help perform the searches, as long as the applicable user agent(s) are specified in the conformance profile.

Techniques for Success Criterion 1 (The author must be able to perform text searches of all text that is editable by the author, including text alternatives for non-text objects and metadata.):

Applicability: This success criterion is applicable to virtually all authoring tools.

Technique A.2.6-1.1 [Sufficient]: Supporting searching for plain text sequences within the content (i.e., text between the open and close tags of an element, text in a content management database) and within text alternatives for non-text content (i.e., short text labels, long text descriptions, etc.) even when this textual information is actually encoded as part of the markup (e.g., as an attribute value).

Example: A.2.6-1.1: In a WYSIWYG editing view, searching for a particular text string yields all of the occurrences in the rendered text as well as all occurrences within alt-text of images, long descriptive text, and metadata values.

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

Applicability: This success criterion is only applicable to authoring tools that allow direct editing of 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.).

Example: A.2.6-2.1: In a code-level editing view, searching for the text string "able", yields <table> elements.

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

Example A.2.6-2.2: A search facility that makes effective use of structure. The facility is pictured with the author having chosen to find the "element" with the name "img", "with attribute" "height" "equal to" "100", where each value in quotation marks was editable. The replacement action is to "set attribute" "height" to "50". The following checkbox options are available "match case", "ignore whitespace" and "search text alternatives". The facility also includes the following buttons "Find Next", "Find all", "Replace", "Replace All", "Close" and "Help". (Source: mockup by AUWG)

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-General.1 [Advisory]: Providing more advanced search options, such as:

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

ATAG Checkpoint A.2.7 For the authoring tool user interface, provide an undo function. [Priority 2] (Rationale | Note)

For Web-based authoring tool user interface functionality: Web-based authoring tools may rely on the "undo" function of the user agent to perform the undo function for some editing actions that do not involve server communication (e.g., typing in a text area), as long as the applicable user agent(s) are specified in the conformance profile.

Techniques for Success Criterion 1 (Author actions that modify content must be either reversible by an "undo" function or include a warning to the author that the action is irreversible. An authoring tool may have certain committing actions (e.g., "save" function) that reset the undo history.):

Applicability: This success criterion is applicable to all authoring tools. Authoring tools are not expected to be able to undo actions related to shutting down the platform on which they run (e.g., shutting down an OS, closing a browser window, powering off a computer), although any measures taken to avoid losing authoring work in these circumstances are helpful.

Technique A.2.7-1.1 [Sufficient]: Ensuring that all actions that modify content (e.g., typing, adding an element, changing an attribute value, etc.) are reversible by means of an undo function or warn the author that the action is irreversible (e.g., closing without saving).

Example A.2.7-1.1: A content management system provides a text boxes for editing footnote text. When the author mistypes a word, the author invokes the user agent's undo function to reverse the error. The author selects the "OK" button to commit the footnote, but then immediately realizes that they have edited the wrong footnote. Instead of using the user agent's undo function, the author now chooses the authoring tool's "undo" function, which has kept a copy of the footnote's previous content and now restores it.

Techniques for Success Criterion 2 (The author must be able to perform consecutive undos up to at least five reversible actions or until an irreversible action or committing action is reached.):

Applicability: This success criterion is not applicable to authoring tools that have not met Success Criteria 1 for this checkpoint.

Technique A.2.7-2.1 [Sufficient]: Maintaining a queue of the five most 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 Criterion 3 (The author must be able to immediately reverse the most recent undos (i.e., a "redo" function).):

Applicability: This success criterion is not applicable to authoring tools that have not met Success Criteria 1 or 2 for this checkpoint.

Technique A.2.7-3.1 [Sufficient]: Including undo actions in the queue of the five most recent actions (see Technique A.2.7-2.1, above).

ATAG Checkpoint A.2.8 For the authoring tool user interface, allow the author to have multiple sets of keyboard operability and display preferences settings. [Priority 2] (Rationale)

Techniques for Success Criterion 1 (The author must be able to save and reload sets of preferences (e.g., personal profiles, personal settings), where each set contains preference settings related to the following (if present): (a) keyboard operability (unless keyboard operability preferences are controlled by the platform), (b) visual display (unless the visual display (e.g., fonts, sizes, colors, spacing, positioning) is controlled by the platform), and (c) audio display (unless the audio display (e.g., volume, speech voices) is controlled by the platform).):

Applicability: This success criterion is only applicable to authoring tools that provide preference settings for one or more of the following (as opposed to relying on the platform to provide them): (a) keyboard operability, (b) the visual display, or (c) for the auditory display.

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 (or any time during a session). Each set contains the configuration settings for (a) keyboard operability, (b) the visual display, (c) for the auditory display.

Example A.2.8-2.1(a): In a Web-based authoring tool, the author must log in. Once they do, they are presented with display/control preferences profiles that they have previously customized. The author can change their profile at any time.

Example: A.2.8-2.1(b): In a non-Web-based authoring tool running on a desktop platform, the author doesn't need to log in, but they are presented with the choice of loading any of the display/control preference profiles that users of that system have saved previously.

ATAG Checkpoint A.2.9 For the authoring tool user interface, ensure previews emulate the accessible rendering features of target user agents. [Priority 2] (Rationale | Note 1 | Note 2)

Techniques for Success Criterion 1 (If a preview feature is provided, then a mechanism of returning from the preview (i.e., moving focus back from, exiting from) must be provided that meets Checkpoint A.2.1 and is documented in the help system.):

Applicability: This success criterion is only applicable to authoring tools that include a preview function.

Technique A.2.9-1.1 [Sufficient]: Implementing the preview so that it launches a third-party user agent in a new window, which can easily be closed or minimized to return focus.

Techniques for Success Criterion 2 (If a preview is provided, then it must meet at least one of the following: (a) the preview makes use of an existing user agent (e.g., a third-party browser or browser component), or (b) the preview meets all of the checkpoints in Part A.):

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

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

Technique A.2.9-2.2 [Sufficient for (a)]: For Web-based authoring tools that are already running in a user agent, use that same user agent to perform be the preview.

Technique A.2.9-2.3 [Advisory for (a)]: Allowing the author to maintain a list of user agents to be used for previewing.

Technique A.2.9-2.4 [Advisory for (a)]: 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-2.5 [Advisory for (a)]: Bundling user agent installer files or providing a list of download sites for appropriate user agents.

Technique A.2.9-2.6 [Sufficient for (b)]: Ensuring that the entire preview (content view and the rest of the user interface) meets all of the requirements of Part A that might apply to a browser (i.e., not A.2.5, A.2.6, A.2.9, and A.3.2).

Technique A.2.9-2.7 [Advisory for (b)]: Providing conformance tests to show that the preview feature meets UAAG 1.0.

Guideline A.3: Authoring Interface must be Understandable

ATAG Checkpoint A.3.1 For the authoring tool user interface, observe the accessibility conventions of the platform. [Priority 2] (Rationale)

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

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

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

Technique A.3.1-1.1 [Sufficient]: Following platform specific conventions for focus and selection, such as:

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

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

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

Technique A.3.1-2.1 [Sufficient]: Following platform specific conventions when choosing keystrokes, such as:

• MacOS: "Mac OS X keyboard shortcuts" [MACOSX-KEYS]
• Windows: "Keyboard shortcuts for Windows" [MS-KEYS]
• Gnome/KDE: "Gnome/KDE Keyboard Shortcuts" [GNOME-KDE-KEYS]

ATAG Checkpoint A.3.2 For the authoring tool user interface, maintain consistency. [Priority 2] (Rationale)

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.

Techniques for Success Criterion 1 (Editing interface controls that are identified by the same text label or icon must always perform the same function.):

Applicability: This success criterion 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 Criterion 2 (When the same function (e.g., saving, running a checker or canceling an action) is available in multiple places within the editing interface (e.g., on multiple windows), at least one method of controlling the function must be available in each place using the same text label or icon.):

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

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

Example: A.3.2-2.1: In an authoring tool, the "copy" function is available in several places in the editing interface: from the main menu bar, from the toolbars and as an item in a context sensitive pop-menu that the author can activate within the editing views. In the case of the main menu bar and the pop-up menu, the "copy" item appears exactly the same in both - having the word "copy" and a "copy" icon. The same "copy" icon is also used for the toolbar.

ATAG Checkpoint A.3.3 For the authoring tool user interface, document the user interface including all accessibility features. [Priority 1] (Rationale)

Techniques for Success Criterion 1 (At least one version of the documentation must conform to the minimum requirements (e.g., "Level A") of WCAG, although it does not necessarily need to be located on-line.):

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

Technique A.3.3-1.1 [Sufficient]: Providing a complete version of the documentation (e.g., on-line, on the installation media) as Web content that conforms to WCAG 2.0 Level A.

Techniques for Success Criterion 2 (All features from Part A that benefit the accessibility of the editing interface must be documented (e.g., keyboard shortcuts).):

Applicability: This success criterion 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.

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-General.1 [Advisory]: Providing additional forms of help, including context sensitive help.

Technique A.3.3-General.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 For the authoring tool user interface, support interoperability with assistive technologies. [Priority 1] (Rationale)

For Web-based authoring tool user interface functionality: Web-based authoring tools will rely on the accessibility platform architecture support of the user agent and therefore meeting Checkpoint A.0.1 will serve to meet this checkpoint.

Techniques for Success Criterion 1 (The authoring tool must implement the accessibility platform architecture(s) relevant to the development platform (e.g., MSAA for Windows applications, Java Access for Java applications).):

Applicability: This success criterion is applicable to all non-Web-based authoring tools.

Technique A.4.1-1.1 [Sufficient]: Implementing the relevant accessibility platform architecture(s), such as:

• Gnome Accessibility: Gnome Accessibility Toolkit API [GNOME-API]
• Eclipse Accessibility: Eclipse Platform API [ECLIPSE-API]
• Java Swing: Java Accessibility Package [JAVA-API]
• MacOS X Accessibility:
  • "Introduction to Accessibility Programming Guidelines for Carbon" [CARBON-ACCESS]
  • "Introduction to Accessibility Programming Guidelines for Cocoa" [COCOA-ACCESS]
• Microsoft Windows Active Accessibility: Microsoft Active Accessibility [MSAA-API]

Techniques for Success Criterion 2 (All of the following information must be published about the implementation of the accessibility platform architecture(s): (a) Specify if only the default support is provided. (b) Otherwise, provide information (e.g., accessible name, accessible description, accessible role) for each GUI component that can receive focus, as defined by the accessibility architecture used. (c) Detail any deviation from their proper use (i.e., lack of use, incomplete use, inappropriate use) as defined by the documentation for the accessibility platform architecture.):

Applicability: This success criterion is applicable to all non-Web-based authoring tools

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

Techniques for Success Criterion 3 (If there is any authoring tool user interface functionality that is not supported by the relevant accessibility platform architecture(s), then at least one of the following must be done: (a) provide an accessible equivalent for the functionality that is supported by the relevant accessibility platform architecture(s). (b) provide an alternative interoperability mechanism with published documentation so that the functionality would be available to an assistive technology implementing the mechanism. (c) describe the inaccessible functionality in the conformance claim):

Applicability: This success criterion is only applicable to authoring tools that include functionality that is not supported by the relevant accessibility platform architecture(s).

Technique A.4.1-3.1 [Sufficient for (a)]: Providing equivalent functionality that is supported by the relevant accessibility platform architecture(s).

Technique A.4.1-3.2 [Sufficient for (b)]: Extend an existing API, if the API is extensible or the source is available.

Technique A.4.1-3.3 [Sufficient for (b)]: Create a new API.

Technique A.4.1-3.4 [Advisory for (b)]: 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]

Technique A.4.1-3.5 [Sufficient for (c)]: Describe the functionality in the conformance claim and see Checkpoint A.4.2, below, for more information.

ATAG Checkpoint A.4.2 For the authoring tool user interface, support interoperability with assistive technologies. [Priority 3] (Rationale)

For Web-based authoring tool user interface functionality: Web-based authoring tools will rely on the accessibility platform architecture support of the user agent and therefore meeting Checkpoint A.0.1 will serve to meet this checkpoint.

Techniques for Success Criterion 1 (Additional information must be published describing the nature and use of the information provided in Checkpoint A.4.1 (e.g., that the long description is different from the associated tool tip).):

Applicability: This success criterion is applicable to all non-Web-based authoring tools.

Technique A.4.2-1.1 [Sufficient]: For each focusable user interface component described under criterion 2 of A.4.1 describe how the respective information provided by the component through the platform accessibility architecture differs from the corresponding information provided by the component itself (e.g., if a button component provides different accessible name text than it uses as displayed text (or if the button only displays an image)) and why the difference exists.

[Contents] [Part A] [Part B] [References]