| Guideline | Success Criteria | Implementations Info |
|---|---|---|
A.1.1 [For the authoring tool user interface] Ensure that Web-based functionality is accessible. [Techniques] Note: This guideline does not apply to non-Web-based authoring tool user interfaces. |
A.1.1.1 Web-Based "A" Accessible: Web-based authoring tool user interfaces meet the level "A" Web content accessibility benchmarks. |
|
A.1.2 [For the authoring tool user interface] Support interoperability with assistive technologies. [Techniques] Applicability Note: This guideline does not apply to Web-based authoring tool user interface functionality. |
A.1.2.1 Accessibility Platform Architecture (user interface "chrome", content display): Non-Web-based authoring user interfaces implement an accessibility platform architecture relevant to the platform. |
N/A:
|
| A.1.2.2 Accessible Alternative (user interface "chrome", content display): If any non-Web-based authoring user interface functionality is not supported by the implemented accessibility platform architecture(s), then a separate accessible alternative for that functionality that is supported by the implemented accessibility platform architecture(s) is provided and a description of the inaccessible functionality appears in the conformance claim. | N/A:
|
|
| A.1.3 [For the authoring tool user interface] Follow the accessibility conventions of the platform. [Techniques] | A.1.3.1 Follow and Cite Conventions (user interface "chrome", content display): Platform conventions are followed and the convention sources are cited for all of the following:
|
|
| A.2.1 [For the authoring tool user interface] Display text alternatives for non-text objects. [Techniques] | A.2.1.1 Editing Non-text Objects (content display): Editing views that render non-text objects contained within the content being edited can display any text alternatives that are identifiable by the authoring tool. It is permissible for the authoring tool to change editing views to display the text alternatives (e.g., from WYSIWYG to instruction level).
|
|
A.2.1.2 Non-text Objects (user interface "chrome"): Non-text objects in the "chrome" have text alternatives that present equivalent information, except for the situations listed below. [WCAG 2.0]
|
|
|
| A.2.2 [For the authoring tool user interface] Display synchronized alternatives for synchronized media. [Techniques] | A.2.2.1 Accessible Synchronized Media During Editing (content
display): Editing
views that render synchronized media contained within the content being
edited can display any synchronized
alternatives that are identifiable by the authoring tool (e.g., WYSIWYG editing views). |
|
| A.2.2.2 Captions (user interface "chrome"): If prerecorded audio is present in the user interface "chrome", then captions are provided. [WCAG 2.0] | ||
A.2.2.3 Visual Information (user interface "chrome"): If prerecorded video is present in the user interface "chrome", then at least one of the following are true: [WCAG 2.0]
|
||
| A.2.3 [For the authoring tool user interface] Ensure that the interface can be presented in different ways. [Techniques] | A.2.3.1 Name, Role, Value (user interface "chrome"): For all user interface components in the user interface "chrome", all of the following are true: [WCAG 2.0]
|
|
| A.2.3.2 Info and Relationships (user interface "chrome"): In the user interface "chrome", information, structure, and relationships conveyed through presentation is available via the platform or are available in text. [WCAG 2.0] | ||
| A.2.3.3 Purpose of Added Presentation (content display): If the authoring tool modifies the presentation of the content being edited, then the functional purpose for the modification is made available via the platform (e.g., if misspelled text is underlined, the fact that it is is misspelled is important). | ||
A.2.3.4 Access to Presentation Being Edited (content displays): If an editing view (e.g., WYSIWYG) renders any of the following text presentation properties and those properties are editable by any editing view (e.g., instruction level), then the properties is made available via the platform:
|
||
| A.2.3.5 Meaningful Sequence (user interface "chrome"): When the sequence in which user interface "chrome" components are presented affect their meaning, a correct reading sequence is available via the platform. [WCAG 2.0] | ||
| A.2.3.6 Sensory Characteristics (user interface "chrome"): Instructions provided for understanding and operating the user interface "chrome" do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation or sound. [WCAG 2.0] | ||
A.2.4 [For the authoring tool user interface] Make it easier to see and hear the interface. [Techniques] Note: While the success criteria for this guideline are based on the capabilities of the platforms (e.g., operating systems, user agents, GUI toolkits) listed in the conformance profile, additional configuration settings may be provided. |
A.2.4.1 Independence of Display (content display): Editing views that usually have their display characteristics set by rendering the content being edited (e.g., WYSIWYG editing views) allows the authors' visual and audio display settings to override these characteristics without affecting the content (e.g., markup, stylesheets, etc.) being edited. |
|
| A.2.4.2 Use of Color (user interface "chrome", content display): Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. [WCAG 2.0] |
|
|
| A.2.4.3 Audio Control (user interface "chrome", content display): If any audio plays automatically for more than 3 seconds, at least one of the following is true: | ||
A.2.4.4 Visual Display (user interface "chrome", content display): If a visual display is provided, authors can configure the visual display settings (i.e., fonts, sizes,
colors, spacing, positioning, and contrast) by at least one of the following methods:
|
|
|
A.2.4.5 Audio Display (user interface "chrome", content display): If an audio display is provided, authors can configure the audio display settings (i.e., volume, speech voices,
voice speed, and voice emphasis) by at least one of the following methods:
|
N/A:
|
|
A.3.1 [For the authoring tool user interface] Ensure that all functionality is available from a keyboard. [Techniques] Note 1: Web-based authoring tool user interface functionality may rely on the keyboard navigation functions of the user agent listed in the conformance profile to satisfy some of these success criteria. Note 2: This guideline should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation. Also see Guideline A.3.1 when choosing keystrokes. |
A.3.1.1 Keyboard (user interface "chrome", content display): Authors can, through keyboard input alone, navigate to and operate all of the functions included in the authoring tool user interface (e.g., navigating, selecting, and editing content within editing views, operating the user interface "chrome", installing and configuring the tool, and accessing documentation), except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g., freeform drawing). This applies to at least one mechanism per authoring outcome. This means non-keyboard accessible mechanisms can remain available (e.g., providing resizing with mouse-"handles" and with a properties dialog). [WCAG 2.0, UAAG 2.0] |
|
A.3.1.2 No Keyboard Trap (user interface "chrome", content display): If focus can be moved to a component with the keyboard, then at least one of the following is true:
|
|
|
| A.3.1.3 Available Keystrokes (user interface "chrome", content display): Authors can always determine the currently available keystrokes (e.g., from a central location such as a list in the help system or a distributed location such as associating shortcuts with menu items). [UAAG 2.0] | ||
| A.3.1.4 Standard Text Area Conventions (content display): Editing views that allow text entry support the standard text area conventions for the platform including, but not necessarily limited to: character keys, backspace/delete, insert, "arrow" key navigation, page up/page down, navigate to start/end, navigate by paragraph, shift-to-select mechanism, etc. |
|
|
| A.3.1.5 "Chrome" Navigation (user interface "chrome"): Authors can use the keyboard to traverse forwards/backwards all of the components, including those in floating toolbars, panels, etc. using conventions of the platform (e.g., via "tab", "shift-tab", "ctrl-tab", "ctrl-shift-tab"). [UAAG 2.0] |
|
|
| A.3.2 [For the authoring tool user interface] Enable time-independent interaction. [Techniques] | A.3.2.1 Data Saved (user interface "chrome", content display): If the authoring tool ends an authoring session due to a time limit (e.g., authenticated session expires), then the content being edited is saved. For Web-Based Authoring Tools, this applies to any content that has already been submitted to the application by the user agent. | |
| A.3.2.2 Timing Adjustable (user interface "chrome", content display): If the authoring tool is responsible for imposing a time limit on authoring sessions (e.g., to mediate collaborative authoring), then authors can extend the time limit. | ||
| A.3.2.3 Moving Targets (user interface "chrome"): If components that act as targets for authors' actions (e.g., are clickable, accept drag-and-drop actions) are capable of movement, then authors can stop that movement. | ||
| A.3.3 [For the authoring tool user interface] Help authors to avoid flashing that could cause seizures. [Techniques] | A.3.3.1 Below Threshold (user interface "chrome"): The user interface "chrome" never violates the general flash or red flash thresholds. |
|
A.3.3.2 Blinking Request (content
display): If an editing
view is capable of rendering content that explicitly requests to blink or flash (e.g. blink element), the rendering does not violate the general
flash or red flash thresholds. |
N/A:
|
|
| A.3.4 [For the authoring tool user interface] Provide navigation and editing via content structure. [Techniques] | A.3.4.1 Edit by Structure (content display): If an editing view displays a structured element set, then authors can, with a simple action, select any element in the set and perform editing functions (e.g., cut, copy, paste, presentation) on that element, its contents, and its sub-elements. |
|
A.3.7 [For the authoring tool user interface] Ensure that previews are as accessible as existing user agents. [Techniques] Note: Previews are treated differently than editing views because authors, including those with disabilities, will not be well-served if preview features diverge too much from the actual functionality of available user agents. Therefore, preview features are exempted from necessarily having to meet all of the other requirements in Part A of this guidelines document, if they meet this guideline. |
A.3.7.1 Return Mechanism (user interface "chrome"): If a preview is provided, then a mechanism for returning from the preview (i.e., moving focus back from, exiting from) is provided that meets the keyboard accessibility requirement (Guideline A.3.1) and is documented in the help system. |
|
A.3.7.2 Preview (user
interface "chrome", content
display): If a preview is
provided, then it meets at least one of
the following:
|
|
|
| A.4.2 [For the authoring tool user interface] Make functionality predictable. [Techniques] | A.4.2.1 On Focus (user interface "chrome"): When any component receives focus, it does not initiate a change of context. [WCAG 2.0] |
|
| A.4.2.2 On Input (user interface "chrome"): Changing the setting of any component does not automatically cause a change of context unless authors has been advised of the behavior before using the component. [WCAG 2.0] |
|
|
| A.4.2.3 Consistent Identification (user interface "chrome"): Components that have the same functionality within the user interface "chrome" are identified consistently. [WCAG 2.0] |
|
|
A.4.3 [For the authoring tool user interface] Help users avoid and correct mistakes. [Techniques] Note 1: Web-based authoring tool user interface functionality may rely on the "undo" function of the user agent listed in the conformance profile to perform the undo function for some editing actions that do not involve server communication (e.g., typing in a text area). Note 2: It is acceptable to collect text entry actions (e.g., typed words, a series of backspaces) into a single reversible authoring action. |
A.4.3.1 Undo Content Changes (content display): Authoring actions are either reversible by an "undo" function or include a warning to authors that the action is irreversible. The authoring tool may have certain committing actions (e.g., "save" function) that reset the undo history. |
|
| A.4.3.2 Undo Setting Changes (user interface "chrome"): Actions that modify authoring tool settings are either reversible or include a warning to the author that the setting modification is irreversible. |
|
|
| A.4.3.3 Error Identification: If an input error is detected, the component that is in error is identified and the error is described to authors in text. [WCAG 2.0] | ||
| A.4.3.4 Labels or Instructions: Labels or instructions are provided when author input is required. [WCAG 2.0] | ||
| A.4.4 [For the authoring tool user interface] Document the user interface including all accessibility features. [Techniques] | A.4.4.1 Accessible Format (user interface "chrome"): At least one version of the documentation is either:
|
|
| A.4.4.2 Document Accessibility Features (user interface "chrome"): All features (other than documentation) that are specifically required to meet Part A of these guidelines (e.g. keyboard shortcuts, text search, etc.) are documented. |
|
|
B.1.1 Support Web content technologies that enable the creation of content that is accessible. [Techniques] Applicability Note: This guideline only applies when benchmarked technologies are available for authoring the particular type of content required (e.g., text, images, synchronized media). |
B.1.1.1 Automatic Choice of "A" Technologies: If the authoring tool automatically selects Web content technologies automatically, then the selection is a level "A" benchmarked technology. |
N/A:
|
| B.1.1.2 Author Choice of "A" Technologies: If the authoring tool provides authors with technology options, level "A" benchmarked technology options are listed with at least as much prominence as any other options. |
N/A:
|
|
| B.1.2 Ensure that the authoring tool preserves accessibility information. [Techniques] | B.1.2.1 Transformation or Conversion: If the authoring tool performs transformations or conversions, then at least one of the following is true:
|
|
| B.1.3 Ensure that automatically generated content is accessible. [Techniques]
Applicability Note 1: This guidelines does apply to any accessibility problems that informed authorshave specifically allowed (e.g., by setting less strict preferences) (see Guideline B.3.3 for more on informing the author). Applicability Note 2: This guideline does not apply when authors have caused the accessibility problem(s) (e.g., by ignoring prompts for accessibility information, providing faulty information, etc.). |
B.1.3.1 Automatic "A" Accessible: If the authoring tool automatically
generates content, then that content meets the level "A" Web
content accessibility benchmarks at the conclusion of the automatic generation process (e.g., when inserted into the existing content).
|
|
| B.2.1 Prompt authors to create accessible content. [Techniques] | B.2.1.1 Prompt "A" Accessible: If authors are prompted for any information as content is being added or updated (e.g., by an image insertion dialog), then the tool also prominently prompts for any accessibility information required for that content to meet the level "A" Web content accessibility benchmarks. |
ed. Benchmark docs needed |
| B.2.1.2 Warn "A" Accessible: If an authoring action or instruction will always lead to the creation of content that cannot be made to meet the level "A" Web content accessibility benchmarks other than by making an alternative version, then a warning is displayed. | N/A:
|
|
| B.2.2 Assist authors in checking for accessibility
problems. [Techniques]
Note: While automated checking or more advanced implementations of semi-automated checking may improve the authoring experience, these are not required to meet the success criteria for this guideline. Applicability Note: This guideline does not apply if the authoring tool controls the authoring process to an extent that it is not possible for authors to introduce accessibility problems. |
B.2.2.1 Check "A" Accessibility: An individual check is associated with each level "A" Web content accessibility benchmark. |
|
| B.2.2.2 Availability: Checking is available to authors prior to the end of the authoring session. |
|
|
| B.2.2.3 Identify Range: The appropriate range (e.g., element, group of elements, entire file, etc.) for each potential accessibility problem is identified. Excessively general checks (e.g., "does the page meet all of the requirements?") are not acceptable. |
|
|
| B.2.2.4 Help Authors Decide: For any checks that require author judgment to determine whether a potential accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), instructions are provided to help authors to decide. |
|
|
| B.2.3 Assist authors in repairing accessibility
problems. [Techniques]
Note: While automated repairing or more advanced implementations of semi-automated repairing may improve the authoring experience, these are not required to meet the success criteria for this guideline. Applicability Note: This guideline does not apply if the authoring tool controls the authoring process to an extent that it is not possible for authors to introduce accessibility problems. |
B.2.3.1 Repair "A" Accessibility: For each accessibility
problem that is identifiable during checking (required
in Guideline B.2.2), repair assistance is provided for meeting the level "A" Web
content accessibility benchmarks.
|
|
B.2.4 Assist authors to manage, edit, and reuse equivalent alternatives for non-text objects. [Techniques] Note: Equivalent alternatives should not be automatically generated from unreliable sources (e.g., file names should not be used as text alternatives). |
B.2.4.1 Accept, Modify, Reject: Authors have the opportunity to accept, modify, or reject any authoring tool-supplied equivalent alternative, prior to insertion. | |
| B.2.4.2 Edit Existing: Authors can edit the equivalent alternatives for any non-text object. | ||
B.2.5 Assist authors with accessible templates and other pre-authored content. [Techniques] \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 content created through their proper use. |
B.2.5.1 Templates "A" Accessible: If the authoring tool automatically selects templates or pre-authored content, then the selection meets the level "A" Web content accessibility benchmarks when used. | |
| B.2.5.2 Provide Accessible Templates: If the authoring tool provides templates, then there are accessible template options for the full range of template uses. | ||
B.2.5.3 Template Selection Mechanism: If authors are provided with a template selection
mechanism, then both of the following are true:
|
||
| B.2.5.4 New Templates: If authors can use the authoring tool to create new templates for use by a template selection mechanism, they can record the accessibility status of the new templates. | ||
| B.2.5.5 Templates in Repository: If the authoring tool provides a repository of templates, then each of the templates has a recorded accessibility status. | ||
| B.3.1. Ensure that accessible authoring actions are given prominence. [Techniques] | B.3.1.1 At Least as Prominent: If authorsare provided with a choice of authoring actions to achieve the same mainstream rendered outcome, then actions that implement accessible authoring practices are at least as prominent as the other action(s) (e.g., text can be made bold with either style sheets or presentational markup). | |
| B.3.3. Ensure that features of the authoring tool supporting the production of accessible content are available. [Techniques] | B.3.3.1 Active by Default: All accessible content support features are active by default. | |
| B.3.3.2 Reactivate Option: If authors deactivate an accessible content support feature, then they can always reactivate the feature. | ||
| B.3.4. Ensure that features of the authoring tool supporting the production of accessible content are documented. [Techniques] | B.3.4.1 Instructions: Instructions for using the accessible content support features appear in the documentation. |
|
| Guideline | Success Criteria | Implementations Info |
|---|---|---|
A.1.1 [For the authoring tool user interface] Ensure that Web-based functionality is accessible. [Techniques] Note: This guideline does not apply to non-Web-based authoring tool user interfaces. |
A.1.1.2 Web-Based "AA" Accessible: Web-based authoring tool user interfaces meet
the level "AA" Web
content accessibility benchmarks.
| |
A.1.2 [For the authoring tool user interface] Support interoperability with assistive technologies. [Techniques] Applicability Note: This guideline does not apply to Web-based authoring tool user interface functionality. |
A.1.2.3 Deviation from Proper Use (user interface "chrome", content display): If any non-Web-based authoring user interface functionality deviates from the proper use of the implemented accessibility
platform architecture(s) (i.e., lack of use, incomplete
use, inappropriate use) as defined by the documentation for
the accessibility
platform architecture(s), this is documented with the conformance
claim.
| |
| A.1.3 [For the authoring tool user interface] Follow the accessibility conventions of the platform. [Techniques] | A.1.3.2 Follow and Cite Conventions (user interface "chrome", content display): Platform conventions are followed and the convention sources are cited for all of the following:
|
|
| A.2.2 [For the authoring tool user interface] Display synchronized alternatives for synchronized media. [Techniques] | A.2.2.4 Audio Description (user interface "chrome"): If prerecorded video is present in the user interface "chrome", then at least one of the following are true: [WCAG 2.0]
|
|
A.2.4 [For the authoring tool user interface] Make it easier to see and hear the interface. [Techniques] Note: While the success criteria for this guideline are based on the capabilities of the platforms (e.g., operating systems, user agents, GUI toolkits) listed in the conformance profile, additional configuration settings may be provided. |
A.2.4.6 Visual Configurability (user interface "chrome", content display): If the visual display settings are not inherited from the platform settings, then the authoring tool provides at least comparable configurable properties with at least comparable configuration ranges as the platform provides. | |
| A.2.4.7 Audio Configurability (user interface "chrome", content display): If the audio display settings are not inherited from the platform settings, then the authoring tool provides at least comparable configurable properties with at least comparable configuration ranges as the platform provides. | ||
| A.3.1 [For the authoring tool user interface] Ensure that all functionality
is available from a keyboard. [Techniques]
Note 1: Web-based authoring tool user interface functionality may rely on the keyboard navigation functions of the user agent listed in the conformance profile to satisfy some of these success criteria. Note 2: This guideline should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation. Also see Guideline A.3.1 when choosing keystrokes. |
A.3.1.6 Accelerator Keys (user interface "chrome"): If the authoring tool includes any of the following functions, authors can enable key-plus-modifier-key (or single-key) access to them:
|
|
| A.3.1.7 Change Accelerator Keys (user interface "chrome"): Authors can modify key-plus-modifier-key (or single-key) combinations. | ||
| A.3.4 [For the authoring tool user interface] Provide navigation and editing via content structure. [Techniques] | A.3.4.2 Navigate By Element Type (content display): If an editing view displays a structured element set, authors can move the editing focus forward/backward to the next identical or closely related (e.g., in the case of headers) element. | |
A.3.4.3 Navigate Tree Structures (content
display): If an editing
view displays a structured
element set, authors can, with a simple action, move
the editing focus from any element to
other elements in the set with any of the following
relationships (if they exist):
|
||
A.3.5 [For the authoring tool user interface] Provide text search. [Techniques] Note: Web-based authoring tool user interface functionality may rely on the "find" function of the user agent listed in the conformance profile to help perform the searches. |
A.3.5.1 Text Search (content display): A text search function is provided that can search any textual information (including text content, text alternatives for non-text objects, metadata, markup) that is editable using the authoring tool. It is permissible for the authoring tool to switch editing views to display the search results (e.g., from WYSIWYG to instruction level in order to display markup). |
|
| A.3.5.2 Bi-Directional: The search function can search backwards and forwards. [UAAG 2.0] |
|
|
| A.3.5.3 Case sensitive: The search function can search in both case sensitive and case insensitive modes. [UAAG 2.0] |
|
|
| A.3.6 [For the authoring tool user interface] Manage preference settings. [Techniques] | A.3.6.1 Save Settings (user interface "chrome"): Preference settings are stored for any of the following that the authoring tool controls (i.e., not controlled by the platform):
|
|
| A.4.2 [For the authoring tool user interface] Make functionality predictable. [Techniques] | A.4.2.4 Consistent Navigation (user interface "chrome"): Navigational mechanisms that are repeated in multiple areas of the user interface "chrome" occur in the same relative order each time they are repeated, unless a change is initiated by the authors. [WCAG 2.0] | |
| A.4.3 [For the
authoring tool user interface] Help users avoid and correct mistakes. [Techniques]
Note 1: Web-based authoring tool user interface functionality may rely on the "undo" function of the user agent listed in the conformance profile to perform the undo function for some editing actions that do not involve server communication (e.g., typing in a text area). Note 2: It is acceptable to collect text entry actions (e.g., typed words, a series of backspaces) into a single reversible authoring action. |
A.4.3.5 Redo (user interface "chrome", content display): Authors are able to immediately reverse the most recent undo(s) (i.e., a "redo" function). |
|
| A.4.3.6 Error Suggestion: If an input error is detected and suggestions for correction are known, then the suggestions are provided to authors, unless it would jeopardize security. [WCAG 2.0] | ||
B.1.1 Support Web content technologies that enable the creation of content that is accessible. [Techniques] Applicability Note: This guideline only applies when benchmarked technologies are available for authoring the particular type of content required (e.g., text, images, synchronized media). |
B.1.1.3 Automatic Choice of "AA" Technologies: If the authoring tool automatically selects Web content technologies automatically, then the selection is a level "AA" benchmarked technology. | |
| B.1.1.4 Author Choice of "AA" Technologies: If the authoring tool provides authors with technology options, level "AA" benchmarked technology options are listed with at least as much prominence as any other options. | ||
| B.1.2 Ensure that the authoring tool preserves accessibility information. [Techniques] | B.1.2.2 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:
|
|
B.1.3 Ensure that automatically generated content is accessible. [Techniques] Applicability Note 1: This guidelines does apply to any accessibility problems that informed authorshave specifically allowed (e.g., by setting less strict preferences) (see Guideline B.3.3 for more on informing the author). Applicability Note 2: This guideline does not apply when authors have caused the accessibility problem(s) (e.g., by ignoring prompts for accessibility information, providing faulty information, etc.). |
B.1.3.2 Automatic "AA" Accessible: If the authoring tool automatically
generates content, then that content meets the level "AA" Web
content accessibility benchmarks at the conclusion of the automatic generation process.
|
|
| B.2.1 Prompt authors to create accessible content. [Techniques] | B.2.1.3 Prompt "AA" Accessible: If authors are prompted for any information as content is being added or updated, then the tool also prominently prompts for accessibility information required for that content to meet the level "AA" Web content accessibility benchmarks. | |
| B.2.1.4 Warn "AA" Accessible: If an authoring action or instruction will always lead to the creation of content that cannot be made to meet the level "AA" Web content accessibility benchmarks other than by making an alternative version, then a warning is displayed. | ||
| B.2.2 Assist authors in checking for accessibility
problems. [Techniques]
Note: While automated checking or more advanced implementations of semi-automated checking may improve the authoring experience, these are not required to meet the success criteria for this guideline. Applicability Note: This guideline does not apply if the authoring tool controls the authoring process to an extent that it is not possible for authors to introduce accessibility problems. |
B.2.2.5 Check "AA" Accessibility: An individual check is associated with each level "AA" Web content accessibility benchmark. | |
| B.2.2.6 View Status: If the authoring tool records accessibility problems found during checking, then a list of any accessibility problems is available to authors prior to the end of the authoring session. |
|
|
| B.2.2.7 Save Status for Repair: If the authoring tool records accessibility problems found during checking, then authors have the option to save the list to facilitate interoperability between checking and repair. | ||
| B.2.2.8 Metadata for Discovery: If the authoring tool records accessibility status, then authors have the option to associate this status with the content as metadata to facilitate resource discovery by end users. | ||
| B.2.3 Assist authors in repairing accessibility
problems. [Techniques]
Note: While automated repairing or more advanced implementations of semi-automated repairing may improve the authoring experience, these are not required to meet the success criteria for this guideline. Applicability Note: This guideline does not apply if the authoring tool controls the authoring process to an extent that it is not possible for authors to introduce accessibility problems. |
B.2.3.2 Repair "AA" Accessibility: For each accessibility
problem that is identifiable during checking, repair assistance is provided for meeting the level
"AA" Web
content accessibility benchmarks.
|
|
B.2.4 Assist authors to manage, edit, and reuse equivalent alternatives for non-text objects. [Techniques] Note: Equivalent alternatives should not be automatically generated from unreliable sources (e.g., file names should not be used as text alternatives). |
B.2.4.3 Acceptable Sources: Authoring tools only supply equivalent alternatives from the following sources:
|
|
B.2.5 Assist authors with accessible templates and other pre-authored content. [Techniques] 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 content created through their proper use. |
B.2.5.6 Templates "AA" Accessible: If the authoring tool automatically selects templates or pre-authored content, then the selection meets the level "AA" Web content accessibility benchmarks when used. | |
B.2.5.7 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:
|
||
| 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. | ||
| B.3.2. Ensure that sequential authoring processes integrate accessible authoring practices. [Techniques] | B.3.2.1 Sequencing Features: Function that sequences authoring actions (e.g., image insertion dialogs, templates, wizards) provide any accessibility prompts relevant to the content being edited at or before the first opportunity to successfully complete the function. | |
| B.3.2.2 Sequenced Instructions: Instructions (e.g., tutorials, reference manuals, design guides) that consist of a sequence of steps for authors to follow include the relevant accessibility authoring practices in the sequence before the first opportunity to successfully complete the sequence. | ||
| B.3.3. Ensure that features of the authoring tool supporting the production of accessible content are available. [Techniques] | B.3.3.3 Deactivation Warning: If authors deactivate an accessible content support feature, then the authoring tool informs them that this may increase the risk of content accessibility problems. | |
| B.3.3.4 At Least as Prominent: Accessible content support features are at least as prominent as any corresponding features related to other types of Web content problems (e.g., invalid markup, syntax errors, spelling and grammar errors). | ||
| B.3.5. Ensure that any authoring practices demonstrated in documentation are accessible. [Techniques] | B.3.5.1 Model "A" Accessible Practice: Any examples of authoring practices in documentation (e.g., markup, screenshots of WYSIWYG editing views) demonstrate level "A" accessible authoring practices. |
| Guideline | Success Criteria | Implementations Info |
|---|---|---|
A.1.1 [For the authoring tool user interface] Ensure that Web-based functionality is accessible. [Techniques] Applicability Note: This guideline does not apply to non-Web-based authoring tool user interfaces |
A.1.1.3 Web-Based "AAA" Accessible: Web-based authoring tool user interfaces meet the level "AAA" Web content accessibility benchmarks. | |
A.1.2 [For the authoring tool user interface] Support interoperability with assistive technologies. [Techniques] Applicability Note: This guideline does not apply to Web-based authoring tool user interface functionality. |
A.1.2.4 Additional Information (user interface "chrome", content display): For non-Web-based authoring user interfaces, additional information is published describing the nature of the implementation of the accessibility platform architecture(s) (e.g., that the long description is different from the associated tool tip). | |
| A.2.2 [For the authoring tool user interface] Display synchronized alternatives for synchronized media. [Techniques] | A.2.2.5 Sign Language (user interface "chrome"): If prerecorded audio is present in the user interface "chrome", then sign language interpretation is provided. [WCAG 2.0] |
|
| A.2.2.6 Audio Description (Extended): If prerecorded video is present in the user interface "chrome", then extended audio description is provided. [WCAG 2.0] | ||
| A.2.2.7 Full Text Alternative (user interface "chrome"): If prerecorded synchronized media is present in the user interface "chrome", then full text alternative for synchronized media including any interaction is provided. [WCAG 2.0] | ||
| A.2.3 [For the authoring tool user interface] Ensure that the interface can be presented in different ways. [Techniques] | A.2.3.6 Access to Presentation Being Edited (content displays): Any text presentation properties (text size, positioning, etc.) that are rendered in an editing view (e.g., WYSIWYG editing views ) and editable by any editing view are available via the platform. | |
| A.2.4 [For the authoring tool user interface] Make it easier to see and hear the interface. [Techniques] | A.2.4.8 Low or No Background Audio (user
interface "chrome"): Audio that contains speech in the foreground does not contain background sounds, background sounds can be turned off, or background sounds are at least 20 decibels lower than the foreground speech, with the exception of occasional sound effects. Background sound that meets this requirement will be approximately one quarter as loud as the foreground speech . [WCAG 2.0]
Note: While the success criteria for this guideline are based on the capabilities of the platforms (e.g., operating systems, user agents, GUI toolkits) listed in the conformance profile, additional configuration settings may be provided. |
|
| A.3.1 [For the authoring tool user interface] Ensure that all functionality
is available from a keyboard. [Techniques]
Note 1: Web-based authoring tool user interface functionality may rely on the keyboard navigation functions of the user agent listed in the conformance profile to satisfy some of these success criteria. Note 2: This guideline should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation. Also see Guideline A.3.1 when choosing keystrokes. |
A.3.1.8 Inter-group Navigation (user interface "chrome", content display): If logical groups of focusable components (e.g., toolbars, dialogs, labeled groups, panels) are present, authors can use the keyboard to navigate to a focusable component in the next and previous groups. [UAAG 2.0]
|
|
| A.3.1.9 Group Navigation (user interface "chrome", content display): If logical groups of focusable components are present, authors can use the keyboard to navigate to the first, last, next and previous focusable component within the current group. [UAAG 2.0] | ||
| A.3.2 [For the authoring tool user interface] Enable time-independent interaction. [Techniques] | A.3.2.4 No Time Limits: The authoring tool does not impose time limits on authoring sessions. | |
| A.3.3 [For the authoring tool user interface] Ensure that authors can avoid flashing that could cause seizures. [Techniques] | A.3.3.3 Three Flashes (user interface "chrome"): No part of the user interface "chrome" ever flashes more than three times in any one second period. [WCAG 2.0] | |
| A.3.6 [For the authoring tool user interface] Manage preference settings. [Techniques] | A.3.6.2 Multiple Sets (user interface "chrome"): 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):
|
|
A.3.6.3 Options Wizard (user interface "chrome"): Authors are provided with an accessibility option-setting "wizard" to configure options related to Part A. |
||
| A.4.1 Make text content readable and understandable. | A.4.1.1 Unusual Words (user interface "chrome"): A mechanism is provided for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon. [WCAG 2.0] | |
| A.4.1.2 Abbreviations (user interface "chrome"): A mechanism is provided for finding the expanded form or meaning of abbreviations. [WCAG 2.0] | ||
| A.4.2 [For the authoring tool user interface] Make functionality predictable. [Techniques] | A.4.2.5 Change on Request (user interface "chrome", content display): Changes of context are initiated only by authors' request. [WCAG 2.0] | |
A.4.3 [For the authoring tool user interface] Help users avoid and correct mistakes. [Techniques] Note 1: Web-based authoring tool user interface functionality may rely on the "undo" function of the user agent listed in the conformance profile to perform the undo function for some editing actions that do not involve server communication (e.g., typing in a text area). Note 2: It is acceptable to collect text entry actions (e.g., typed words, a series of backspaces) into a single reversible authoring action. |
A.4.3.7 Multiple Undos (user interface "chrome", content display): Authors can reverse at least 5 consecutive reversible actions. | |
B.1.1 Support Web content technologies that enable the creation of content that is accessible. [Techniques] Applicability Note: This guideline only applies when benchmarked technologies are available for authoring the particular type of content required (e.g., text, images, synchronized media). |
B.1.1.5 Automatic Choice of "AAA" Technologies: If the authoring tool automatically selects Web content technologies automatically, then the selection is a level "AAA" benchmarked technology. | |
| B.1.1.6 Author Choice of "AAA" Technologies: If the authoring tool provides authors with technology options, level "AAA" benchmarked technology options are listed with at least as much prominence as any other options. | ||
| B.1.3 Ensure that automatically generated content is accessible. [Techniques]
Applicability Note 1: This guidelines does apply to any accessibility problems that informed authorshave specifically allowed (e.g., by setting less strict preferences) (see Guideline B.3.3 for more on informing the author). Applicability Note 2: This guideline does not apply when authors have caused the accessibility problem(s) (e.g., by ignoring prompts for accessibility information, providing faulty information, etc.). |
B.1.3.3 Automatic "AAA" Accessible: If the authoring tool automatically
generates content, then that content meets the level "AAA" Web
content accessibility benchmarks at the conclusion of the automatic generation process.
|
|
| B.2.1 Prompt authors to create accessible content. [Techniques] | B.2.1.5 Prompt "AAA" Accessible: If authors are prompted for any information as content is being added or updated, then the tool also prominently prompts for accessibility information required for that content to meet the level "AAA" Web content accessibility benchmarks. | |
| B.2.1.6 Warn "AAA" Accessible: If an authoring action or instruction will always lead to the creation of content that cannot be made to meet the level "AAA" Web content accessibility benchmarks other than by making an alternative version, then a warning is displayed. | ||
B.2.2 Assist authors in checking for accessibility problems. [Techniques] Note: While automated checking or more advanced implementations of semi-automated checking may improve the authoring experience, these are not required to meet the success criteria for this guideline. Applicability Note: This guideline does not apply if the authoring tool controls the authoring process to an extent that it is not possible for authors to introduce accessibility problems. |
B.2.2.9 Check "AAA" Accessibility: An individual check is associated with each level
"AAA" Web
content accessibility benchmark.
|
|
B.2.3 Assist authors in repairing accessibility problems. [Techniques] Note: While automated repairing or more advanced implementations of semi-automated repairing may improve the authoring experience, these are not required to meet the success criteria for this guideline. Applicability Note: This guideline does not apply if the authoring tool controls the authoring process to an extent that it is not possible for authors to introduce accessibility problems. |
B.2.3.3 Repair "AAA" Accessibility: For each accessibility
problem that is identifiable during checking, repair assistance is provided for meeting the level
"AAA" Web
content accessibility benchmarks.
| |
B.2.4 Assist authors to manage, edit, and reuse equivalent alternatives for non-text objects. [Techniques] Note: Equivalent alternatives should not be automatically generated from unreliable sources (e.g., file names should not be used as text alternatives). |
B.2.4.4 Save for Reuse: Authors can store, for future reuse, both of the following author-assigned equivalent alternatives (as applicable):
|
|
B.2.5 Assist authors with accessible templates and other pre-authored content. [Techniques] 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 content created through their proper use. |
B.2.5.9 Templates "AAA" Accessible: If the authoring tool automatically select templates or pre-authored content, then the selection meets the level
"AAA" Web
content accessibility benchmarks when used.
| |
| B.3.1. Ensure that accessible authoring actions are given prominence. [Techniques] | B.3.1.2 Higher Prominence: If authors are provided with a choice of authoring actions to achieve the same mainstream rendered outcome, then actions that implement accessible authoring practices are more prominent than the other action(s). | |
| B.3.4. Ensure that features of the authoring tool supporting the production of accessible content are documented. [Techniques] | B.3.4.2 Accessible Authoring Tutorial: A tutorial on the accessible authoring process that is specific to the authoring tool is provided. |
Tool Descriptions:
TinyMCE v2.0+ (XHTML 1.0) : Info provided by Greg Gay
DreamWeaver MX2004 with LIFT (XHTML 1.0) : Observation by Jan Richards
XStandard 2.1 (XHTML 1.0) : Info provided by Vlad Alexander, Roberto Scano
A-Checker (XHTML 1.0) : Info provided by Greg Gay