W3C

ATAG 2.0 Implementation 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

Authoring Tools

@@IMPORTANT NOTES:

Handle Details Notes and URIs Contributor(s)
Lotus Tools     Sueann N.
Amaya     Jeanne Spellman
Dreamweaver CS5    

Greg Pisocky

Acrobat 9     Greg Pisocky
Defacto CMS Web application http://www.nomensa.com/web-design/defacto-content-management-system Alastair Campbell
TinyMCE3.2
  • TinyMCE v.3.2.x
  • with Accessibility plugin
  • producing XHTML 1.0
  • tested on IE8

 
  • Base application (http://tinymce.moxiecode.com/download.php)
  • Accessibility plugin (http://wiki.moxiecode.com/index.php/TinyMCE:Accessibility)
Jan Richards
Google Docs (Text) - 13Aug2010 HTML I looked at Google Docs but it seems to have quite a few issues (no keyboard access to menus, no ability to add alt, longdesc, no table captions, equations become images, real headings are not used, etc., etc.). Jan Richards
Drupal, Moodle, SAKAI ???     ???
DreamWeaver8 Producing HTML4   Jan Richards
Flash8 Producing Flash   Jan Richards
XStandard2.1 XStandard 2.1 used to produce XHTML 1.0   Vlad Alexander, Roberto Scano
WebAIM WAVE Checking HTML4 http://wave.webaim.org/ Jan Richards
AChecker Checking HTML4 http://achecker.ca/ Greg Gay, Jan Richards
Office2010   http://blogs.technet.com/office2010/archive/2010/01/07/office-2010-accessibility-investments-document-accessibility.aspx Jan Richards

Implementations by Checkpoints and Success Criteria

Applicability Notes:

For PART A: Make the authoring tool user interface accessible:

  1. 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 content being edited, such as menus, button bars, status bars, user preferences, documentation, etc.
  2. Reflected web 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 a text alternative in the 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 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.
  3. 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. If a conformance claim is made, the claim cites the user agent.
  4. Features for meeting Part A must be accessible: The Part A success criteria apply to the entire authoring tool user interface, including any features added to meet the success criteria in Part A (e.g., documentation, search functions, etc.). The only exemption is for preview features, as long as they meet Guideline A.3.7. Previews are treated differently than editing views because all authors, including those with disabilities, benefit when preview features accurately reflect the actual functionality of user agents.

For PART B: Support the production of accessible content :

  1. Author availability: Any Part B success criteria that refer to authors only apply during authoring sessions.
  2. Applicability after the end of an authoring session: For author-generated content, the requirements of Part B only apply during authoring sessions. For example, if the author includes a third-party feed in their web content, the authoring tool is not required to provide checking for web content accessibility problems in that feed after the end of the authoring session. In contrast, for automatically-generated content, Part B continues to apply after the end of the authoring session. For example, if the site-wide templates of a content management system are updated, these would be required to meet the accessibility requirements for automatically-generated content.
  3. Authoring systems: As per the ATAG 2.0 definition of authoring tool, several software tools (identified in any 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).
  4. Features for meeting Part B must be accessible: The Part A success criteria apply to the entire authoring tool user interface, including any features added to meet the success criteria in Part B (e.g., checking tools, repair tools, tutorials, documentation, etc.).
  5. Multiple author roles: Some authoring tool include multiple author roles, each with different views and content editing permissions (e.g., a content management system may separate the roles of designers, content authors, and quality assurers). In these cases, the Part B success criteria apply to the authoring tool as a whole, not to the view provided to any particular author role.

Numbers of Implementations

Level A Success Criteria

Guideline Success Criteria Implementations Info
A.1.1 [For the authoring tool user interface] Ensure that web-based functionality is accessible. A.1.1.1 Web-Based Accessible (WCAG Level A): Web-based authoring tool user interfaces conform to WCAG 2.0 Level A.
  • @Several
    • TinyMCE3.2
    • Defacto CMS
  • MoodleLMS?, DrupalCMS?, ATutorLCMS?
A.1.2 [For the authoring tool user interface] Ensure that non-web-based functionality is accessible. A.1.2.1 Non-Web-Based Accessible: Non-web-based authoring tool user interfaces follow accessibility standards and/or platform conventions that support accessibility.
Note: If a conformance claim is made, the claim cites the accessibility standards and/or platform conventions that were followed.
  • @At-least-one
    • XStandard2.1 (MSAA support)
  • iPhone apps? Annotate (Steve H)? MS2010?
A.2.1 [For the authoring tool user interface] Make alternative content available to the author. A.2.1.1 Recognized Alternative Content: If recognized alternative content is available for editing view content renderings, then the alternative content is provided to authors.
  • @Several
    • TinyMCE3.2 (via browser)
    • DreamWeaver8
    • XStandard2.1
    • Defacto CMS
  • MoodleLMS?, DrupalCMS?, ATutorLCMS?
A.2.2 [For the authoring tool user interface] Editing view presentation can be programmatically determined. A.2.2.1 Purpose of Added Presentation: If an editing view modifies the presentation of web content to provide additional information to authors, then that additional information can be programmatically determined.
  • @At-least-one
    • WAVE (adds information icons throughout the checked webpage)
  • XMetal? Office2010 spelling?
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 those properties can be programmatically determined:
(a) Text Font; and
(b) Text Style (e.g., italic, bold); and
(c) Text Color; and
(d) Text Size.
  • @At-least-one
    • TinyMCE3.2 (via browser)
  • MoodleLMS?, DrupalCMS?, ATutorLCMS? (note: Use MSAA Inspect tool to test on Windows)
A.2.3: Ensure the independence of the authors' display preferences. A.2.3.1 Independence of Display: Authors can set their own display settings for editing views (including WYSIWYG views) without affecting the web content to be published.
  • @Many
    • TinyMCE3.2 (since browser display settings are used)
    • Defacto CMS (via browser display settings)
    • XStandard2.1
    • DreamWeaver8
    • GoogleDocs
A.3.1 [For the authoring tool user interface] Provide keyboard access to authoring features. A.3.1.1 Keyboard Access (Minimum): All functionality of the authoring tool is operable through a keyboard interface, except where editing web content properties that encode continuous input.
Note 1: This exception relates to the nature of web content, not the usual input technique. For example, setting the path of a freehand curve is exempt, while setting the endpoints of a straight line is not.
Note 2: This should not be interpreted as discouraging mouse input or other input methods in addition to the keyboard interface.
  • @Several
    • TinyMCE3.2
    • Dreamweaver8
    • Defacto CMS
    • MS2010? AtutorLCMS? Sakai3.0?
A.3.1.2 No Content Keyboard Traps: Keyboard traps are prevented as follows:
(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 Web Content: If an editing view renders web content (e.g., WYSIWYG view), then a documented keyboard command is provided that will always restore keyboard focus to a known location (e.g., the menus).
  • @Several
    • TinyMCE3.2 (relying on browser for (b))
    • Dreamweaver8
    • Flash8
    • Defacto CMS
  • MoodleLMS?, DrupalCMS?, ATutorLCMS? (relying on browser for (b))
A.3.2 [For the authoring tool user interface] Provide authors with enough time. A.3.2.1 Data Saved (Minimum): If the authoring tool includes authoring session time limits, then the authoring tool saves all submitted content edits made by authors.
  • @At-least-one
    • TinyMCE3.2
    • ATutorLCMS (Scorm mode?)? DrupalCMS? MoodleLMS? Wikis?
A.3.2.2 Timing Adjustable: If a time limit is set by the authoring tool, then at least one of the following is true:
(a) Turn Off: Authors are allowed to turn off the time limit before encountering it; or
(b) Adjust: Authors 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: Authors are warned before time expires and given at least 20 seconds to extend the time limit with a simple action (e.g., "press the space bar"), and authors 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.
  • @None-confirmed
    • ATutorLCMS (Scorm mode?)?
    • DrupalCMS?MoodleLMS? Wikis?
A.3.2.3 Static Pointer Targets: User interface components that accept pointer input are either stationary or authors can pause the movement.
  • @Many
    • MS2010
    • Dreamweaver8
    • Acrobat
    • etc.
A.3.3 [For the authoring tool user interface] Help authors avoid flashing that could cause seizures. A.3.3.1 Static View Option: Rendering of time-based content (e.g., animations) in editing views can be turned off.
  • @At-least-one
    • Flash8 (Timeline only plays on user request)
  • Maybe some web-based tools if rendering of dynanic objects turned off in browser
A.3.4 [For the authoring tool user interface] Enhance navigation and editing via content structure. A.3.4.1 Edit by Structure: Editing views for structured web content include editing mechanism(s) that can make use of the structure.
  • @Several
    • TinyMCE3.2 (using "Path" feature)
    • DreamWeaver8
  • Amaya? (JS)
A.3.4.2 Navigate By Structure: Editing views for structured web content include navigation mechanism(s) that can make use of the structure.
  • @Several
    • TinyMCE3.2 (using "Path" feature)
    • DreamWeaver8 ("Edit>Select Parent Tag", "Edit>Select Child")
  • Amaya? (JS)
A.3.7 [For the authoring tool user interface] Ensure that previews are as accessible as existing user agents. A.3.7.1 Return Mechanism: If a preview is provided, then authors can return from the preview using only keyboard commands.
  • @Many
    • TinyMCE3.2 (by switching browser windows)
    • DreamWeaver8 (by switching applications)
  • Amaya? (JS) ATutorLCMS?
A.3.7.2 Preview: If a preview is provided, then at least one of the following is true:
(a) Third-Party User Agent: The preview makes use of an existing third-party user agent; or
(b) UAAG (Level A): The preview conforms to the User Agent Accessibility Guidelines Level A [UAAG].
  • @Many (by (a))
    • XStandard2.1 (by (a))
    • TinyMCE3.2 (by (a))
    • DreamWeaver8 (by (a))
    • ATutorLCMS? (by (a))
  • Amaya? (JS)
A.4.1 [For the authoring tool user interface] Help users avoid and correct mistakes. A.4.1.1 Undo Content Changes: Authoring actions are either reversible by an "undo" function or include a warning to the authors that the action is irreversible.
Note 1: It is acceptable to collect a series of 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.
  • @Many
    • XStandard2.1
    • TinyMCE3.2
    • DreamWeaver8 ("Edit>Undo")
    • Defacto CMS (warns before deleting content)
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.
  • @Many
    • XStandard2.1
    • DreamWeaver8 (all settings are reversible)
A.4.2 [For the authoring tool user interface] Document the user interface including all accessibility features. 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.
  • @At-least-one
    • MS2010
  • DreamWeaver8?
B.1.1 Support web content technologies that enable the creation of content that is accessible. B.1.1.1 Accessible Content Production (WCAG Level A): Authors can use the authoring tool to produce web content that conforms to WCAG 2.0 Level A.
  • @Many
    • XStandard2.1
    • TinyMCE3.2
    • DreamWeaver8
    • Defacto CMS (Partly via TinyMCE, partly via templates)
B.1.2 Ensure that the authoring tool preserves accessibility information. B.1.2.1 Preserve Accessibility Information (Minimum): Any accessibility information (WCAG 2.0 Level A) recognized in the input to any web content transformation is preserved as accessibility information in the output, if allowed by the web content technology of the output.
  • @Several
    • Atutor (transformations from IEEE LOM to SCORM package etc.)
    • Acrobat (when exporting PDF from MS Word format)
  • TinyMCE when copying from MS Word? Final Cut Pro preserving captions?
B.1.2.2 End Product Cannot Preserve Accessibility Information: If the web content technology of the output of a web content transformation cannot preserve recognized accessibility information (WCAG 2.0 Level A) (e.g., saving a structured graphic to a raster image format), then at least one of the following are true:
(a) Option to Save: Authors have the option to save the accessibility information in another way (e.g., as a "comment", as a backup copy of the input); or
(b) Warning: Authors are warned that this will result in web content accessibility problems in the output.
  • @Many (by (a))
    • ...

 

B.1.3 Ensure that automatically generated content is accessible. B.1.3.1 Accessible Auto-Generated Content (WCAG Level A): If the authoring tool automatically generates content, then that web content conforms to WCAG 2.0 Level A prior to publishing.
Note: This success criterion only applies to the automated behavior specified by the authoring tool developer. It does not apply when actions of authors prevent generation of accessible web content (e.g., authors might set less strict preferences, ignore prompts for accessibility information, provide faulty accessibility information, write their own automated scripts, etc.).
  • @At-least-one:
    • TinyMCE3.2
    • Defacto CMS (developer created templates display content listings)
  • ATutorLCMS? Dreamweaver8?
B.2.1 Guide authors to create accessible content. B.2.1.1 Decision Support: If the authoring tool provides the option of producing a web content technology for publishing for which the authoring tool does not provide support for the production of accessible content, then both of the following are true:
(a) Warning: Authors are warned that the authoring tool does not provide support for the production of accessible content for that technology; and
(b) List: From the warning, authors can access a list of technologies for which the authoring tool does provide support for the production of accessible content.
  • @None-confirmed
B.2.1.2 Set Accessible Properties: Mechanisms that set the properties of web content (e.g., attribute values, etc.) also include the ability to set the accessibility-related properties.
  • @Several
    • TinyMCE3.2
    • Dreamweaver8
      Screenshot of Dreamweaver8 image properties pane includes 'alt' attribute
    • Adobe Acrobat
      Screenshot of the touchup properties dialog showing the 'alternate text' field
    • Defacto CMS (primarly applies to uploaded assets, e.g. alt text)
  • ATutorLCMS?
B.2.1.3 Other Technologies: If the authoring tool can insert web content that it cannot subsequently edit, then the authors can associate accessibility information with that web content.
  • @Several
    • TinyMCE3.2
  • Dreamweaver8 (e.g., OBJECT accesibility information, etc.)?
B.2.2 Assist authors in checking for accessibility problems. B.2.2.1 Check Accessibility (WCAG Level A): If the authoring tool provides authors with the ability to add or modify web content so that any WCAG 2.0 Level A Success Criterion can be violated, then accessibility checking for those success criteria is provided (e.g., an HTML authoring tool that inserts images should check for alternative text; a video authoring tool with the ability to edit text tracks should check for captions).
Note: Automated and semi-automated checking is possible (and encouraged) for many types of web content accessibility problems. However, manual checking is the minimum requirement to meet this success criterion. In manual checking, the authoring tool provides authors with instructions for detecting problems, which authors must carry out by themselves. For more information on checking, see Implementing ATAG 2.0 - Appendix B: Levels of Checking Automation.
  • @Several
    • TinyMCE3.2 (via button launching AChecker (WCAG 2.0 A option, including "Potential Problems" display))
    • WAVE
    • Acrobat Accessibility Checker
    • MSOffice2010
      Screenshot of MS2010 checker pane. The top section of the pane lists errors and warnings. Once an issue receives focus, the bottom area displays information about why it should be repaired and how.
B.2.2.2 Availability: Checking is available prior to publishing in a manner appropriate to the workflow of the authoring tool.
  • @Several
    • TinyMCE3.2 (via button launching AChecker)
    • Office2010
      Screenshot of the accessibility checker available from the 'prepare for sharing' section along with 'inspect document' and 'check compatibility'
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 the authors decide whether it is correctly identified.
  • @Several
    • TinyMCE3.2 (via button launching AChecker)
    • WAVE (via the Index of WAVE icons)
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 content is identified (e.g., highlighting the affected content, displaying line numbers, etc.)
  • @Several
    • TinyMCE3.2 (via button launching AChecker)
    • MSOffice2010
    • WebAIM WAVE
B.2.3 Assist authors in repairing accessibility problems. B.2.3.1 Repair Accessibility (WCAG Level A): For each WCAG 2.0 Level A web content accessibility problem that is identifiable during checking (as required by Guideline B.2.2), repair assistance is provided.
Note: Automated and semi-automated repair is possible (and encouraged) for many types of web content accessibility problems. However, manual repair is the minimum requirement to meet this success criterion. In manual repair, the authoring tool provides authors with instructions for repairing problems, which authors must carry out by themselves. For more information on repair, see Implementing ATAG 2.0 - Appendix C: Levels of Repair Automation.
  • @Several
    • TinyMCE3.2 (via button launching AChecker (WCAG 2.0 A option, including "Potential Problems" display)) (manual repair instructions)
    • MSOffice2010 (manual repair instructions with pointed to some semi-automated repair functionality)
      Screenshot of MS2010 checker pane. The top section of the pane lists errors and warnings. Once an issue receives focus, the bottom area displays information about why it should be repaired and how.
    • WAVE (Manual repair instructions are provided)
B.2.4 Assist authors with managing alternative content for non-text content. 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.
  • @Many
    • TinyMCE3.2
    • Dreamweaver8
    • MS2010
    • XStandard2.1
    • Defacto CMS
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:
(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).
  • @At-least-one
    • A-Prompt 1.0
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 value that is equally available to user agents (e.g., the filename is not used).
  • @Many
    • TinyMCE3.2
    • Dreamweaver8
    • MS2010
    • XStandard2.1
B.2.5 Assist authors with accessible templates and other pre-authored content. B.2.5.1 Templates Accessible (WCAG Level A): If the authoring tool automatically selects templates or pre-authored content, then the selections conform to WCAG 2.0 Level A when used.
Note: Templates may not pass accessibility checks due to their inherent incompleteness. The accessibility status of a template should instead be measured by the accessibility of completed web content (in the final web content technology) created when the template is used properly.
  • @At-least-one
    • Defacto CMS (authors can choose from several pre-defined templates)
  • AtutorLCMS?
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.
  • @Several
    • AtutorLCMS
    • Dreamweaver8
    • Defacto CMS
B.3.1 Ensure that accessible authoring actions are given prominence. B.3.1.1 Accessible Options Prominent (WCAG Level A): If authors are provided with a choice of authoring actions for achieving the same authoring outcome (e.g., styling text), then options that will result in web content conforming to WCAG 2.0 Level A are at least as prominent as options that will not.
  • @At-least-one
    • Dreamweaver
    • Defacto CMS
B.3.2 Ensure that features of the authoring tool supporting the production of accessible content are available. B.3.2.1 Active by Default: All accessible content support features are turned on by default.
  • @Several
    • TinyMCE3.2
    • Dreamweaver8
    • Defacto CMS
B.3.2.2 Reactivate Option: If authors turn off an accessible content support feature, then they can always turn the feature back on.
  • @Many
    • Dreamweaver8 (e.g., "Accessibility" preferences page)
    • TinyMCE3.2
    • AtutorLCMS
  • SAKAI 3.0 HTML Authoring Component?
B.3.3 Ensure that features of the authoring tool supporting the production of accessible content are documented. B.3.3.1 Instructions: Instructions for using the accessible content support features appear in the documentation.
  • @Many
    • TinyMCE3.2
    • Dreamweaver8
    • AtutorLCMS
  • SAKAI 3.0 HTML Authoring Component?
B.3.4 Ensure that any authoring practices demonstrated in documentation are accessible. B.3.4.1 Model Accessible Practice (WCAG Level A): A range of examples in the documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level A accessible authoring practices.
  • @None-confirmed
  • AtutorLCMS?

Level AA Success Criteria

Guideline Success Criteria Implementations Info
A.1.1 [For the authoring tool user interface] Ensure that web-based functionality is accessible. A.1.1.2 Web-Based Accessible (WCAG Level AA): Web-based authoring tool user interfaces conform to WCAG 2.0 Level AA.
  • @At-least-one
    • Defacto CMS (a couple of error messages to improve, but it's almost there assuming that TinyMCE passes as well)
  • TinyMCE3.2?
A.3.1 [For the authoring tool user interface] Provide keyboard access to authoring features. A.3.1.3 Keyboard Shortcuts: Keyboard shortcuts are provided.
  • @Several
    • TinyMCE3.2
    • Dreamweaver8
    • AtutorLCMS
  • Flash8?
A.3.5 [For the authoring tool user interface] Provide text search of the content. A.3.5.1 Text Search: Authors can perform text searches of web content as follows:
(a) Search All Editable: Any information that is text and that the authoring tool can modify is searchable, including: text content, text alternatives for non-text content, metadata, markup elements and attributes; and
Note: If the current editing view is not able to display the results of a search, then the authoring tool may provide a mechanism to switch to a different editing view to display the results.
(b) Bi-Directional: The search can be made forwards or backwards; and
(c) Case Sensitive: The search can be in both case sensitive and case insensitive modes.
  • @Many
    • DreamWeaver8
  • MS2010?
A.3.6 [For the authoring tool user interface] Manage preference settings. A.3.6.1 Save Settings: The authoring tool display settings and control settings are saved between sessions.
  • @Many
    • Dreamweaver8
    • MS2010
    • XStandard2.1
A.3.6.2 Respect Platform Settings: The authoring tool respects platform display settings and control settings.
Note: As per Success Criterion A.2.3.1, the author's display settings must still be independent of the web content being edited.
  • @At-least-one
    • TinyMCE3.2 (respects browser display settings)
  • Dreamweaver (for Mac)? Desire2Learn? SAKAI?
A.4.1 [For the authoring tool user interface] Help users avoid and correct mistakes. A.4.1.3 Undo is Reversible: Authors can immediately reverse the most recent "undo" action(s).
  • @Several
    • TinyMCE3.2
    • Dreamweaver8
A.4.2 [For the authoring tool user interface] Document the user interface including all accessibility features. A.4.2.2 Document All Features: All features of the authoring tool are documented.
  • @At-least-one
    • Dreamweaver8
  • MS2010?
B.1.1 Support web content technologies that enable the creation of content that is accessible. B.1.1.2 Accessible Content Production (WCAG Level AA): Authors can use the authoring tool to produce web content that conforms to WCAG 2.0 Level AA.
  • @Many
    • XStandard2.1
    • TinyMCE3.2
    • DreamWeaver8
B.1.2 Ensure that the authoring tool preserves accessibility information. B.1.2.3 Preserve Accessibility Information (Enhanced): Any accessibility information (up to WCAG 2.0 Level AAA) recognized in the input to any web content transformation is preserved as accessibility information in the output.
  • @None-confirmed
    • @@examples needed - Jan (in general), Greg (New dreamweaver html5 extension, Adobe Encore?)
    • @@video converters?
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:
(a) Preserve Accessibility Information: The authoring tool only automatically deletes web content that it can detect is not accessibility information; or
(b) Notification Option: Authors have the option to receive notification before deletion; or
(c) No Deletion Option: Authors have the option to prevent automatic deletion by the authoring tool.
  • @None-confirmed
  • @@examples needed - code cleanup tools (Jan)?
B.1.3 Ensure that automatically generated content is accessible. B.1.3.2 Accessible Auto-Generated Content (Level AA): If the authoring tool automatically generates content, then that web content conforms to WCAG 2.0 Level AA prior to publishing.
Note: This success criterion only applies to the automated behavior specified by the authoring tool developer. It does not apply when actions of authors prevent generation of accessible web content (e.g., authors might set less strict preferences, ignore prompts for accessibility information, provide faulty accessibility information, write their own automated scripts, etc.).
  • @At-least-one
    • TinyMCE3.2
    • Defacto CMS
  • Dreamweaver8?
B.2.2 Assist authors in checking for accessibility problems. B.2.2.5 Check Accessibility (WCAG Level AA): If the authoring tool provides authors with the ability to add or modify web content so that any WCAG 2.0 Level AA Success Criterion can be violated, then accessibility checking for those success criteria is provided.
Note: Automated and semi-automated checking is possible (and encouraged) for many types of web content accessibility problems. However, manual checking is the minimum requirement to meet this success criterion. In manual checking, the authoring tool provides authors with instructions for detecting problems, which authors must carry out by themselves. For more information on checking, see Implementing ATAG 2.0 - Appendix B: Levels of Checking Automation.
  • @Several
    • TinyMCE3.2 (via button launching AChecker (WCAG 2.0 AA option, including "Potential Problems" display))
    • Acrobat Accessibility Checker
    • WAVE
  • MS2010 Document Finisher?
B.2.2.6 Status Report: Authors can receive an accessibility status report based on the results of the accessibility checks.
Note: The format of the accessibility status is not specified. For example, the status might be a listing of problems detected or a WCAG 2.0 conformance level, etc.
  • @Several
    • TinyMCE3.2 (via button launching AChecker (WCAG 2.0 AA option, including "Potential Problems" display))
    • WAVE
    • Acrobat Accessibility Checker
B.2.2.7 Metadata Production: Authors have the option of associating accessibility checking results with the web content as metadata. (Level AA)
Note: The metadata format that is implemented will dictate the nature of the associated results (e.g., low-level check results, high-level conformance claims, etc.)
  • @At-least-one
    • AChecker (AccessForAll metadata)
  • EARL producing checkers?
B.2.3 Assist authors in repairing accessibility problems. B.2.3.2 Repair Accessibility (WCAG Level AA): For each WCAG 2.0 Level AA web content accessibility problem that is identifiable during checking (as required by Success Criterion B.2.2.5), repair assistance is provided.
Note: Automated and semi-automated repair is possible (and encouraged) for many types of web content accessibility problems. However, manual repair is the minimum requirement to meet this success criterion. In manual repair, the authoring tool provides authors with instructions for repairing problems, which authors must carry out by themselves. For more information on repair, see Implementing ATAG 2.0 - Appendix C: Levels of Repair Automation.
  • @Several
    • TinyMCE3.2 (via button launching AChecker (WCAG 2.0 AA option, including "Potential Problems" display))
    • WAVE
    • Acrobat Accessibility Checker
B.2.4 Assist authors with managing alternative content for non-text content. 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.
  • @At-least-one
    • A-Prompt 1.0 (for "alt")
  • Capscribe?
B.2.5 Assist authors with accessible templates and other pre-authored content. B.2.5.3 Templates Accessible (WCAG Level AA): If the authoring tool automatically selects templates or pre-authored content, then the selections conform to WCAG 2.0 Level AA when used.
Note: Templates may not pass accessibility checks due to their inherent incompleteness. The accessibility status of a template should instead be measured by the accessibility of completed web content (in the final web content technology) created when the template is used properly.
  • @None-confirmed
    • Defacto CMS
  • AtutorLCMS?
B.2.5.4 Template Selection Mechanism: If authors are provided with a template selection mechanism, then both of the following are true:
(a) Indicate: The selection mechanism indicates the accessibility status of templates (if known); and
(b) Prominence: Any accessible template options are at least as prominent as other template options.
  • @None-confirmed
  • DrupalCMS? AtutorLCMS? De Facto CMS?
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.
  • @None-confirmed
  • Check with Shadi re: EARL? Desire2Learn?
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:
(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.
  • @None-confirmed
  • Acrobat? Eclipse/Netbean plugins for DoJo, Jquery? Fluid?
B.3.1 Ensure that accessible authoring actions are given prominence. B.3.1.2 Accessible Options Prominent (WCAG Level AA): If authors are provided with a choice of authoring actions for achieving the same authoring outcome (e.g., styling text), then options that will result in web content conforming to WCAG 2.0 Level AA are at least as prominent as options that will not.
  • @At-least-one
    • TinyMCE3.2
B.3.2 Ensure that features of the authoring tool supporting the production of accessible content are available. B.3.2.3 Deactivation Warning: If authors turn off an accessible content support feature, then the authoring tool informs them that this may increase the risk of content accessibility problems.
  • @None-confirmed
  • Acrobat? MS2010? AtutorLCMS?
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).
  • @Several
    • TinyMCE3.2
    • MS2010
    • Acrobat
B.3.4 Ensure that any authoring practices demonstrated in documentation are accessible. B.3.4.2 Model Accessible Practice (WCAG Level AA): A range of examples in the documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level AA accessible authoring practices.
  • @None-confirmed
  • Acrobat?

Level AAA Success Criteria

Guideline Success Criteria Implementations Info
A.1.1 [For the authoring tool user interface] Ensure that web-based functionality is accessible. A.1.1.3 Web-Based Accessible (WCAG Level AAA): Web-based authoring tool user interfaces conform to WCAG 2.0 Level AAA.
  • @None-confirmed
  • TinyMCE3.2?
A.2.2 [For the authoring tool user interface] Editing view presentation can be programmatically determined. A.2.2.3 Access to Text Presentation (Enhanced): If an editing view (e.g., WYSIWYG view) renders any presentation properties for text, then those properties can be programmatically determined.
  • @At-least-one
    • TinyMCE3.2.(via browser)
A.3.1 [For the authoring tool user interface] Provide keyboard access to authoring features. A.3.1.4 Keyboard Access (Enhanced): All functionality of the authoring tool is operable through a keyboard interface.
  • @Several
    • TinyMCE3.2
    • AtutorCMS
    • Defacto CMS
  • DrupalCMS? Fluid tools (Decapod coversion, Collection space)
A.3.1.5 Customize Keyboard Access: Keyboard access to the authoring tool can be customized.
  • @At-least-one
    • DreamWeaver8
      Screenshot of Dreamweaver MX2004 keyboard shortcut editor.
    • MS2010, Web-based tools customized from browser?
A.3.1.6 Present Keyboard Commands: Authoring tool user interface controls can be presented with their associated keyboard commands.
  • @Several
    • MS2010
    • DreamWeaver8 (underlines access keys in the menus when "alt" key is pressed)
      Screenshot of Dreamweaver MX2004 keyboard shortcut editor.
A.3.2 [For the authoring tool user interface] Provide authors with enough time. A.3.2.4 Content Edits Saved (Extended): The authoring tool can be set to save all content edits made by authors.
  • @Several
    • Photoshop
    • Google Docs document editor
  • Dreamweaver?
A.3.6 [For the authoring tool user interface] Manage preference settings. A.3.6.3 Multiple Sets: Authors can save and reload multiple sets of any authoring tool display settings and control settings.
  • @Several
    • Dreamwaever
    • Indesign
A.3.6.4 Options Assistance: The authoring tool includes a mechanism to help authors configure any options related to Part A of this document.
  • @Several
    • MS2010
    • DreamWeaver8

 
B.1.1 Support web content technologies that enable the creation of content that is accessible. B.1.1.3 Accessible Content Production (WCAG Level AAA): Authors can use the authoring tool to produce web content that conforms to WCAG 2.0 Level AAA.
  • @Many
    • TinyMCE3.2
    • Dreamweaver
    • Defacto CMS
B.1.3 Ensure that automatically generated content is accessible. B.1.3.3 Accessible Auto-Generated Content (Level AAA): If the authoring tool automatically generates content, then that web contentconforms to WCAG 2.0 Level AAA prior to publishing.
Note: This success criterion only applies to the automated behavior specified by the authoring tool developer. It does not apply when actions of authors prevent generation of accessible web content (e.g., authors might set less strict preferences, ignore prompts for accessibility information, provide faulty accessibility information, write their own automated scripts, etc.).
  • @At-least-one
    • TinyMCE3.2
    • Defacto CMS
B.2.2 Assist authors in checking for accessibility problems. B.2.2.8 Check Accessibility (WCAG 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.
Note: Automated and semi-automated checking is possible (and encouraged) for many types of web content accessibility problems. However, manual checking is the minimum requirement to meet this success criterion. In manual checking, the authoring tool provides authors with instructions for detecting problems, which authors must carry out by themselves. For more information on checking, see Implementing ATAG 2.0 - Appendix B: Levels of Checking Automation.
  • @At-least-one
    • TinyMCE3.2 (via button launching AChecker (WCAG 2.0 AAA option, including "Potential Problems" display))
    • WebAIM WAVE? Deeque? HiSoftware? CommonLook?
B.2.3 Assist authors in repairing accessibility problems. B.2.3.3 Repair Accessibility (WCAG Level AAA): For each WCAG 2.0 Level AAA web content accessibility problem that is identifiable during checking (as required by Success Criterion B.2.2.10), repair assistance is provided.
Note: Automated and semi-automated repair is possible (and encouraged) for many types of web content accessibility problems. However, manual repair is the minimum requirement to meet this success criterion. In manual repair, the authoring tool provides authors with instructions for repairing problems, which authors must carry out by themselves. For more information on repair, see Implementing ATAG 2.0 - Appendix C: Levels of Repair Automation.
  • @At-least-one
    • TinyMCE3.2 (via button launching AChecker (WCAG 2.0 AAA option, including "Potential Problems" display))
    • WebAIM WAVE? Deeque? HiSoftware? CommonLook?
B.2.5 Assist authors with accessible templates and other pre-authored content. 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.
  • @None-confirmed
  • A-Content (Div. Directorate)? Dreamweaver templates may list some accessible status info? Scholar's portal?
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.
  • @None-confirmed
  • A-Content (Div. Directorate)? Dreamweaver templates may list some accessible status info? Scholar's portal?
B.2.5.9 Templates Accessible (WCAG Level AAA): If the authoring tool automatically selects templates or pre-authored content, then the selections conform to WCAG 2.0 Level AAA when used.
Note: Templates may not pass accessibility checks due to their inherent incompleteness. The accessibility status of a template should instead be measured by the accessibility of completed web content (in the final web content technology) created when the template is used properly.
  • @At-least-one
    • Defacto CMS
B.3.1 Ensure that accessible authoring actions are given prominence. B.3.1.3 Accessible Options Prominent (WCAG Level AAA): If authors are provided with a choice of authoring actions for achieving the same authoring outcome (e.g., styling text), then options that will result in web content conforming to WCAG 2.0 Level AAA are at least as prominent as options that will not.
  • @None-confirmed
  • Opencaps? TinyMCE?
B.3.3 Ensure that features of the authoring tool supporting the production of accessible content are documented. B.3.3.2 Accessible Authoring Tutorial: A tutorial on an accessible authoring process that is specific to the authoring tool is provided.
  • @At-least-one
    • Acrobat (http://www.adobe.com/accessibility/tutorials.html)
    • Atutor
B.3.4 Ensure that any authoring practices demonstrated in documentation are accessible. B.3.4.3 Model Accessible Practice (WCAG Level AAA): A range of examples in the documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level AAA accessible authoring practices.
  • @None-confirmed
    • OpenCaps, Atutor