PART A:
Make the authoring tool user interface accessible
- Scope of Authoring Tool User Interface: The Part
A success criteria apply to all aspects of the authoring tool user interface that are under the control of the authoring tool developer. This includes views of the web content being edited, and features that are independent of the web content being edited, such as menus, button bars, status bars, user preferences, documentation, etc.
- Reflected Content Accessibility Problems: The authoring tool is responsible for ensuring that editing views display the web content being edited in a way that is accessible to authors with disabilities (e.g., ensuring that an image label in the web content can be programmatically determined). However, where an authoring tool user interface accessibility problem is caused directly by a web content accessibility problem in the web content being edited (e.g., if an image in the content lacks a label), then this would not be considered a deficiency in the accessibility of the authoring tool user interface.
- User Agent Features: Web-based authoring tools may rely on user
agent features (e.g., keyboard navigation, find functions, display preferences, undo features, etc.) to satisfy success criteria as long as the user
agent is listed in the conformance
claim.
- Applies to Features for Part B: The Part
A success criteria apply to the entire authoring tool user interface, including any of the features (e.g., checking tool , tutorials) added to meet
the Part B success criteria.
- Previews: Preview features
are exempt from having to meet the other requirements in Part A, if they meet Guideline A.3.7. Previews are treated differently than editing views because authors, including those with disabilities, are not well-served
if preview features diverge too much from the actual functionality of user
agents.
PRINCIPLE
A.1: Authoring tool user interfaces must follow applicable accessibility guidelines
Guideline A.1.1
[For the authoring tool user interface] Ensure that web-based functionality is accessible.
[Return to Guideline]
Rationale: When authoring tools or parts of authoring tools (e.g., an online help system) are web-based, conforming to WCAG 2.0 will facilitate access by all authors, including those using assistive
technologies.
A.1.1.1 Web-Based Accessible (Level A): Web-based authoring tool user interfaces conform to WCAG 2.0 Level A. (Level A)
- Intent of the Success Criterion A.1.1.1:
The intent of this success criterion is to ensure that web-based authoring tool user interfaces are accessible to authors with disabilities. Since WCAG 2.0 already provides requirements for the accessibility of web content, including web applications, that document is referenced to avoid replication of requirements.
- Examples that meet the Success Criterion:
- Web-based authoring tool:
A web-based wiki application is designed to conform to WCAG 2.0 Level A. During development, the user interface (including test content being authored) is tested by the developer using an accessibility evaluation harness for web applications. Periodically, the application is also tested by authors using assistive
technologies.
- Web-based help system:
A non-web-based authoring tool makes use of a web-based help system. Each page in the help system is based on a template that was designed to conform to WCAG 2.0 Level A (when used) and the developer ensures that each help page passes an accessibility checker before being published. The developer confirms the accessibility of the final help system by spot-checking sample pages.
- Related Resources:
Guideline A.1.2
[For the authoring tool user interface] Ensure that non-web-based functionality is accessible. [Return to Guideline]
Rationale: When authoring tools or parts of authoring tools are non-web-based (e.g., a client-side file uploader for a web-based content management system), following existing accessibility standards and/or platform conventions that support accessibility will facilitate access by all authors, including those using assistive technologies.
A.1.2.1 Non-Web-Based Accessible: Non-web-based authoring tool user interfaces follow (and cite in the conformance claim) accessibility standards and/or platform conventions that support accessibility. (Level A)
- Intent of the Success Criterion A.1.2.1:
The intent of this success criterion is to ensure that non-web-based authoring tool user interfaces are accessible to authors with disabilities. Since accessibility standards and platform conventions exist for many platforms, those documents are referenced to avoid replication of requirements.
- Examples that meet the Success Criterion:
- WYSIWYG on MacOS
@@JS
- Content Management System on Windows
@@JS
- Document Sharing System in Lotus Notes
@@JS
- Debugger in Java
@@JS
- Related Resources:
@@JS look for other newer resources@@
- The following is a non-exhaustive list of accessibility guidelines and best practice documents for various platforms:
- Eclipse: "Designing Accessible Plug-ins in Eclipse" [ECLIPSE-ACCESS]
- Gnome/KDE:
- Java:
- "IBM Guidelines for Writing Accessible Applications Using 100% Pure Java" [JAVA-ACCESS]
- "Java accessibility guidelines and checklist" [JAVA-CHECKLIST]
- Lotus Notes: "Lotus Notes accessibility guidelines" [NOTES-ACCESS]
- Mac OS: "Accessibility Documentation" [APPLE-ACCESS]
- "Mac OS X keyboard shortcuts" [MACOSX-KEYS]
- Microsoft Windows:
- General Guides:
- "Application Software Design Guidelines" [TRACE-REF]
- "Ergonomics of human-system interaction -- Guidance on accessibility for human-computer
interfaces" ISO standard [ISO-TS-16071]
- "Designing for Accessibility" [SUN-DESIGN]
- "[Electronic Information Technology Access Advisory Committee] EITAAC Desktop Software standards" [EITAAC]
- "Making Educational Software and Web Sites Accessible" [EDU-SOFT-ACCESS]
- "Software Accessibility" [IBM-ACCESS]
- "What is Accessible Software" [WHAT-IS]
PRINCIPLE
A.2: Editing views must be perceivable
Guideline A.2.1
[For the authoring tool user interface] Make alternative content available to the author.
[Return to Guideline]
Rationale: Some authors require access to alternative content in order to interact with the web content that they are authoring.
Guideline A.2.2
[For the authoring tool user interface] Editing view presentation can be programmatically determined.
[Return to Guideline]
Rationale: Some authors need access to the editing view presentation because this may be used to convey both status information added by the authoring tool (e.g., underlining misspelled words) and, within content renderings, information about the end user experience of the web content being edited.
A.2.2.1 Purpose of Added Presentation: If an editing view modifies the presentation of web content to provide additional information, then that additional information can be programmatically determined. (Level A)
- Intent of the Success Criterion A.2.2.1:
The intent of this success criterion is to ensure that authors with disabilities have the same access to any information conveyed by the authoring tool using editing view presentation as other authors.
- Examples that meet the Success Criterion:
- Change tracking feature:
A change tracking feature displays inserted text in green and deleted text in red with a strike-through. Instead of implementing this using simple CSS selectors, the XHTML elements ins and del are used, since these have semantic meaning.
- Related Resources:
A.2.2.2 Access to Text Presentation (Minimum): If an editing view (e.g., WYSIWYG view) renders any of the following presentation properties for text, then the properties can be programmatically determined: (Level A)
- (a) Text font; and
- (b) Text style (e.g., italic, bold); and
- (c) Text color; and
- (d) Text size.
- Intent of the Success Criterion A.2.2.2:
The intent of this success criterion is to ensure that authors with disabilities have access to text presentation information that is available to other authors because even authors that cannot see need to understand how their web content will appear to end users.
- Examples that meet the Success Criterion:
- Related Resources:
Guideline A.2.3: Ensure the independence of the authors' display preferences.
Rationale: Some authors need to set their own display settings in a way that differs from the presentation that they want to define for the published web content.
PRINCIPLE A.3: Editing views must be operable
Guideline A.3.1
[For the authoring tool user interface] Enhance keyboard access to authoring features. [Return to Guideline]
Rationale: Some authors with
limited mobility or visual disabilities are not able to use a mouse, and instead require full keyboard access.
A.3.1.1 Keyboard: All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the author's movement and not just the endpoints. (Level A)
Note 1: The movement path exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input, but the underlying function (text input) does not.
Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
- Intent of the Success Criterion A.3.1.1:
The intent of this success criterion is to ensure that, wherever possible, authoring tools can be operated through a keyboard or keyboard interface (so an alternate keyboard can be used). Examples of "specific timings for individual keystrokes" include situations where authors would be required to repeat or execute multiple keystrokes within a short period of time or where a key must be held down for an extended period before the keystroke is registered. The phrase "except where the underlying function requires input that depends on the path of the author's movement and not just the endpoints" is included to separate those things that cannot reasonably be controlled from a keyboard.
- Examples that meet the Success Criterion:
- Drag-and-drop feature:
An authoring tool that includes a drag-and-drop feature for adding widgets to web content also includes allows the same widgets to be added from a menu that can be operated with the keyboard.
- Drawing feature:
An authoring tool has a drawing feature that enables authors to create, size, position and rotate drawing objects from the keyboard.
- Related Resources:
A.3.1.2 Avoiding Content Keyboard Traps: The authoring tool prevents keyboard traps as follows: (Level A)
- (a) In the authoring tool user interface: If keyboard focus can be moved to a component using the keyboard, then focus can be moved away from that component using standard keyboard navigation commands (e.g., TAB key); and
- (b) In editing views that render content: If an editing view (e.g., WYSIWYG view) renders web content, then a documented keyboard command is provided that will always restore keyboard focus to a known location (e.g., the menus).
- Intent of the Success Criterion A.3.1.2:
The intent of this success criterion is to ensure that neither the authoring tool's own user interface nor any rendered web content within editing views "traps" keyboard focus. This is a common problem when an interactive object is embedded in the web content. The user might be able to move focus to the object (e.g., by "tab" key), but is then unable to move the focus out using the keyboard because keyboard control has passed to the embedded application.
- Examples that meet the Success Criterion:
- Related Resources:
A.3.1.3 Keyboard Shortcuts: The authoring tool provides keyboard shortcuts. (Level AA)
- Intent of the Success Criterion A.3.1.3:
The intent of this success criterion is to ensure that authors using a keyboard interface can more easily access commonly used functions of the authoring tool in a manner that is appropriate to the operating environment (i.e., desktop systems generally have more keystrokes available to be assigned as shortcuts than mobile devices).
- Examples that meet the Success Criterion:
- Non-web-based authoring tool:
An authoring tool provides keyboard shortcuts for menu of its menu functions as well as access keys in the design of its menus and dialog boxes. The choice of shortcut keys follows platform conventions.
- Social networking application on a mobile device:
A social networking application on a mobile device has only a very few keyboard shortcuts available on its targeted devices. These few keyboard shortcuts are used for the most commonly accessed functions of the application (e.g., home, list of friends).
- Related Resources:
- The following is a non-exhaustive list of keyboard shortcut conventions for various platforms:
@@JS to complete
A.3.1.4 Customize Keyboard Access: The author(s) can customize keyboard access to the authoring tool. (Level AAA)
- Intent of the Success Criterion A.3.1.4:
The intent of this success criterion is to ensure that authors using a keyboard interface have the ability to remap the authoring tool's keyboard shortcuts in order to avoid keystroke conflicts, use familiar keystroke combinations and optimize keyboard layout (e.g., for one handed use).
- Examples that meet the Success Criterion:
- Non-web-based authoring tool:
An authoring tool has a keyboard setup utility that lists all of the available keyboard shortcuts and allows authors to associate each with any of the authoring tool's commands (e.g., all of the menu commands).
- Web-based content management system:
A content management system has a keyboard setup utility that allows authors to change the access keys that are available during authoring. These access key rebindings are for the authors' use only and do not affect the web content being edited.
- Social networking application on a mobile device:
A social networking application has a keyboard setup utility that allows authors to change their keyboard shortcuts for the site. The remapping is saved in site cookies.
- Related Resources:
Guideline A.3.2
[For the authoring tool user interface] Provide authors with enough time.
[Return to Guideline]
Rationale: Some authors who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits or requiring a fast reaction speed, such as clicking on a moving target.
A.3.2.1 Data Saved: If the authoring tool ends an authoring session due to a time limit (e.g., an authenticated session expires), then the author(s) have the global option to ensure that the web content being edited is saved. (Level A)
Note: For web-based authoring tools, this applies to any web content that has already been submitted to the server by the user agent.
- Intent of the Success Criterion A.3.2.1:
The intent of this success criterion is to ensure that the work an author has produced is saved in the event that an authoring session is ended due to a time limit. This is especially important for some authors with disabilities who may take longer to accomplish tasks.
- Examples that meet the Success Criterion:
- Web-based content management system:
A content management system has a login timeout function that automatically logs authors out after 20 minutes of inactivity. The authors' work is automatically saved before they are logged out for inactivity and a numerically incremented file name is used in order to avoid overwriting authors' previously saved versions.
- Wiki:
A wiki has an auto-save feature that can be turned on by authors. The auto-save feature always saves before a login timeout.
- Related Resources:
A.3.2.2 Timing Adjustable: For each time limit that is set by the authoring tool, at least one of the following is true: (Level A)
- (a) Turn off: The author(s) are allowed to turn off the time limit before encountering it; or
- (b) Adjust: The author(s) are allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
- (c) Extend: The author(s) are warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the author(s) are allowed to extend the time limit at least ten times; or
- (d) Real-time Exception: The time limit is a required part of a real-time event (e.g., a collaborative authoring system), and no alternative to the time limit is possible; or
- (e) Essential Exception: The time limit is essential and extending it would invalidate the activity; or
- (f) 20 Hour Exception: The time limit is longer than 20 hours.
- Intent of the Success Criterion A.3.2.2:
The intent of this success criterion is to ensure that authoring tools provide authors with disabilities adequate time to perform their tasks. Any process that happens without author initiation after a set time or on a periodic basis is a time limit. This includes partial or full updates of the screen (for example, page refresh), or the expiration of a window of opportunity for an author to react to a request for input. It also includes user interface functionality that is advancing or updating at a rate beyond the author's ability to read and/or understand it. In other words, animated, moving or scrolling information introduces a time limit. Generally, turning off time limits is better than customizing the length of time limits, which is better than requesting more time before a time limit occurs. In some cases, however, it is not possible to change the time limit (e.g., a collaborative authoring session) and exceptions are therefore provided for those cases.
- Examples that meet the Success Criterion:
- Web-based content management system:
A content management system has a login timeout function that automatically logs authors out after 20 minutes of inactivity. One minute before the automatic log out, the system notifies authors that the log out will occur unless they cancel the notification (meeting (c)). The system also includes a preference setting that lets authors set the timing of the notification up to 10 minutes before the automatic logout (meeting (b)).
- Real-time collaborative editing system:
A collaborative editing system allows multiple authors to edit the same web content document simultaneously. An integral part of the real-time collaborative activity is that any author may edit or delete what others have just authored (meeting (d)).
- Related Resources:
A.3.2.3 Moving Targets: If a user interface component is moving (e.g., animated vector graphic), then the author(s) have the option to stop the movement.
(Level A)
- Intent of the Success Criterion A.3.2.3:
The intent of this Success Criterion is to ensure that authors are not prevented from using the authoring tool by a requirement for fast reactions.
- Examples that meet the Success Criterion:
- Timeline-based authoring tool:
A timeline-based interactive web content editor has an indicator of the current position on the timeline that authors can click and drag. When the interactive web content is being previewed, the indicator moves along the timeline which can make it difficult to target with the mouse. In this case, authors can stop the indicator from moving with the "Stop" button.
- Related Resources:
Guideline A.3.3
[For the authoring tool user interface] Help authors avoid flashing that could cause seizures.[Return to Guideline]
Rationale: Flashing
can cause seizures in authors with photosensitive seizure disorder.
A.3.3.1 Static View Option: If an editing view renders time-based content (e.g., animations), the author(s) have the global option of rendering only the initial state of time-based web content. (Level A)
- Intent of the Success Criterion A.3.3.1:
The intent of this success criterion is to ensure that authors with photosensitive seizure disorder can use the authoring tool to open time-based web content without risk.
- Examples that meet the Success Criterion:
- Blog:
A blogging tool allows authors to import of video files. Authors have the option to turn off an auto-play feature so that the video files are not played until a "Play" button is activated.
- WYSIWYG web page editor:
A WYSIWYG editing view is capable of rendering Javascript in real time. Authors have the option to turn off the real time rendering feature, so that the Javascript is not rendered until a "Play" button is activated.
- Related Resources:
Guideline A.3.4
[For the authoring tool user interface] Enhance navigation and editing via content structure. [Return to Guideline]
Rationale: Some authors who have difficulty typing or operating the mouse benefit when authoring tools make use of the structure present in web content to simplify the tasks of navigation and editing the content.
A.3.4.1 Edit by Structure: If an editing
view displays a structured
element set, then the author(s) can select
any element in
the structured
element set and perform editing functions (e.g., cut, copy, paste, presentation)
on that element, its contents, and its sub-elements.
(Level A)
- Intent of the Success Criterion A.3.4.1:
The intent of this success criterion is to ensure that authors can make use of the structure that may be present in the web content that they are editing to read and edit that web content. This is particularly important when authors are editing large amounts of text.
- Examples that meet the Success Criterion:
- WYSIWYG web page editor:
A WYSIWYG editing view allows authors to select and manipulate elements. When an element is selected, any content, including sub-elements, of the element are also selected. When authors perform a function on their selections, the scope of the function and the resulting outcome depends on the nature of the function.
- Some functions target the entire selection (i.e., element, content and sub-elements). For example, 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.
- Some functions that only target the top level element of the selection (i.e., element). For example, "strip element tags" deletes the markup of the top level element without affecting its sub-elements or content.
- Some functions only 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. For example, “replace contents” is a variant of "paste" in which the sub-elements and content of the selected element are replaced.
- Related Resources:
A.3.4.2 Navigate By Element Type: If an editing
view displays a structured
element set, then the author(s) can move the editing focus forward or backward to the next instance of the same element. (Level AA)
- Intent of the Success Criterion A.3.4.2:
The intent of this Success Criterion is to ensure that authors using a keyboard interface can navigate effectively within structured web content.
- Examples that meet the Success Criterion:
- Search by element:
An authoring tool includes a search function mode that enables authors to search forwards or backwards by the names of elements. When a searched-for element exists, it is selected in the editing view, enabling authors to immediately edit the element. In addition, the search can be customized to search by attributes, etc.
Figure: A "Find and Replace" dialog box is shown configured to find the "element" with the name "img", "with attribute" "height" "equal to" "100", where each value in quotation marks is editable. The replacement action is to "set attribute" "height" to "50". The following checkbox options are available "match case", "ignore white space" and "search text alternatives". The dialog box also includes the following buttons "Find Next", "Find all", "Replace", "Replace All", "Close" and "Help". (Source: mockup by AUWG)
- Related Resources:
A.3.4.3 Navigate By Headings: If an editing
view displays a structured
element set, then the author(s) can move the editing focus to the heading before or the heading after the element. (Level AA)
- Intent of the Success Criterion A.3.4.3:
The intent of this success criterion is to ensure that authors using a keyboard interface can navigate effectively within web content that is structured using multiple levels of headings.
- Examples that meet the Success Criterion:
- Search by any header element:
An authoring tool includes a search function mode that enables authors to search forwards or backwards by "any header element". For example, in HTML4 this would be h1, h2, h3, h4, h5, and h6. When a searched-for header element exists, it is selected in the editing view, enabling authors to immediately edit the element.
- Related Resources:
A.3.4.4 Navigate Tree Structures: If an editing
view displays a structured
element set, then the author(s) can move
the editing focus from any element to
the following other elements in the structured
element set (if they exist): (Level AA)
- (a) Parent: The element immediately
above; and
- (b) Child: The first element immediately
below; and
- (c) Previous Sibling: The element immediately
preceding at the same level; and
- (d) Next Sibling: The element immediately
following at the same level.
- Intent of the Success Criterion A.3.4.4:
The intent of this success criterion is to ensure that authors using a keyboard interface can use the structure that is inherent in certain types of web content to increase efficiency of their navigation. For example, when working with a table, the length and complexity of the table markup can become a barrier to simple keyboard navigation (e.g., navigating through the markup code using only the arrow keys). Instead, navigation is greatly improved if the relationships in the markup can be leveraged, as when authors can move focus from the last row element in a table up to the table element with a single keyboard command.
- Examples that meet the Success Criterion:
- Source content editing view:
A source content editing view supports authors by providing the ability to use keyboard shortcuts to move the focus from any element (e.g., table row) to:
- the element that contains it (e.g., table),
- to the first sub-element that it contains (e.g., table data cell),
- to the element immediately preceding it as a sub-element of the same parent element (e.g., previous table row),
- and to the element immediately following it as a sub-element of the same parent element (e.g., next table row).
- Customizing widgets:
An authoring tool enables authors to add and customize javascript widgets in its WYSIWYG editing
view. Authors can use the keyboard to navigate through the elements that make up the widget to set the properties or appearance of the widget. For example, in a slider widget, the keyboard can be used to select the background, the line, the line ticks or the thumb marker of the slider.
- Outline view:
An "outline"
or "structure" editing view is provided that organizes structured
element sets being edited into a document tree. In this editing
view, only the arrow keys are required for navigation between the parent, child and sibling elements.
- Related Resources:
Guideline
A.3.5 [For the authoring tool user interface] Provide
text search of the content. [Return to Guideline]
Rationale: Some authors who have difficulty typing or operating the mouse benefit from the ability to navigate to arbitrary points within the web content being authored.
A.3.5.1 Text Search: The author(s) can perform text searches of web content in which all of the following are true: (Level AA)
- (a) Search All Editable: The search can be within any information that is text and that the authoring tool can modify (e.g., text content, text alternatives for non-text content, metadata, markup elements and attributes, etc.); and
Note: If the current editing view is not able to display the results of a search then the authoring tool may switch to a different editing view to display the results (e.g., to a source content editing view to display search results within markup tags).
- (b) Bi-Directional: The search can be made forwards or backwards; and [UAAG 2.0]
- (c) Case Sensitive: The search can be in both case sensitive and case insensitive modes [UAAG 2.0]
- Intent of the Success Criterion A.3.5.1:
The intent of this success criterion is to ensure that authors can efficiently find the web content they wish to edit.
- Examples that meet the Success Criterion:
- Basic text search:
An authoring tool provides a WYSIWYG editing view as well as a properties pane for certain object properties (e.g., the color of text, alternative text labels for images, etc.). The authoring tool provides bi-directional, case sensitive searching for plain text sequences within the rendered web content and within the object property values. Search results within the object property values are displayed by selecting the object in the WYSIWYG editing view and putting focus on the appropriate value in the property pane.
- Advanced text search:
An authoring tool's basic text search feature is augmented by more advanced search options, such as:
- replacement,
- wildcard characters,
- whole word matching,
- search repetition, and
- highlighting of all occurrences.
- Metadata editor:
A metadata editor provides
bi-directional, case sensitive searching for plain text sequences within textual metadata fields (e.g., title, description, author, etc.).
- Related Resources:
Guideline A.3.6
[For the authoring tool user interface] Manage preference settings. [Return to Guideline]
Rationale: Providing the ability to save and reload sets of keyboard and
display preference settings benefits authors who have needs that differ
over time (e.g., due to fatigue).
A.3.6.1 Save Settings: Preference settings are stored for any of the following that the authoring tool controls
(i.e., not controlled by the platform): (Level AA)
- Intent of the Success Criterion A.3.6.1:
The intent of this success criterion is to ensure that authors' preference settings for keyboard and display settings do not need to be reset for each authoring session.
- Examples that meet the Success Criterion:
- Related Resources:
A.3.6.2 Multiple Sets: Choosing between multiple sets of
preferences (e.g., personal profiles, personal settings) are supported for any of the following that the
authoring tool controls (i.e., not controlled by the platform): (Level AAA)
- Intent of the Success Criterion A.3.6.2:
The intent of this success criterion is to ensure that authors whose personal preferences vary over time (e.g., due to fatigue) can easily select from a series of pre-set preferences for keyboard and display settings.
- Examples that meet the Success Criterion:
- Basic multiple profiles:
An authoring tool allows the various configurations of preference settings to be stored as different profiles that authors can switch between at any time. The stored preference settings include all keyboard and display settings that are specific to the authoring tool (i.e., are not controlled by the platform).
- Portable profiles:
An authoring tool's basic multiple profiles feature is augmented by the ability for authors to save the profiles as separate files. This allows authors to move configurations between instances of the authoring tool on different systems or to share the configuration files with other authors with similar requirements.
- Related Resources:
A.3.6.3 Options Assistance: The authoring tool includes a mechanism to help the author(s) configure options related to Part A.
(Level AAA)
- Intent of the Success Criterion:
The intent of this success criterion is to ensure that authoring tools provides assistance to authors in configuring any options related to the accessibility of the user interface. This assistance will be should include extra assistance resolving any incompatibilities between options (e.g., prevent the same color being used for the foreground and background).
- Examples that meet the Success Criterion:
- Options setting wizard:
An authoring tool includes a wizard that takes authors step-by-step through the accessibility options, providing explanations and previews of how the options will change the display. The wizard follows an interview format, first asking authors about
general areas (e.g., seeing the screen, using the keyboard) and then becoming more detailed (e.g., text size, text color, etc.).
- Related Resources:
Guideline A.3.7
[For the authoring tool user interface] Ensure that previews are
as accessible as existing user
agents. [Return to Guideline]
Rationale: Preview features
are provided in many authoring tools because the workflow of authors often includes periodically checking how user
agents will display the web content to end users. Authors with disabilities need to be able to follow
the same workflow.
A.3.7.1 Return Mechanism: If a preview is provided, then it is possible for the author(s) to return from the preview using only keyboard commands. (Level A)
- Intent of the Success Criterion A.3.7.1:
The intent of this success criterion is to ensure that even if the preview feature makes use of an existing user
agent with accessibility problems to meet Success Criterion A.3.7.2, authors will at least be able to exit the preview feature in an accessible way.
- Examples that meet the Success Criterion:
- Related Resources:
A.3.7.2 Preview: If a preview is provided, then at least one of the following is true: (Level A)
- (a) Existing User Agent: the preview makes
use of an existing user
agent that is specified in the conformance
claim (e.g., opening the
content in a third-party browser, browser component, video player, etc.); or
- (b) Part A.1: the preview meets
all of the Level A guidelines in Principle A.1 of this document; or
- (c) UAAG: the preview conforms
to the User Agent Accessibility Guidelines [UAAG].
- Intent of the Success Criterion A.3.7.2:
The intent of this success criterion is to ensure that the design of preview features is able to strike a balance between giving authors with disabilities an accessible means of previewing the web content that they are editing and not giving those authors an unrealistic impression of how end users with similar disabilities will actually experience that web content in their user
agents. In other words, having the preview feature meet the User Agent Accessibility Guidelines [UAAG] is not an absolute requirement because the user
agents (for the web content technology in question) that are actually available to end users might not meet UAAG. The most straightforward way to meet this requirement is for authoring tools to simply implement preview features using user
agents that are already in use by end users.
- Examples that meet the Success Criterion:
- Related Resources:
PRINCIPLE
A.4: Editing views must be understandable
Guideline A.4.1 [For the
authoring tool user interface] Help users avoid and correct mistakes.
[Return to Guideline]
Rationale: Some authors who have difficulty making fine movements may be prone to
making unintended actions.
A.4.1.1 Undo Content Changes:
Authoring actions are either reversible
by an "undo" function or include a warning to authors that the action is
irreversible. (Level A)
Note 1: It is acceptable to collect text entry actions (e.g., typed words, a series of backspaces) into a single reversible authoring action.
Note 2: It is acceptable for certain committing actions (e.g., "save", "publish") to make all previous authoring actions irreversible.
- Intent of the Success Criterion A.4.1.1:
The intent of this success criterion is to help authors with disabilities avoid serious consequences in the web content that they are editing as the result of a mistake while performing authoring actions.
- Examples that meet the Success Criterion:
- Non-web-based authoring tool:
An authoring tool has an "Undo" action under the "Edit Menu". Activating the undo action reverses the previous action authoring action. Activating undo again undoes the previous authoring action and so on.
- Web-based content management system:
A web-based content management system supports two types of undo. The first type of undo is that text entry actions into text fields can be undone using the undo feature of the user
agent (cited in the conformance
claim). The second type of undo is that "Cancel" buttons are available in case the author is not satisfied with the result of ending some content. However, to avoid the "Cancel" button being pressed accidentally, authors have the option of having confirmation dialogs displayed when "Cancel" is a activated.
- Related Resources:
A.4.1.2 Undo Setting Changes: Actions that modify authoring tool settings are either reversible or include a warning to authors that the
action is irreversible. (Level A)
- Intent of the Success Criterion A.4.1.2:
The intent of this success criterion is to help authors with disabilities avoid making the authoring tool unusable to them as the result of making a mistake while installing the program or modifying preference settings.
- Examples that meet the Success Criterion:
- All reversible :
All
of the preference setting changes in an authoring tool are reversible, by revisiting the preference setting utility and adjusting the settings. In order to make it easier for authors to start over if they make mistakes, a "restore default settings" button is made available.
- Related Resources:
A.4.1.3 Redo: Authors can immediately reverse the most recent "undo" action(s) (i.e., a "redo" function).
(Level AA)
- Intent of the Success Criterion:
The intent of this success criterion is to ensure that an inadvertent "undo" can be reversed.
- Examples that meet the Success Criterion:
- Web-based content management system:
In the "Web-based content management system" example in A.4.1.1, the content management system supports two types of redo. The first type of redo uses the redo feature of the user
agent (cited in the conformance
claim) to redo text entry that has been "undone". The second type of redo is that for the "Cancel" buttons that allow authors to discard all changes to some content, authors have the option of having confirmation dialogs displayed when "Cancel" is a activated. If the author answers "no" when asked to confirm, the "Cancel" action not performed.
- Related Resources:
Guideline A.4.2
[For the authoring tool user interface] Document the user interface
including all accessibility features.
[Return to Guideline]
Rationale: Some
authors may not be able to understand or operate
the authoring tool user interface without proper
documentation.
See Also: The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2.
A.4.2.1 Document Accessibility Features: All features that
are specifically required to meet Part A
of this document (e.g. keyboard shortcuts, text search, etc.) are documented. (Level A)
- Intent of the Success Criterion:
The intent of this success criterion is to ensure that authors that need to use the accessibility features of the authoring tool user interface can easily find specific instruction in the documentation.
- Examples that meet the Success Criterion:
- Accessibility Features :
An authoring tool includes documentation for the following topics. The documentation is grouped together into an "Accessibility Features" chapter in the help system, and is also linked in context from the various features within the authoring tool:
- how to customize display settings
- what keyboard shortcuts are available, including navigation keys
- how to customize keyboard shortcuts
- how to avoid keyboard traps
- how to extend time limits
- how to use the search features
- how to undo/redo
- how to set accessibility-related options, such as turning off auto-play
- Related Resources:
A.4.2.2 Document All Features: All features of the authoring tool are documented. (Level AA)
- Intent of the Success Criterion:
The intent of this success criterion is to ensure that authors who need additional support to learn to operate an authoring tool can easily access instructions.
- Examples that meet the Success Criterion:
- Related Resources:
PART B: Support the production of accessible content
Applicability Notes:
- Author Availability: Any Part B success criteria that refer to authors only apply during authoring sessions.
- Responsibility After Authoring Sessions: Authoring tools are not responsible for web content accessibility problems that result from carrying out instructions made by authors during authoring sessions (e.g., the content of a third-party feed specified by the author). Authoring tools are responsible if the web content accessibility problems are automatically generated (e.g., when the developer of a content management system updates its site-wide templates).
- Existing Technologies: The Part B success criteria in only apply to support for production of web content using the web content technologies that are included in the conformance claim.
- Authoring Systems: As per the ATAG 2.0 definition of authoring tool, several software tools (identified in the conformance claim) can be used in conjunction to meet the requirements of Part B. (e.g., an authoring tool could make use of a third-party software accessibility checking and repair tool).
PRINCIPLE
B.1: Production of accessible content must be enabled
Guideline B.1.1 Support web content technologies that enable the creation of content that is accessible.
[Return to Guideline]
Rationale: For the purposes of this document, WCAG 2.0 defines the accessible
web content requirements. To support accessible
web content production, at minimum, it must be possible to produce web content that complies to WCAG 2.0 using the authoring tool.
B.1.1.1 Accessible Content Production (Level A): The author(s) can use the authoring tool to produce web content that conforms to WCAG 2.0 Level A.
- Intent of the Success Criterion B.1.1.1:
The intent of this success criterion is to ensure that authors who have the motivation and knowledge to create accessible
web content using an authoring tool are not prevented from doing so. The subsequent success criteria in Part B will build on this minimal requirement. WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.
- Examples that meet the Success Criterion:
- Related Resources:
Guideline B.1.2
Ensure that the authoring tool preserves accessibility information.
[Return to Guideline]
Rationale: Accessibility
information is critical to maintaining comparable levels of accessibility
between the input and output of transformations and conversions.
B.1.2.1 End Product Preserves Accessibility Information: If the web content technology of the output of a transformation or conversion can preserve recognized accessibility
information that is required for that web content to conform to WCAG 2.0 Level A, then the accessibility
information is preserved and available for end users in the end product of the transformation or conversion. (Level A)
- Intent of the Success Criterion B.1.2.1:
The intent of this success criterion is to ensure that, when technically possible, any accessibility
information that authors have made the effort to include in web content is still available to end users after the web content has been transformed within a web content technology or converted into another web content technology.
- Examples that meet the Success Criterion:
- Similar data structures:
A conversion tool preserves accessibility
information in similar data structures, whenever possible. For example:
- when converting between HTML and SVG, the contents of
alt attributes are stored in desc attributes
- when saving a word-processor format to markup,
headings and list items are transformed into appropriate structural
markup
- Dissimilar but accessible:
A conversion tool preserves accessibility
information in a dissimilar, but accessible way, when similar data structures are not available. For example:
- when transforming a SMIL presentation with a closed-caption text track into a video-only format, authors have the option of an open-captioned video
- when transforming a table to a list, table
headings are transformed into headings and summary or caption information
is retained as rendered text content
- when saving a word-processing format to markup, specialized document features (i.e., footnotes, endnotes, call-outs,
annotations, references, etc.) are retained as rendered text content with two-way linking.
- Authors control:
A conversion tool allows authors to edit the conversion rules to specify the way that presentation conventions are to be converted into structural markup.
- Related Resources:
B.1.2.2 End Product Cannot Preserve Accessibility Information: If the web content technology of the output of a transformation or conversion cannot preserve recognized accessibility
information that is required for the end product of the transformation or conversion to conform to WCAG 2.0 Level A, then at least one of the following are true: (Level A)
B.1.2.3 Accessibility Information Preservation (Enhanced): If the authoring tool performs transformations or conversions during an authoring session,
then any accessibility
information in the pre-transformation/conversion content that is required for the end product of the transformation or conversion to conform to WCAG 2.0 Level AA or AAA is preserved and available for end
users.
(Level AA)
- Intent of the Success Criterion B.1.2.3:
The intent of this success criterion is to set out an enhanced preservation requirement (at Level AA) in which authoring tools only offer authors transformations and/or conversions that preserve accessibility
information that will be needed to make the end product accessible.
- Examples that meet the Success Criterion:
- Preserving secondary audio tracks:
A multimedia authoring tool is capable of converting video formats that include secondary audio tracks, that may contain audio descriptions, into video formats that support only one audio track. In these cases, the author is provided with options to preserve the information in the secondary audio track by either (1) combining the two audio tracks into the one remaining audio track or (2) moving the secondary audio track into a separate audio file that is associated with the resulting video file using SMIL.
- Related Resources:
B.1.2.4 Notification Prior to Deletion: If the authoring tool automatically deletes any author-generated content for any reason, then at least one of the following is true:
(Level AA)
Guideline B.1.3
Ensure that automatically generated content is accessible.
[Return to Guideline]
Rationale: Authoring tools that automatically generate content that is not accessible impose additional repair tasks on authors.
See Also: If accessibility
information is required from authors during
the automatic generation process, see Guideline
B.2.1. If templates or other pre-authored content are involved, see Guideline B.2.5.
PRINCIPLE B.2:
Authors must be supported in the production of
accessible content
Guideline B.2.1 Guide authors to
create accessible content.
[Return to Guideline]
Rationale: By guiding authors from the outset towards the creation and maintenance of accessible
web content, web content accessibility problems are mitigated and less repair effort is required.
B.2.1.X Decision Support: If the authoring tool presents choices to the author(s), provide information to assist the author in making choices that enable the content to conform to WCAG 2.0. (Level A) @@decision-support SC@@
- Intent of the Success Criterion B.2.1.X:
The intent of this Success Criterion is to ensure that correct accessibility decisions are made from the start, which reduces the resources required for correction.
- Examples that meet the Success Criterion:
- Choosing between calendar widgets:
An author, using a content management system, adds a date field. The system prompts the user to choose a calendar widget that will appear to the end-user when they use the date field. All choices that conform to WCAG 2.0 are labeled as accessible. Choices that do not conform include warnings to the author.
- Accessibility fields for a table:
An author inserts a table using an HTML authoring tool. The authoring tool displays a dialog box that prompts the author for the number of rows and columns and also for accessibility fields such as caption and summary.
The author is not required to fill in the accessibility fields to continue, but help text accompanying the fields explains the importance of the fields for accessibility.
- Help on proper use of accessibility fields:
An author inserts an image into some content and is provided with a field for entering an alternative text label and a means for identifying that the role of the image is decorative. Help text is provided to explain how and when to use these fields in order to conform to WCAG 2.0.
- Related Resources:
B.2.1.1 Set Accessible Properties: Mechanisms that set the properties of web content (e.g., attribute values, etc.) include the ability to set the accessibility-related properties. (Level A)
- Intent of the Success Criterion B.2.1.1:
The intent of this success criterion is to ensure that if authoring tools only allow authors the ability to modify a subset of the properties of a content element, the properties required for conformance to WCAG 2.0 are included in the subset.
- Examples that meet the Success Criterion:
- Context sensitive properties:
A markup authoring tool includes a context sensitive properties pane that displays property fields for the most common subset of attributes associated with the markup element that currently has focus in the editing view. The attributes that are required for WCAG 2.0 are included in the subset.
- Related Resources:
N/A
B.2.1.2 Other Technologies: If the authoring tool enables web content to be inserted that the authoring tool cannot be used to edit, then provide the author(s) with the option to insert or associate accessibility information. (Level A)
- Intent of the Success Criterion:
The intent of this success criterion is to ensure that when web content technologies can only be imported or integrated (but not edited), authoring tools still provide a mechanism for associating needed accessibility information. Many authoring tools make a distinction between technologies that the authoring tool uses to edit web content and technologies that can only be imported or integrated. For example, most HTML editors can insert images into web pages without the ability to edit the images. In situations where web content is imported or integrated that cannot be edited, the authoring tool can support accessibility by inserting or associating accessibility information using technologies that it does have the ability to edit.
- Examples that meet the Success Criterion:
- Time-based media alternatives:
A SMIL authoring tool lets authors create multimedia presentations by pulling together video, audio and timed text objects on to a timeline, even though the tool has no built-in ability to edit these objects. When authors specify information about video to be inserted, they are also provided with the opportunity to associate a timed text object (for captions), an audio object (for audio description) and a secondary video (for sign language interpretation). When authors specify information about audio to be inserted, they are also provided with the opportunity to associate a timed text object (for captions) and a video (for sign language interpretation).
- Data table for a bar graph:
A learning content managment system has a feature that lets authors insert figures. The feature accepts images, even though the authoring tool has no built-in ability to edit images, but as part of the "figure properties" the authors can identify the figure as a graph. If they choose this option, then the system assists the authors in creating an accompanying data table using the values used to create the graph.
- Related Resources:
Guideline B.2.2 Assist authors in checking for accessibility problems.
[Return to Guideline]
Rationale: Accessibility checking as an integrated function of the authoring tool helps make authors aware of web content accessibility problems during the authoring process, so they can be immediately addressed.
B.2.2.1 Check Accessibility (Level A): At least one individual check
is associated with each WCAG 2.0 Level A Success Criterion that the authoring tool has the functionality to modify web content to meet (e.g., an HTML authoring tool that inserts images should check for alt text; a video authoring tool with the ability to edit text tracks should check for captions). (Level A)
Note: While automated
checking or more advanced implementations of semi-automated
checking may improve the authoring experience, manual checking is the minimum requirement to meet this success criterion (as well as B.2.2.4 and B.2.2.10).
- Intent of the Success Criterion B.2.2.1:
The intent of this success criterion is to ensure that authors are supported in discovering web content accessibility problems in the web content that they are editing. This is critical if these issues are to be addressed prior to publishing. The requirement to individually check WCAG 2.0 success criteria is intended to prevent manual checks from being worded in excessively general ways (e.g., "does the page meet all of the requirements?"). The success criterion does not specify how multiple instances of the same problem should be handled, because this will usually depend on the nature of the problem and the degree of automation in the checking and repair features of the authoring tool. Some problems are limited to one or just a few elements and lend themselves to automated or semi-automated reporting of each instance (e.g, missing labels), while other problems extend across many elements and are sometimes best checked globally (e.g., reading level, etc.). The note about manual checking is intended to recognize that the current state of technology does not allow every web content accessibility problem to be identified automatically.
- Examples that meet the Success Criterion:
- Markup processing checker :
An accessibility checking tool includes automated for web content accessibility problems that can be detected from markup alone. The tool includes semi-automated checking where potential instances can be detected from the markup but where an understanding of the content is required to make a final decision. In cases where markup processing is little or no use in detecting problems, manual instructions are included for authors to follow in identifying whether the relevant WCAG 2.0 success criterion has been met.
- Content processing checker:
An accessibility checking tool goes beyond markup processing
by applying content processing heuristics, such as:
- Image processing to detect whether foreground and background contrast levels are sufficient or whether images are blank.
- Text processing to calculate reading levels and detect changes in human language.
- Related Resources:
B.2.2.2 Availability: Checking is available prior to
publishing in a manner appropriate to the workflow of the authoring tool. (Level A)
- Intent of the Success Criterion B.2.2.2:
The intent of this success criterion is to ensure that accessibility checking is an integral part of the normal workflow of authoring tools, similar to checking for other content issues (e.g., spelling, syntax, validation, security). If authors are made aware of the web content accessibility problems in their web content as a normal part of their workflow, the issues are more likely to be repaired before the web content is published. Through this process, authors will become more aware of accessible authoring practices.
- Examples that meet the Success Criterion:
- Check-as-you-type:
An authoring tool continuously checks the web content being edited and highlights problems as the authors work.
Figure: A WYSIWY authoring tool is shown with check-as-you-type accessibility checking activated. Two elements on the page have been highlighted as having problems: an image is surrounded by a blue squiggly line and a line of text is underlined by the same style of blue squiggly line. (Source: mockup by AUWG)
- Checking on demand:
An authoring tool provides accessibility checking from a menu item that is always available.
- Prompt to check before publishing:
An authoring tool automatically performs an accessibility check if authors choose to close or publish the web content and informs the authors of the results.
- Related Resources:
B.2.2.3 Help Authors Decide: For any checks that require author judgment to determine whether a potential
web content accessibility problem
is correctly identified (i.e., manual checking
and semi-automated checking),
instructions are provided to help authors to decide whether it is correctly identified. (Level A)
- Intent of the Success Criterion:
The intent of this success criterion is to ensure that authors, who in many cases will lack accessibility knowledge, will be able to make adequate judgments. If this is not the case, authors may miss web content accessibility problems that do exist and/or mistakenly identify problems that do not exist.
- Examples that meet the Success Criterion:
- Questions answered:
Instructions are formulated to answer the following questions: "What part of the content should be examined?" and "What is present or absent that is causing the problem?".
- Variety of views:
When author judgements would be enhanced by modified views of the web content being edited, an accessibility browser toolbar is used to provide various previews, such as:
- an alternative content view (with images and other multimedia replaced by any alternative content)
- a monochrome view (to test contrast)
- a text to speech view (to test the availability of text alternatives)
- no scripts view
- no frames view
- no style sheet view
- Judgments saved:
An authoring tool saves author judgments for manual checks and only prompts for new judgments after the author has made substantial changes.
- Related Resources:
B.2.2.4 Help Authors Locate: For any checks that require author judgment to determine whether a potential web content accessibility problem is correctly identified (i.e., manual checking and semi-automated
checking), the relevant web content is identified (e.g., displaying the web content, displaying line numbers, etc.) (Level AA)
- Intent of the Success Criterion:
The intent of this success criterion is to increase the accuracy of author judgements by identifying the location of suspected web content accessibility problems as precisely as possible.
- Examples that meet the Success Criterion:
- Related Resources:
B.2.2.5 Check Accessibility (Level AA): At least one individual check is associated with each WCAG 2.0 Level AA Success Criterion that the authoring tool has the functionality to modify web content to meet. (Level AA)
- See Techniques for B.2.2.1 using WCAG 2.0 level AA.
B.2.2.6 View Status: If the authoring tool records web content accessibility problems found during checking, then a list of any problems is available to authors prior to the end of the authoring session. (Level AA)
- Intent of the Success Criterion:
The intent of this success criterion is to ensure that an overview of the accessibility status of web content is present to enable authors to assess their repair options, monitor progress and manage reporting.
- Examples that meet the Success Criterion:
- Related Resources:
B.2.2.7 Save Status for Repair: If repair assistance is not provided during checking, then authors have the option to save a list of web content accessibility problems to facilitate interoperability between checking and repair. (Level AA)
- Intent of the Success Criterion:
The intent of this success criterion is to encourage interoperability between checking and repair, even when more seamless checking and repair workflows (which are usually preferable) are not possible for whatever reason. Saving the status in a human-readable format facilitates manual repair as well as monitoring progress and managing reporting.
- Examples that meet the Success Criterion:
- Save out accessibility status:
An accessibility checker has an accessibility status feature (in order to meet success criterion B.2.2.6) that lists the web content accessibility problems in the web content along with the line number of the first element involved. This feature has a "save" function that allows list of problems to be saved out as a text file.
- Web-based checker:
A web-based accessibility checker has an accessibility status feature (in order to meet success criterion B.2.2.6) that lists the web content accessibility problems in the web content along with the line number of the first element involved. The page can then be saved using the "save" function in the user agent (that is cited in the conformance claim).
- Related Resources:
B.2.2.8 Metadata for Discovery: If the authoring tool records the accessibility status of web content, then authors have the option to associate this status with the web content as metadata to facilitate resource discovery by end users. (Level AA)
- Intent of the Success Criterion:
The intent of this success criterion is to facilitate the creation of accessibility metadata that can be used some content management systems to match end user accessibility preferences with suitably designed web content.
- Examples that meet the Success Criterion:
- Saving AccessForAll:
An accessibility checker has an accessibility status feature (in order to meet success criterion B.2.2.6) that lists the web content accessibility problems in the web content. The feature provides an option of storing accessibility status information using the IMS AccessForAll Meta-data
mechanism [ACCESSFORALL].
- Related Resources:
B.2.2.9 Metadata for Repair: If repair assistance is not provided during checking, then authors have the option to save a metadata listing of the web content accessibility problems to facilitate interoperability between checking and repair. (Level AAA)
- Intent of the Success Criterion:
The intent of this success criterion is the same as for B.2.2.8 except that for B.2.2.9 the information is to be provided in a machine-readable format, which facilitates automated repair and semi-automated repair.
- Examples that meet the Success Criterion:
- Saving EARL:
An accessibility checker has an accessibility status feature (in order to meet success criterion B.2.2.6) that lists the web content accessibility problems in the web content. In addition to the text file "save' function (in order to meet success criterion B.2.2.7), the feature provides authors with the option of storing the accessibility
status information using the Evaluation and Repair Language [EARL].
- Related Resources:
B.2.2.10 Check Accessibility (Level AAA): At least one individual check is associated with each WCAG 2.0 Level AAA Success Criterion that the authoring tool has the functionality to modify web content to meet. (Level AAA)
- See Techniques for B.2.2.1 using WCAG 2.0 level AAA.
Guideline B.2.3
Assist authors in repairing accessibility problems.
[Return to Guideline]
Rationale: Repair as an integral part of the authoring process greatly enhances the utility of checking and increases the likelihood that accessibility
problems will be properly addressed.
B.2.3.1 Repair Accessibility (Level A): For each WCAG 2.0 Level A web content accessibility problem that is identifiable during checking (required
in Guideline B.2.2), repair assistance is provided. (Level A)
Note: While automated repair assistance or more advanced implementations of semi-automated repair assistance may improve the authoring experience, manual repair assistance is the minimum requirement to meet this success criterion (as well as success criteria B.2.3.2 and B.2.3.3).
- Intent of the Success Criterion:
The intent of this success criterion is to ensure that authors are given a method to repair identifiable web content accessibility problems. Allowing manual repair assistance to meet this success criterion is intended to take into account the difficulty of automatically or semi-automatically repairing certain types of accessibility problems (e.g., ensuring clear link text).
- Examples that meet the Success Criterion:
- Technique B.2.3.1-1 [Sufficient]:
For each potential accessibility problem identified by the checking function (required in Guideline B.2.2), providing repair instructions that an author (with sufficient skill and knowledge to use the rest of the tool) could follow to correct the problem. At the authoring tool developer's discretion, semi-automated repairs (that prompts the author for required information) or automated repairs (that are able to complete the repair without prompting the author) may be substituted.
- Technique B.2.3.1-2 [Advisory]:
Providing as much automated repair as possible. Where necessary provide semi-automated repairing (see Appendix C: Levels of Repair Automation). Where neither of these options is possible, provide manual repairing.
- Technique B.2.3.1-3 [Advisory]:
When appropriate, reusing affected elements' property editing mechanisms. This has the advantage that the author is already somewhat familiar with the interface. However, this practice does not necessarily focus the author's attention on the dialog control(s) that are relevant to the required correction.
- Technique B.2.3.1-4 [Advisory]:
Implementing a special-purpose correcting interface, analogous to a spelling or grammar checker, that includes only the input field(s) for the information currently required. Additional information and tips that the author may require in order to properly provide the requested information can be added.
- Example: A special-purpose correction interface supports the author's repair task by providing (1) a short description of the problem (here: "Missing Alternate Text Label for an Image"), (2) a preview (here: the "earthrise" image that is missing a label), (3) tips for performing the repair (here: "Alternate text should be 10 words or less and should include any text in the image."; "Image buttons should have alternate text that describes the button function."; and "Image bullets should have "bullet" as alternate text."), and (4) an offered semi-automated repair in an editable drop-down box (here: "An earth rise as seen from the moon"). (Source: mockup by AUWG)
Technique B.2.3.1-5 [Advisory]:
Presenting accessibility problems and repair options in a sequential manner analogous to a typical spelling or grammar checking "wizard". Because of the wider range of problems an accessibility checker needs to handle (i.e., missing text, missing structural information, improper use of color, etc.), the interface template will likely need to be especially flexible.
- Example: A sequential accessibility checker. The special-purpose correction interface from the previous example is supplemented by a progress indicator ("5 of 25") and navigation buttons to move backwards ("back") and forwards ("skip") through the list of repair tasks. Buttons to "repair", get "help" and "cancel" are also provided. (Source: mockup by AUWG)
Technique B.2.3.1-6 [Advisory]:
Where an authoring tool is able to detect site-wide problems, allowing the author to make site-wide corrections. This should not be used for alternative content when the function is not known with certainty (see Guideline B.2.4).
- Technique B.2.3.1-7 [Advisory]:
Providing a mechanism for authors to navigate sequentially among uncorrected accessibility problems. This allows the author to quickly scan accessibility problems in context.
- Related Resources:
- Techniques for Accessibility Evaluation and Repair Tools [AERT] Public Working Draft document for evaluation and repair algorithms.
Guideline
B.2.4 Assist authors with managing alternative content for non-text content.
[Return to Guideline]
Rationale: Improperly generated alternative content can create accessibility problems and interfere with accessibility checking.
See also: This guideline applies when non-text
content is specified by the author(s) (e.g., an author inserts an image). When non-text
content is automatically added by the authoring tool, see Guideline B.1.3.
B.2.4.1 Editable: Authors are able to modify alternative content for non-text
content. This includes types of alternative content that may not typically be displayed on screen by user agents. (Level A)
- Intent of the Success Criterion:
The intent of this Success Criterion is to ensure that authors can add alternative content for non-text objects and modify that alternative text in the future. If the type of alternative content (e.g., alternative text) is not displayed by a WYSIWYG editing view, another mechanism is provided for modifying that content.
- Examples that meet the Success Criterion:
- Technique B.2.4.1-1 [Sufficient]: Proving editing mechanisms for all applicable alternative content types in a properties editor.
- Technique B.2.4.1-2 [Sufficient]: Providing a mechanism for the author to accept, modify, or reject any alternative content that the authoring tool supplies during the insertion process.
- Technique B.2.4.1-3 [Advisory]: Allowing the author to accept patterns of future uses of an alternative content under certain conditions (e.g., whenever the same non-text content is marked with the same semantic role).
- Technique B.2.4.1-4 [Advisory]: If the
author changes the alternative equivalent for non-text content, asking the author whether all instances of the
non-text content with the same known function should also be updated.
- Technique B.2.4.1-5 [Advisory]: Providing an editing capability for any alternative content managed by the tool.
- Example: A text equivalents registry viewer allows the author to query and edit the various text equivalents stored in the registry. For maximum flexibility, the design takes into account multiple non-text content objects of the same name, multiple types of text equivalents for each non-text content object, and multiple versions of each text equivalent type. In the viewer shown here, the author has selected "image" as the "media type" and then selected pic123.gif as the "content" to edit. This has brought up a rendering of the "earthrise" image. The viewer also shows that the content has three text labels. The author has selected one ("An earth rise as seen from the moon") in order to edit it. In addition some authoring tips are included ("Alternate text should be 10 words or less and should include any text in the image", "Image buttons should have alternate text that describes the button function.", and "Image bullets should have "bullet" as alternate text."(Source: mockup by AUWG)
B.2.4.2 Automated suggestions: During the authoring session, the authoring tool can automatically suggest alternative content for non-text
content only under the following conditions: (Level A)
- (a) Author control: authors have the opportunity to accept, modify, or reject the suggested alternative content prior to insertion; and
- (b) Relevant sources: the suggested alternative content is only derived from sources designed to fulfill the same purpose (e.g., suggesting the value of an image's "description" metadata field as a long description).
- Intent of the Success Criterion:
The intent of this Success Criterion is to prevent the production of alternative content that is not useful to an end user because it has not been approved by an author and/or it is derived from unreliable sources. Authors who are unfamiliar with accessibility may approve alternative content suggestions without understanding the problems these can cause for end users.
- Examples that meet the Success Criterion:
- Clip art library:
....Placing, within the appropriate field of the non-text content editing dialog box, a text alternative (or multiple alternatives if a drop-down is used) that was obtained from one of the acceptable sources.
- Related Resources:
B.2.4.3 Let user agents repair: After the end of an authoring session, the authoring tool does not attempt to repair alternative content for non-text
content using text values that is equally available to user agents (e.g., the filename is not used). (Level A)
- Intent of the Success Criterion:
The intent of this Success Criterion is to ensure that if the authoring tool does attempt to automatically repair missing alternative content, the repair does not imply that the alternative content has been provided by or approved by the author. In some cases, the authoring tool will have text information, such as contextual information (e.g., the image is the author's profile picture) that the user agent does not have equal access to, in which case, the repair can be made.
- Examples that meet the Success Criterion:
- Contextual information is known:
A social networking authoring tool allows the author to add a description of their profile picture. If the author chooses not to provide a description, the authoring tool labels the image as the author's profile picture.
- Contextual information is not known:
A web page authoring tool allows the author to insert images. The authoring tool has access to information such as the filename, but since this is text information that is equally available to user agents, it is not suggested.
- Related Resources:
B.2.4.4 Save for Reuse: Authors have the option of having any recognized plain text alternative content that they enter (e.g., short text labels, long descriptions) stored for future reuse. (Level AA)
-
- Intent of the Success Criterion:
The intent of this Success Criterion is to ensure that when the author has spent effort providing alternative content, this content is retained by the authoring tool in a form that allows it be easily reused.
- Examples that meet the Success Criterion:
- Related Resources:
Guideline B.2.5 Assist authors with accessible templates and other pre-authored content.
[Return to Guideline]
Rationale: Templates and other pre-authored
content (e.g., clip art, synchronized media, widgets, etc.) that are not accessible impose additional repair tasks on authors.
B.2.5.1 Templates "A" Accessible: If the authoring tool automatically selects templates or pre-authored content, then the selection meets WCAG 2.0 Level A when used. (Level A)
Note: Templates may be complicated to check for accessibility due to their inherent incompleteness. The accessibility status of templates is instead measured by the accessibility of web content (in the final web content technology) created through their proper use.
- Intent of the Success Criterion:
The intent of this Success Criterion is to ensure that when authoring tools select templates or pre-authored content for the author(s) or automatically generate web content from a template, then the web content meets WCAG 2.0 Level A by default. If this was not the case, authoring tools could continually introduce accessibility problems that the author(s) would not be able to repair.
- Examples that meet the Success Criterion:
- Content management system:
A content management system offers a variety of templates to authors for different purposes (e.g., information page, interactive form page, registration page, etc.). All of the templates have passed WCAG 2.0 Level A accessibility evaluations with sample content.
- Related Resources:
B.2.5.2 Provide Accessible Templates: If the authoring tool provides templates, then there are accessible template options for a range of template uses. (Level A)
- Intent of the Success Criterion:
The intent of this Success Criterion is to ensure that an author is not forced to use an inaccessible template to create web content for a purpose for which an accessible template does not exist..
- Examples that meet the Success Criterion:
- Variety of accessible templates:
An authoring tool provides several template choices for home pages, guest books and on-line albums. For each type of functionality, the basic template option is accessible.
- Related Resources:
B.2.5.3 Templates "AA" Accessible: If the authoring tool automatically selects templates or pre-authored content, then the selection meets WCAG 2.0 Level AA when used. (Level AA)
- See Techniques for B.2.5.1 using WCAG Level AA.
B.2.5.4 Template Selection Mechanism: If authors are provided with a template selection mechanism,
then both of the following are true (Level AA):
- Intent of the Success Criterion:
The intent of this Success Criterion is to ensure that authors can easily determine the accessibility status of templates prior to selecting them and that author is more likely to notice the accessible template options.
- Examples that meet the Success Criterion:
- Template names include accessibility status:
In a wiki system, creating a new page brings up a list of available templates. The WCAG 2.0 conformance of each template is included in the name (e.g., "slide show template - wcagA").
- Sort by accessibility status:
A template repository lists the available templates and provides the templates' accessibility status as a sortable field.
- Related Resources:
B.2.5.5 New Templates: If authors can use the authoring tool to create new templates for use by a template selection mechanism, they have the option to record the accessibility status of the new templates.
(Level AA)
- Intent of the Success Criterion:
The intent of this Success Criterion is to ensure that new templates that authors create and which might be used by subsequent authors interoperate with the relevant template selection mechanism.
- Examples that meet the Success Criterion:
- Save as template:
An authoring tool provides a "save as template" feature. When authors activates this feature, the authoring tool automatically runs an accessibility checker on the template with sample data. The author is provided with the option of labeling the template with its accessibility status. If the template fails to conform to WCAG 2.0 with sample data, the author is advised that templates should be held to a high accessibility standard, since they will be repeatedly reused.
- Related Resources:
B.2.5.6 Pre-Authored Content Selection Mechanism: If authors are provided with a selection mechanism for pre-authored content other than templates (e.g., clip art gallery, widget repository, design themes), then both of the following are true (Level AA):
- (a) Indicate: the selection
mechanism indicates the accessibility status of the pre-authored content (if known); and
- (b) Prominence: any accessible options are at least as prominent as other pre-authored content options.
- See Techniques for B.2.5.4, reading "pre-authored content" in place of "templates".
B.2.5.7 Templates in Repository: If the authoring tool provides a
repository of templates, then each of the templates has a recorded accessibility status.
(Level AAA)
- Intent of the Success Criterion:
The intent of this Success Criterion is to ensure that all templates that the authoring tool provides include an accessibility status.
- Examples that meet the Success Criterion:
- Template repository :
???
- Related Resources:
B.2.5.8 Pre-Authored Content in Repository: If the authoring tool provides a repository of pre-authored content, then
each of the content objects has a recorded accessibility status. (Level AAA)
- Intent of the Success Criterion:
The intent of this Success Criterion is to ensure that all pre-authored content that the authoring tool provides include an accessibility status.
- Examples that meet the Success Criterion:
- Clip art collection:
An authoring tool is shipped with a clip art collection. Each image in the collection has a short text label and long text description and the system is interoperable with the alternative content registry (See Checkpoint B.2.4.4), so that whenever the author inserts an image from the clip art collection, its alternative content is automatically retrieved.
- Related Resources:
B.2.5.9 Templates "AAA" Accessible: If the authoring tool automatically select templates or pre-authored content, then the selection meets WCAG 2.0 Level AAA when used.
(Level AAA)
- See Techniques for B.2.5.1 using WCAG Level AAA.
PRINCIPLE
B.3: Accessibility solutions must be promoted and integrated
Guideline B.3.1
Ensure that accessible authoring
actions are given prominence.
[Return to Guideline]
Rationale: When authors are learning a new authoring tool, they may find and learn to use the first authoring
action they encounter that achieves their intended outcome. Since they may be unaware of the issue of accessibility, it is preferable that accessible
web content be an additional unintended outcome, rather than inaccessible content.
B.3.1.1 Accessible Options Prominent (Level A): If the author(s) are provided with multiple options for an authoring task, options that will result in web content conforming to WCAG 2.0 Level A are at least as prominent as options that will not. (Level A)
- Intent of the Success Criterion:
The intent of this Success Criterion is to ensure that accessible authoring practices are part of the default workflow.
- Examples that meet the Success Criterion:
- Related Resources:
- Technique
B.3.1.1-1 [Sufficient]: Removing less accessible options.
- Technique
B.3.1.1-2 [Sufficient]: Providing the more accessible choice with a higher position in the menus and having it appear in interface shortcuts such as toolbars.
- Example: An authoring tool that supports
two methods for setting text color: using CSS and using
font.
Since using CSS is the more accessible option, it is given a higher prominence
within the authoring interface by: (1) the "CSS Styling" option
appearing above the "FONT Styling" option in the drop down Text
menu, and (2) the CSS styling option being used to implement the one-click
text color formatting button in the tool bar. The association is made clear because the toolbar button has the same icon (an "A" beside a color spectrum) as the "Color" sub-menu item under the "CSS Styling" menu option.). An (Source: mockup by AUWG)
B.3.1.2 Accessible Options Prominent (Level AA): If the author(s) are provided with multiple options for an authoring task, options that will result in web content conforming to WCAG 2.0 Level AA are at least as prominent as options that will not. (Level AA)
- See Techniques for B.3.1.1 using WCAG Level AA.
B.3.1.3 Accessible Options Prominent (Level AAA): If the author(s) are provided with multiple options for an authoring task, options that will result in web content conforming to WCAG 2.0 Level AAA are at least as prominent as options that will not. (Level AAA)
- See Techniques for B.3.1.1 using WCAG Level AAA.
Guideline B.3.2
Ensure that features
of the authoring tool supporting the production of accessible content are available.[Return to Guideline]
Rationale: The accessible
content support features will be more likely to be used if they are turned on and are afforded reasonable prominence within the authoring tool user interface.
B.3.2.1 Active by Default: All
accessible content support features are turned on by default. (Level A)
-
- Intent of the Success Criterion:
The intent of this Success Criterion is to ensure that the accessible content support features are perceived as a natural and expected part of the authoring tool workflow.
- Examples that meet the Success Criterion:
- Related Resources:
- Technique B.3.3.1-1 [Sufficient]: Ensuring that all accessible content support features are turned on by default within the authoring tool preferences area.
- Example: The preference setting area of an authoring tool, open to an "Accessibility" section, shows the default settings. "W3C-WCAG" and a level (e.g. "Double-A") are selected as are the following options: "Check accessibility as you type", "Check accessibility after saving", "Auto-correct when possible", "Highlight accessibility related fields", "Prompt when highlighted fields are left blank", and "Provide accessibility 'Quick Tips'". (Source: mockup by AUWG)
B.3.2.2 Reactivate Option: If the
author(s) turn off an accessible content support feature, then
they can always turn on the feature. (Level A)
- Intent of the Success Criterion:
The intent of this Success Criterion is to ensure that if an author turns off an accessible content support feature for any reason, they can easily turn it back on.
- Examples that meet the Success Criterion:
- Related Resources:
- Technique B.3.3.2-1 [Sufficient]: Providing an authoring tool preferences area where any deactivated features can be reactivated.
B.3.2.3 Deactivation Warning: If the
author(s) deactivate an accessible content support feature, then the authoring tool informs them that this may increase the risk of content accessibility problems. (Level AA)
-
- Intent of the Success Criterion:
The intent of this Success Criterion is to ensure that if an author attempts to turn off an accessible content support feature for any reason, they will understand the effect this will have on the accessibility of the web they produce.
- Examples that meet the Success Criterion:
- Related Resources:
- Technique B.3.3.3-1 [Sufficient]: Providing the author with a warning whenever an accessible content support feature is turned off (e.g., from the authoring tool preferences area.
- Example: In an authoring tool, the author has unchecked a
"highlighting accessibility related fields" feature the tool. As a result the tool displays a
warning that reads "You have just turned off the highlighting accessibility related fields feature.
This feature is designed to inform you when information must be provided in order for your documents to
comply with your target accessibility setting. Turning this feature off could cause your documents to be
less accessible to many users. In some jurisdictions accessibility is a legal requirement. Are you
sure you want to proceed?". The author has the option to answer "Yes", "No" or
"Cancel". (Source: mockup by AUWG)
B.3.2.4 At Least as Prominent: Accessible content support features are at least as prominent as
comparable features related to other types of
web content problems (e.g., invalid markup, syntax errors, spelling
and grammar errors).
(Level AA)
- Intent of the Success Criterion:
The intent of this Success Criterion is to ensure that authors will be as likely to notice and address accessibility problems as other web content issues.
- Examples that meet the Success Criterion:
- Related Resources:
- Technique B.3.3.4-1 [Sufficient in combination]: Ensuring that prompting for accessibility information
has the same prominence as prompting for information critical to content correctness (e.g., a tool that prompts the author for a required multimedia file name attribute has prompts with the same prominence
for short text labels and long descriptions for that object.
- Example: An "Image Properties" dialog box in which the input fields
are ordered (from top to bottom, left to right): source ("src"), short label ("alt"), long description ("longdesc"), height, and width. The buttons at the bottom are "More...", "OK" and "Cancel". (Source: mockup by AUWG)
- Technique B.3.3.4-2 [Sufficient in combination]: Ensuring that utilities for checking and repairing accessibility problems
has the same prominence as utilities for checking for information critical to content correctness (e.g., a tool that checks for spelling, grammar, or code syntax will
have checks with the same prominence as checking for accessibility problems).
Example: An authoring interface that checks
for and displays spelling and accessibility problems with the same prominence in that both are shown as underlines, one red, one blue.
In this case, the author has activated a right-click pop-up menu on the word "CHZ" that includes
spelling repair options ("1 Khz", "2 Chi", "Check Spelling...") and accessibility repair options ("Repair: Set acronym expansion…", "Skip", "Ignore", and "Check Accessibility...") and "Help...". (Source: mockup by AUWG)
- Technique B.3.3.4-3 [Sufficient in combination]: Ensuring that documentation for accessibility has the
same prominence as documentation for information critical to content correctness.
(e.g., a tool that documents any aspect of its operation will have documentation
with the same prominence for accessibility).
- Example: Accessibility documentation
is part of the main documentation of an authoring tool, with very similar prominence
to that of the spelling-related features. In the right pane is the documentation table of contents, where "Accessibility Features" appears as a top level topic just below "Spelling Features". In the left panel is the help text, demonstrating a style typical of the rest of the help system: "Checking for Accessibility: A variety of accessibility checking options are available: Accessibility verifier, Check accessibility as you type, Manual test support materials.
These are suitable for use at different times during the authoring process and all have options that can be changed with the accessibility preferences. To get more information on accessible Web content, see the References.". (Source: mockup by AUWG)
Guideline B.3.3
Ensure that features
of the authoring tool supporting the production of accessible
content are documented. [Return to Guideline]
Rationale: Without documentation of
the features
that support the production of accessible content (e.g., prompts for text alternatives, accessibility checking tools), some authors may
not be
able to use them.
B.3.3.1 Instructions: Instructions for using
the accessible content support features appear in the documentation.
(Level A)
- Intent of the Success Criterion:
The intent of this Success Criterion is to that authors are able to use the accessible content support features effectively. In addition, as authors reference the authoring tool documentation, accessibility is a naturally integrated part of the instruction.
- Examples that meet the Success Criterion:
- Related Resources:
- Technique B.3.4.1-1 [Sufficient]: Ensuring that the help system answers
the question "What features of the tool encourage the production
of accessible content?" with reference to all of the accessible content support features and for each feature identified, the help system answers the question "How are these features operated?".
- Technique B.3.4.1-2 [Advisory]: Providing direct links from accessible content support features to context sensitive
help on how to operate the features.
- Technique B.3.4.1-3 [Advisory]: Providing direct links from within the accessibility-related documentation that take the author directly to the relevant accessible content support features.
- Technique B.3.4.1-4 [Advisory]: During prompting and repairs, providing the author
with immediate access to some basic accessibility documentation and one-step
access to more comprehensive documentation.
- Example: An accessibility
checker includes some limited tips for authoring short text labels listed beneath the
text entry area as well as a "Help" button linking to the full documentation. The tips are: "Alternate text should be 10 words or less and should include any text in the image.", "Image buttons should have alternate text that describes the button function.", and "Image bullets should have 'bullet' as alternate text.". The screen shot also includes the name of the problem ("Missing Alternate Text Label for an Image"), a field for adding the short text label and a preview rendering of the image ("earthrise"). At the bottom are five buttons: "Help", "< Back", "Repair", "Skip", and "Cancel". (Source:
mockup by AUWG)
B.3.3.2 Accessible Authoring Tutorial: A tutorial on an accessible
authoring process that is specific to the authoring tool is provided.
(Level AAA)
-
- Intent of the Success Criterion:
The intent of this Success Criterion is to ensure that authors that learn best through tutorials are exposed to accessibility best practices specific to the author tool.
- Examples that meet the Success Criterion:
- Related Resources:
- Technique B.3.4.2-1 [Sufficient]: Providing a tutorial that describes how to use the authoring tool to increase the accessibility of Web content. The tutorial begins at the typical starting point for the tool (e.g., empty document) and, for example, describes how accessibility prompting should be followed as content is being added or modified. The tutorial also covers when and how checking and repair should be performed.
- Technique B.3.4.2-2 [Advisory]: Ensuring that wherever rationales appear, the text avoids referring to accessibility features
as being exclusively for particular groups (e.g., "for blind authors"). Instead, the rationales emphasize the importance of accessibility
for a wide range of content consumers, from
those with disabilities to those with alternative viewers (see "Auxiliary
Benefits of Accessibility Features", a W3C-WAI resource).
- Technique B.3.4.2-3 [Advisory]: Providing a dedicated accessibility
section.
- Technique B.3.4.2-4 [Advisory]: Providing context-sensitive help definitions for accessibility-related terms.
- Technique B.3.4.2-5 [Advisory]: Including pointers to more information on accessible Web authoring, such as WCAG and other accessibility-related resources.
- Technique B.3.4.2-6 [Advisory]: Including pointers to relevant technology specifications. This is particularly relevant for languages that are easily hand-edited, such as most XML languages.
- Technique B.3.4.2-7 [Advisory]: Calling author attention to accessibility-related idiosyncrasies of the tool compared to other authoring tools that create the same kind of content.
- Example: Content might need to be saved before an automatic accessibility checking feature becomes active.
Guideline B.3.4
Ensure that any authoring practices demonstrated in documentation are
accessible.[Return to Guideline]
Rationale: Demonstrating
accessible authoring as routine practice will encourage its acceptance by some authors.
B.3.4.1 Model Accessible Practice (Minimum): A range of examples of documentation (e.g.,
markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level
A accessible
authoring practices.
(Level A)
-
- Intent of the Success Criterion:
The intent of this Success Criterion is to promote accessible authoring practices as best practice.
- Examples that meet the Success Criterion:
- Related Resources:
- Technique B.3.5.1-1 [Sufficient]: Ensuring that in the authoring tool documentation, all examples of content conform to WCAG Level
A and also that all screen shots of the authoring tool interface are in states that corresponds with the production of content that conforms to Level A (e.g., prompts filled in, optional accessibility features turned on, etc.).
Example: Documentation for
the input element in this instruction-level authoring tool makes use
of the label element in an example in order to reinforce the routine nature
of the pairing. The help text reads: "Input Element: Input elements are form controls. They let the reader of your page use text entry, checkboxes, radio buttons, etc. to interact with your page. The most important attribute of the INPUT element is type. The value of type can be: button, checkbox, file, hidden, image, password, radio, reset, submit, and text. Examples:<label>Enter your name: <input type="text" name="name" maxlength="30"></label><input type="submit">. (Source: mockup by AUWG)
- Technique B.3.5.1-2 [Advisory]: Ensuring all examples of content pass the authoring tool's own accessibility checking mechanism (see Guideline B.2.2).
- Technique B.3.5.1-3 [Advisory]: Ensuring that the documentation includes at least
one model of a wide range of WCAG Level
A accessible
authoring practices.
- Technique B.3.5.1-4 [Advisory]: Ensuring plug-ins that update the accessibility features
of a tool also update the documentation examples.
