W3C

ATAG 2.0 Implementtion Report

DD MMM YYYY

Editors:
 
Jan Richards - ATRC, University of Toronto

Rating Information

Rating Scale
C: Complete Implementation
AC: Almost Complete Implementation, almost all requirements satisfied or bugs need to be fixed
PI: Partial Implementation, some requirements satisfied
NI: Not Implemented
NR: Not Rated
NA: Not Applicable

Implementations by Checkpoints and Success Criteria

"Relative Priority" Checkpoints

Checkpoint Highest
Checkpoint
Rating		 Success Criteria Highest
Success Criteria
Rating		 Implementations Info
A.0.1 For the authoring tool user interface, ensure that Web-based functionality conforms to WCAG.   1. All Web-based authoring tool user interface functionality must conform to WCAG.  
  • RP-Level 1: TinyMCE v.???+
B.1.4 Ensure that when the authoring tool automatically generates content it conforms to WCAG.   1. All content that is automatically generated by the authoring tool (i.e., not authored "by hand") must conform to WCAG.  
  • NOT SURE: Up to RP-Level ???: TinyMCE v.???+ (small scale generation - styling etc.)
B.1.5 Ensure that all pre-authored content for the authoring tool conforms to WCAG.   1. Any content (e.g., templates, clip art, example pages, graphical widgets) that is bundled with the authoring tool or preferentially licensed to the users of the authoring tool (i.e., provided for free or sold at a discount) must conform to WCAG when used by the author.    
B.2.1 Prompt and assist the author to create content that conforms to WCAG.   1. The authoring tool must provide an option to notify the author when content is added or updated, that requires accessibility information from the author to conform to WCAG (e.g., using a dialog box, using interactive feedback).  
  • XHTML 1.0: TinyMCE
2. Instructions provided to the author by the authoring tool must (if followed) meet one of the following:    

B.2.2 Check for and inform the author of accessibility problems.

Note: This checkpoint does not apply to authoring tools that constrain authoring choice to such a degree that it is not possible to create content that does not conform to WCAG.

  

1. An individual check must be associated with each requirement in the content type-specific WCAG benchmark document (i.e., not blanket statements such as "does the content meet all the requirements").

  
  • RP-Level 1 only: XHTML 1.0: A-Checker (note: more than half the tests are manual)
2. For checks that are associated with a type of element (e.g., img), each element instance must be individually identified as potential accessibility problems. For checks that are relevant across multiple elements (e.g., consistent navigation) or apply to most or all elements (e.g., background color contrast, reading level), the entire span of elements must be identified as potential accessibility problems, up to the entire content if applicable.  
  • Up to RP-Level 3: XHTML 1.0: A-Checker
3. If the authoring tool relies on author judgment to determine if a potential accessibility problem is correctly identified, then the message to the author must be tailored to that potential accessibility problem (i.e., to that requirement in the context of that element or span of elements).  
  • Up to RP-Level 3: XHTML 1.0: A-Checker
4. The authoring tool must present checking as an option to the author at or before the completion of authoring.  
  • FrontPage 2003
  • DreamWeaver MX2004 with LIFT
  • TinyMCE (accessible version)
B.2.3 Assist authors in repairing accessibility problems.   1. For each potential accessibility problem identified by the checking function (required in Checkpoint B.2.2), at least one of the following must be provided:  
  • Up to RP-Level 3: XHTML 1.0: A-Checker (note: satisfies (a) - the manual requirement, rather than (b) )

"Regular Priority" Checkpoints

Priority 1 Checkpoints

Checkpoint Highest
Checkpoint
Rating		 Success Criteria Highest
Success Criteria
Rating		 Implementations Info

A.1.1 For the authoring tool user interface, provide text alternatives for all non-text objects.

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

  1. All editing interface non-text objects that are used to convey information (e.g., toolbar icon, graphical depiction of a tag, sound effect) must have a text alternative (e.g., alternative text label, long text description).  
  • XHTML 1.0: TinyMCE
2. The author must have the option to access an accessible multimedia alternative to any multimedia in the editing interface.    
3. All editing views must always include an option to display any available text alternatives for non-text objects in the content being edited.  
  • XHTML 1.0: DreamweaverMX2004
  • XHTML 1.0: TinyMCE

A.1.3 For the authoring tool user interface, ensure that all display preferences are configurable.

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

   1. If the visual display (e.g. fonts, sizes, colors, spacing, positioning) is controlled by the authoring tool rather than by the platform, then the authoring tool must provide at least the same configurable properties with at least the same configuration ranges as the platform.    
