Contents | Part A | Part B | References
Copyright © 1994-2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.
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:
- ensuring compatibility with assistive technology,
- supporting keyboard input,
- supporting software control of pointing devices,
- properly displaying fonts,
- ensuring customizable displays,
- properly using color,
- supporting audio output,
- proper handling of errors and user notification,
- providing on-line documentation and help,
- ensuring customization of user preferences,
- ensuring proper window appearance and behavior,
- proper handling of keyboard input focus.
Technique A-0.2[Advisory]: Following other guidelines and best practice documents for specific technologies where they are relevant. These include:
- Platform Specific:
- Eclipse: "Designing Accessible Plug-ins in Eclipse" [ECLIPSE-ACCESS], T. Creasey, IBM OTI Labs.
- Gnome: "GNOME Accessibility for Developers" [GNOME-ACCESS], C. Benson, B. Cameron, B.Haneman, S. Snider, P. O'Briain, The GNOME Accessibility Project.
- Java:
- "IBM Guidelines for Writing Accessible Applications Using 100% Pure Java" [JAVA-ACCESS], R. Schwerdtfeger, IBM Special Needs Systems.
- "Java accessibility guidelines and checklist" [JAVA-CHECKLIST], IBM.
- Lotus Notes: "Lotus Notes accessibility guidelines" [NOTES-ACCESS], IBM.
- MacOS: "Accessibility Documentation" [APPLE-ACCESS], Apple Computer Inc.
- Microsoft Windows:
- "Accessibility for applications designers" [MS-ENABLE], Microsoft Corporation.
- "The Microsoft Windows Guidelines for Accessible Software Design" [MS-SOFTWARE], Microsoft Corporation.
- General:
- "Application Software Design Guidelines" [TRACE-REF] compiled by G. Vanderheiden, TRACE Center. A thorough reference work.
- "Designing for Accessibility" [SUN-DESIGN] E. Bergman and E. Johnson. This paper discusses specific disabilities including those related to hearing, vision, and cognitive function.
- "[Electronic Information Technology Access Advisory Committee] EITAAC Desktop Software standards" [EITAAC], this outline was compiled by J. Fruchterman, TRACE Centre .
- "Making Educational Software and Web Sites Accessible" [EDU-SOFT-ACCESS] G. Freed, M. Rothberg and T. Wlodkowski, National Center for Accessible Media (NCAM). This document provides additional information for math and science software. 2003.
- "Software Accessibility" [IBM-ACCESS] IBM. A concise checklist.
- "Towards Accessible Human-Computer Interaction" [SUN-HCI] E. Bergman, E. Johnson, Sun Microsystems 1995.
- "User Agent Accessibility Guidelines 1.0" [UAAG10] I. Jacobs, J. Gunderson, E. Hansen, eds. W3C. Accessibility guidelines that cover browsers and other user agents.
- "Web Content Accessibility Guidelines 1.0" [WCAG10] W. Chisholm, G. Vanderheiden, I. Jacobs, eds. W3C.
- "What is Accessible Software" [WHAT-IS] J. W. Thatcher, Ph.D., IBM, 1997. This paper gives a short example-based introduction to the difference between software that is accessible, and software that can be used by some assistive technologies.
Technique A-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.
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@@
![]()
![]()
![]()
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.
![]()
![]()
![]()
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.
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Applicability: This success criteria is not applicable if the authoring tool lacks any non-text objects within the user interface (rendering non-text objects in the content does not apply here).
Technique A.1.1-1.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.
![]()
![]()
![]()
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.
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).
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).
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.
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.
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Applicability: This success criteria is not applicable if the authoring tool 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).
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).
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Applicability: This success criteria is not applicable if the authoring tool relies on the visual display settings of the platform and supports the full setting range of the platform.
Technique A.1.3-1.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)
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)
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.
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.@@
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.@@
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.@@
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.@@
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.
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.
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)
![]()
Description:
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.
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.
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.).
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:
- 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-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.
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.
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.
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Applicability: This success criteria is not applicable to authoring tools that lack interface time limits.
Technique A.2.3-1.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.
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.
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.).
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Applicability: This success criteria is not applicable to authoring tools that lack flashing user interface controls and do not render objects in the editing view in a way that will cause flashing.
Technique A.2.4-1.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.
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.
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).
![]()
![]()
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.
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:
- "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:
![]()
Example 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.
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:
- 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).
For Web-Based Interface Components: Web-based authoring tools may make use of the find function of the browsers to help perform the searches.
Applicability: This success criteria is not applicable to authoring tools that prevent the author from to editing content.
Technique A.2.6-1.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).
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.
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:
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:
- text search options such as replacement, case (in)sensitivity, wildcard characters, whole word matching, search repetition, and highlighting of all occurrences.
- option to search the content only, the markup only, or both.
- use metadata (per WCAG 2.0 [WCAG20]) to assist searching of large collections, or of timed presentations. (Refer also to the paper "A Comparison of Schemas for Dublin Core-based Video Metadata Representation" [SEARCHABLE] for discussion specifically addressing timed multimedia presentations)
- for tools that manage a database or multiple files, provide a search function that can search through the different pieces of content at once.
- allow the author to select an area by similarity to the search probe (e.g. closeness of color in an image editor, etc.)
For Web-Based Interface Components: Web-based authoring tools may rely on the undo function of the browser to perform the undo function for editing actions that do not involve server communication (e.g. typing in a text area). Therefore, all Web-based interface components, that meet Checkpoint A.0.1 will serve to meet this checkpoint as long as the user agent(s) specified in the conformance profile have the ability to perform at least one level of text entry undo.
Applicability: This success criteria is applicable to all authoring tools (except see note on Web-Based tools above).
Technique A.2.7-1.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).
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.
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.
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.
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.
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.
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Applicability: This success criteria is applicable to all authoring tools.
Technique A.3.1-1.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.
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:
- MacOS: "Mac OS X keyboard shortcuts" [MACOSX-KEYS]
- Windows: "Keyboard shortcuts for Windows" [MS-KEYS]
- Gnome/KDE: "Gnome/KDE Keyboard Shortcuts" [GNOME-KDE-KEYS]
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Applicability: This success criteria is applicable to all authoring tools.
Technique A.3.2-1.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.
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.
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.
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.
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.
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.
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.
For Web-Based Interface Components: Meeting Checkpoint A.0.1 will serve to meet this checkpoint.
Applicability: This success criteria is applicable to all authoring tools.
Technique A.4.1-1.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]
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