2. If the audio display (e.g. volume, speech voices) is controlled by the authoring tool rather than by the platform, then the authoring tool must provide at least the same configurable properties with at least the same configuration ranges as the platform.    
3. Editing views that have their display characteristics set by rendering the content being edited (e.g., WYSWYG editing views) must override these characteristics if the author explicitly sets visual or audio display preferences as described in the previous two success criteria.    
4. Any visual or audio display settings must be saved between authoring sessions.    
A.1.4 For the authoring tool user interface, ensure changes to the display settings of editing views do not affect the content being edited.   1. The author must be able to configure the display settings of editing views without affecting the content being edited.  
  • ??

A.1.5 For the authoring tool user interface, ensure that information, functionality, and structure can be separated from presentation.

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

  1. For rendered editing views (e.g., WYSIWYG editing view), all characteristics of the presentation (e.g., color, boldness, positioning) must be available programmatically.    
2. For authoring tool-controlled presentation in editing views (e.g., coloring misspelled words, identifying tag text in a code-level view), the semantic description of the presentation must be available programmatically.    
3. For the presentation of controls within the editing interface (e.g., dialog boxes, menus, button bars, user interface controls in the editing view), the semantic description of the presentation (e.g., "paragraph tag" instead of "blue-colored <p>") must be available programmatically.    
4. Any information that is conveyed by color (e.g., different colored underlines to indicate spelling and grammar errors) must meet at least one of the following:
  • visually evident when color is not available (e.g., by the shape of the underlining), or
  • provided by an alternative version that meets Part A (e.g., spelling and grammar checking utilities that provide the same functionality as the colored underline).
    

A.2.1 For the authoring tool user interface, ensure that all functionality is operable via a keyboard or a keyboard interface.

For Web-based authoring tool user interface functionality: Meeting Checkpoint A.0.1 will serve to meet success criteria 1 and 2 of this checkpoint. User agent functionality (e.g., for "cut/copy/paste") or access keys (e.g., for "open new content") may be relied on to achieve success criteria 3 and 4 as long as the applicable user agent(s) are specified in the conformance profile.

   1. The author must be able, through keyboard input alone, to perform any authoring task that is available through the authoring tool user interface (e.g., navigating, selecting, and editing content within editing views, operating the editing interface, installing and configuring the tool, and accessing documentation), except freeform drawing. This applies to at least one mechanism per task, allowing non-keyboard accessible mechanisms to remain available (e.g., inserting an image with an "insert image" menu item vs. drag-and-dropping the image file's icon into the document).    
2. The author must have the option to ensure that selection is separate from activation (e.g., navigating through the items in a dropdown menu without activating any of the items).    
3. The author must have the option to enable single-key access to both of the following functionalities:
  • (a) move content focus to the next enabled control in the editing interface (e.g., using "tab" key), and
  • (b) navigate forward and backward within editing views (e.g., using "arrow" keys).
 
  • Dreamweaver MX2004
4. The author must have the option to enable key-plus-modifier-key (or single-key) access to all of the following functionalities (if present):
  • (a) move content focus to the previous enabled control (e.g., using "shift-tab" key),
  • (b) navigate between panels or windows,
  • (c) open help system,
  • (d) open new content,
  • (e) open existing content,
  • (f) save content,
  • (g) close content,
  • (h) cut/copy/paste,
  • (i) undo/redo,
  • (j) open find/replace function, and
  • (k) navigate to the start and end of the content being edited.
  
  • Dreamweaver MX2004
5. Any keyboard operability settings must be saved between authoring sessions.  
  • Dreamweaver MX2004
6. The current keyboard settings must be available to the author at all times (e.g. in either a central location such as a list, or a distributed location such as associating shortcuts with menu items).  
  • Dreamweaver MX2004

A.2.3 For the authoring tool user interface, allow authors to control time limits.

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

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

A.2.4 For the authoring tool user interface, allow authors to avoid flashing that could cause seizures due to photosensitivity.

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

   1. If flashing occurs in any part of the user interface (e.g., within a WYSIWYG editing view) that violates international health and safety standards for general flash or red flash, then the author must be able to do at least one of the following:
  1. the author is able to deactivate the flashing, or
  2. the author is able to adjust the rate of flashing so that it no longer violates international health and safety standards for general flash or red flash
    
A.3.3 For the authoring tool user interface, document the user interface including all accessibility features.   1. At least one version of the documentation must conform to the minimum requirements (e.g., "Level A") of WCAG.    
2. All features from Part A that benefit the accessibility of the editing interface must be documented (e.g., keyboard shortcuts).    

A.4.1 For the authoring tool user interface, support interoperability with assistive technologies.

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

 

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

    
2. All of the following information must be published about the implementation of the accessibility platform architecture(s):
  • (a) Specify if only the default support is provided.
  • (b) Otherwise, provide information (e.g., accessible name, accessible description, accessible role) for each GUI component that can receive focus, as defined by the accessibility architecture used.
  • (c) Detail any deviation from their proper use (i.e., lack of use, incomplete use, inappropriate use) as defined by the documentation for the accessibility platform architecture.
    
3. If there is any authoring tool user interface functionality that is not supported by the relevant accessibility platform architecture(s), then at least one of the following must be done:
  • (a) provide an accessible equivalent for the functionality that is supported by the relevant accessibility platform architecture(s).
  • (b) provide an alternative interoperability mechanism with published documentation so that the functionality would be available to an assistive technology implementing the mechanism.
  • (c) describe the inaccessible functionality in the conformance claim.
    
B.1.1 Support content types that enable the creation of content that conforms to WCAG.   1. Any authoring tool that chooses the content type used for publication on the Web for the author must always choose content types for which a published content type-specific WCAG benchmark document exists.  
  • XHTML 1.0: Dreamweaver MX2004
  • MS FrontPage 2003
  • once we put in place the CTSWB
2. Any authoring tool that allows authors to choose the content type used for publication on the Web must always support at least one content type for which a published content type-specific WCAG benchmark document exists and must always give prominence to those content types.    
B.1.2 Ensure that the authoring tool preserves accessibility information during transformations and conversions.   1. During all transformations and conversions supported by the authoring tool, accessibility information must always be handled according to the following:    
B.2.4 Assist authors to ensure that equivalent alternatives for non-text objects are accurate and fit the context.   1. If the authoring tool offers text alternatives for non-text objects, then the source of the alternatives for each object must be at least one of the following: (Text alternatives should not be generated from unreliable sources. File names are generally not acceptable, although in some cases they will be (e.g., if they store alternatives previously entered by authors))    
2. The authoring tool must allow the author to accept, modify, or reject equivalent alternatives.    
B.3.5 Document features of the authoring tool that support the production of accessible content.   1. All accessible content support features must be documented in the help system.    

Priority 2 checkpoints

Checkpoint Highest
Checkpoint
Rating		 Success Criteria Highest
Success Criteria
Rating		 Implementations Info

A.1.2 For the authoring tool user interface, provide synchronized alternatives for multimedia.

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

 

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

    
2. All editing views must always include an option to display any available synchronized alternatives for multimedia in the content being edited.    
A.2.5 For the authoring tool user interface, ensure that editing views enable the author to navigate the structure and perform structure-based edits.   1. If editing content that is a structured element set, the author must always be able to move the editing focus from any element to other elements in the set with any of the following relationships (if they exist):
  • (a) the element immediately above (i.e., parent),
  • (b) the first element immediately below (i.e., child),
  • (c) the element immediately preceding at the same level (i.e., previous sibling), and
  • (d) the element immediately following at the same level (i.e., next sibling).
   
2. If editing content that is a structured element set, the author must be able to select any element in the set and perform editing functions (e.g., cut, copy, paste, presentation) on that element, its contents, and its sub-elements.    

A.2.6 For the authoring tool user interface, allow the author to search content, including markup, within the editing views.

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

  

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

    
2. The author must be able to perform text searches of all markup that is editable by the author.    

A.2.7 For the authoring tool user interface, provide an undo function.

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

  

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

    
2. The author must be able to perform consecutive undos up to at least five reversible actions or until an irreversible action or committing action is reached.    
3. The author must be able to immediately reverse the most recent undos (i.e., a "redo" function).    
A.2.8 For the authoring tool user interface, allow the author to have multiple sets of keyboard operability and display preferences settings.   1. The author must be able to save and reload sets of preferences (e.g., personal profiles, personal settings), where each set contains preference settings related to the following (if present):
  • (a) keyboard operability (unless keyboard operability preferences are controlled by the platform),
  • (b) visual display (unless the visual display (e.g., fonts, sizes, colors, spacing, positioning) is controlled by the platform), and
  • (c) audio display (unless the audio display (e.g., volume, speech voices) is controlled by the platform).
    
A.2.9 For the authoring tool user interface, ensure previews emulate the accessible rendering features of target user agents.   1. If a preview feature is provided, then a mechanism of returning from the preview (i.e., moving focus back from, exiting from) must be provided that meets Checkpoint A.2.1 and is documented in the help system.    
2. If a preview is provided, then it must meet at least one of the following:
  • (a) the preview makes use of an existing user agent (e.g., a third-party browser or browser component), or
  • (b) the preview meets all of the checkpoints in Part A.
    

A.3.1 For the authoring tool user interface, observe the accessibility conventions of the platform.

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

  1. Focus and selection conventions for the current platform (specified in the conformance profile) must be followed.    
2. Keyboard accessibility configuration conventions (e.g., default accelerator key bindings) for the platform (specified in the conformance profile) must be followed.    

A.3.2 For the authoring tool user interface, maintain consistency.

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

  1. Editing interface controls that are identified by the same text label or icon must always perform the same function.    
2. When the same function (e.g., saving, running a checker or canceling an action) is available in multiple places within the editing interface (e.g., on multiple windows), at least one method of controlling the function must be available in each place using the same text label or icon.    
B.1.3 Ensure that the author is notified before content is automatically removed.   1. The authoring tool must provide an option to notify the author before permanently removing content using an automatic process.    
B.2.7 Document in the help system all features of the tool that support the production of accessible content.   1. All features that play a role in creating accessible content must be documented in the help system.    
B.3.1 Ensure that the most accessible option for an authoring task is given priority.   1. When the author has more than one authoring option for a given task (e.g. emphasizing text using semantic markup rather than inappropriately using header markup), then any options that conform to WCAG must have equal or higher prominence than any options that do not.    
2. Any choices of content types or authoring option presented to the author (e.g., in menus, toolbars or dialogs) that will lead to the creation of content that does not conforms to WCAG must be marked or labeled so that the author is aware of the consequences prior to making the choice.    
B.3.2 Ensure that sequential authoring processes integrate accessible authoring practices.   1. Interactive features that sequence author actions (e.g., object insertion dialogs, templates, wizards) must provide any accessibility prompts relevant to the content being authored at or before the first opportunity to successfully complete the interactive feature.    
2. For read-only instruction text (e.g., tutorials, reference manuals, design guides) that includes a sequence of steps for the author to follow, the relevant accessibility authoring practices must appear in the step sequence before the first opportunity to successfully complete the sequence.    
B.3.3 Ensure that features of the authoring tool that support the production of accessible content are prominent in the user interface.   1. All accessible content support features must match or exceed the prominence of any corresponding features related to other classes of Web content problems (e.g., markup validity, program code syntax, spelling and grammar).  
  • XHTML 1.0: TinyMCE

Priority 3 checkpoints

Checkpoint Highest
Checkpoint
Rating		 Success Criteria Highest
Success Criteria
Rating		 Implementations Info
A.2.2 For the authoring tool user interface, ensure author configurable access to selectable items.  

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

    
 

2. There must be at least one editing interface area in which selectable items can be activated by a single action (e.g., toolbar, palette), where both of the following are true:

  • (a) the author can change the order of the items, and
  • (b) the author can select which items are available from the set of all selectable items.
    

A.4.2 For the authoring tool user interface, document how the authoring interface makes use of existing accessibility architectures.

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

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

 

    
B.2.5 Provide functionality for managing, editing, and reusing equivalent alternatives.   1. The authoring tool must have the option of storing for future re-use the following author added equivalent alternatives for non-text objects (if applicable):    
B.2.6 Provide the author with a summary of accessibility status.   1. The authoring tool must provide an option to view a list of all known accessibility problems (i.e., detected by automated checking or identified by the author) prior to completion of authoring.  
  • XHTML 1.0: A-Checker
B.2.7 Provide the author with a tutorial on the process of accessible authoring.   1. The authoring tool must provide a tutorial on the accessible authoring process that is specific to the tool.  
  • XHTML 1.0: TinyMCE
B.3.4 Ensure that features of the authoring tool that support the production of accessible content are configurable.  

1. All accessible content support features must be turned on by default.

  
  • XHTML 1.0: TinyMCE
  2. If the author does turn off an accessible content support feature, then the authoring tool must inform the author that this may increase the risk of content accessibility problems.    
  3. If the author does turn off an accessible content support feature, then the author must always have the option to turn the feature back on again.    
  4. The accessible content support feature settings must be saved between authoring sessions.    
B.3.6 Ensure that any authoring practices demonstrated in repair instructions and documentation are accessible.   1. All examples of markup and screenshots of the authoring tool user interface that appear in the documentation and repair instructions must demonstrate accessible Web content, with the exception of examples specifically intended to show inaccessible practices which must be avoided.    

Tool Descriptions

TinyMCE: