Draft Authoring Tool Accessibility Guidelines (ATAG) Version 2.0 Conformance Assessment Template

Template Completion Instructions

1. Edit this template with an HTML editor.
2. Follow the instructions given in the temporary text, identified as follows [temporary text].
3. When you are finished, remove the temporary text

Assessment Information

TOOL: [Tool name and version number along with all supplementary plug-ins etc.]
DATE: [Date evaluation was completed]
EVALUATOR: [Evaluator's name] (e-mail: [Evaluator's email address])
ATAG VERSION: http://www.w3.org/TR/2000/REC-ATAG10-20000203/

Disclaimer

This conformance evaluation is for informative purposes, only. It is not meant as a definitive review of the product. The evaluation does not represent any endorsement by the W3C, the Authoring Tools Working Group (AUWG), or any members. The evaluation should not to be used to try to rate or compare product accessibility. The review does not necessarily reflect a consensus of the AUWG. Comments on the review can be sent to the AUWG mail list.

Evaluating Relative Priority Checkpoints

The five Relative Priority (RP) checkpoints in ATAG (always version 2.0 in this document) are those that require authoring tools to do something general (e.g. generate markup, include templates, perform checking, etc.) with respect to some or all of the accessibility problems defined in WCAG (always version 1.0 in this document).

RP checkpoints are different from the regular Priority 1, 2 , or 3 ATAG checkpoints in that they inherit their priority level from the WCAG checkpoints that they reference (see chart, below).

As previously mentioned, not every WCAG checkpoint will be relevant to every ATAG RP checkpoint. Those that are, are specified in the "ATAG 2.0 References WCAG Draft Note" and listed in this template to aid the reviewer. Keep in mind, however, that these lists reflect relevance for authoring tools, in general, and some of the listed checkpoints may not be relevant to specific authoring tools. To take account of this, you will usually have the option of deciding that a WCAG checkpoint is Not Applicable.

Once you have determined whether each WCAG checkpoint relevant to an ATAG RP checkpoint is met, not met or not applicable, refer to the chart above to determine the Relative Priority ATAG Checkpoint Priority Level.

Conformance Summary

Instructions for this section

The overall ATAG 1.0 conformance level is: Level-AAA | Level-AA | Level-A | Not conformant

Instructions:

This chart will help you determine the conformance level of the authoring tool with ATAG 1.0. Fill in the chart by:

1. Inserting the answers from the evaluations (the rest of the template) into the appropriate rows.
2. The blank cells should be left blank. These represent checkpoints not required for meeting lower conformance levels. For example, checkpoint 4.3 is a Priority 2 checkpoint, so it does not matter if it is met or not for A-Level conformance. But it does matter for AA-Level and AAA-Level conformance.
3. RP Note: For RP checkpoints, enter Yes if the priority level of the RP is less than or equal to that of the column. For example, if RP checkpoint 2.5 has been found to have a priority of AA-Level, then enter Yes in the A-Level column, Yes in the AA-Level column and No in the AAA-Level column.
4. Finally, to determine the level of compliance, choose the highest level column that does not include any No answers. If No appears in every column, then the authoring tool is Not conformant with ATAG 2.0.

Highlights

Strong Points:

[Add summary comments about the areas the tool has conformed.]

Improvement Needed:

[Add summary comments about the areas that remain to reach the next level of conformance.]

Conformance Details

Guideline 1: Ensure that the tool itself is accessible

1.1 Ensure that the authoring interface follows applicable software accessibility guidelines ([Priority 1] for required elements of the software accessibility guidelines; [Priority 3] for recommended elements of the software accessibility guidelines).

Yes(Level-AAA). [The authoring interface passes Required Software Accessibility Guidelines testing criteria, below]
Yes(Level-A). [The authoring interface passes the Recommended Software Accessibility Guidelines testing criteria, below.]
No (Does not meet Level-A). [The authoring interface does not pass the Software Accessibility Guidelines testing criteria, below]

[This section only for Yes(Level-A) or No]
The following operating system and accessibility standards and conventions below related to accessible software still remain to be met in order to meet the compliance levels listed:

Outstanding Required Software Accessibility Guidelines testing criteria
(Required to meet Relative Priority Levels A and AAA)

[Delete checkpoints from this list that the tool DOES meet]

• Following Standards: Draw text and objects using system conventions.
  
• Following Standards: Make mouse, keyboard, and API activation of events consistent.
  
• Following Standards: Provide a user interface that is "familiar" (to system standards, or across platform).
  
• Following Standards: Use system standard indirections and APIs wherever possible.
  
• Following Standards: Ensure all dialogs, sub-windows, etc., satisfy all same requirements as the main program.
  
• Following Standards: Avoid blocking assistive technology functions (sticky/mouse keys, screen reader controls, etc.) where possible.
  
• Configurability: Allow control of timing, colors, sizes, input/output devices and media.
  
• Input Device Independence: Provide Keyboard access to all functions.
  
• Input Device Independence: Document all keyboard bindings.
  
• Icons, Graphics, Sounds: Provide graphical (text) equivalents for sound warnings.
  
• Icons, Graphics, Sounds: Provide text equivalents for images/icons.
  
• Icons, Graphics, Sounds: Use customizable (or removable) colors/patterns.
  
• Icons, Graphics, Sounds: Ensure high contrast is available (as default setting).
  
• Icons, Graphics, Sounds: Provide text equivalents for all audio.
  
• Layout: Do not rely on color alone for meaning. Use color for differentiation, in combination with accessible cues (text equivalents, natural language, etc.).
  
• Layout: Position related text labels and objects consistently, and in an obvious manner (labels before objects is recommended).
  
• Layout: Ensure default window sizes fit in screen.
  
• User Focus: Clearly identify the user focus (and expose it via API).
  
• User Focus: Unexpected events should not be caused by viewing content (for example by moving the focus to a new point).
  
• User Focus: Allow user control of timing - delays, time-dependent response, etc.
  
• User Focus: Allow for navigation between as well as within windows.
  
• Documentation: Ensure that help functions are accessible.

Details: [Provide an explanation for your answer.]

Outstanding Recommended Software Accessibility Guidelines testing criteria
(Required to meet Relative Priority Levels AAA)

[Delete checkpoints from this list that the tool DOES meet]

• Input Device Independence: Provide logical navigation order for the keyboard interface.
  
• Input Device Independence: Avoid repetitive keying wherever possible.
  
• Input Device Independence: Provide customizable keyboard shortcuts for common functions.
  
• Input Device Independence: Provide mouse access to functions where possible.
  
• Icons, Graphics, Sounds: Use icons that can be resized or are available in multiple sizes.
  
• Icons, Graphics, Sounds: Allow sounds to be turned off.
  
• Layout: Group related controls.
  
• Layout: Allow for window resizing (very small to very large).
  
• Documentation: Provide documentation for all features of the tool.

• Configurability: Allow users to create profiles.
  
• Configurability: Allow users to reshape the user interface - customize toolbars, keyboard commands, etc.
  
• Other:

Details: [Provide an explanation for your answer.]

1.2 Ensure that the authoring interface enables accessible editing of element and object properties [Priority 1]

Yes. [At least one editing method passes the Software Accessibility Guidelines testing criteria for each element and object property editable by the tool. (Priority 1 for Required criteria; Priority 3 for Recommended criteria) ]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

1.3 Allow the display preferences of the authoring interface to be changed without affecting the document markup [Priority 1]

Yes. [All editing views display text equivalents for any non-text content AND all editing views either respect operating system display settings (for color, contrast, size, and font) or, from within the tool, provide a means of changing color, contrast, size and font, without affecting the content markup. ]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

1.4 Ensure that the authoring interface enables the author to navigate the structure and perform structure-based edits. [Priority 1]

Yes. [In any element hierarchy, the author is able to move editing focus from any structural element to any element immediately above, immediately below or in the same level in the hierarchy AND in any element hierarchy, the author must be able to select, copy, cut and paste any element with its content. ]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

1.5 Ensure the authoring interface allows the author to search within the editing views [Priority 2]

Yes. [The authoring tool has a search function for all editing views AND the author is able to search for text within all text equivalents of any rendered non-text content AND the author is able to specify whether to search content, markup, or both.]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

GUIDELINE 2: Ensure that the tool is designed to produce accessible content

Yes. [All markup strings written automatically by the tool (i.e. not authored "by hand") conform to the applicable markup language specification]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

2.2 Use the latest versions of W3C format Recommendations when they are available and appropriate for a task [Priority 2]

Yes. [The tool provides an accessible reading of web content in available, relevant W3C recommended language format and provide accessible means for editing and writing in that language format, AND the tool may use non-W3C formats in addition to the W3C Recommendations, AND a W3C Recommendation is considered available to a specific version of an authoring tool, if the Recommendation has reached the Candidate Recommendation phase at least two (2) years before the version of the tool in question is released for use, AND whether a W3C Recommendation is appropriate depends on the features of the tool. Critical relevance criteria will depend on the task, but may include support for media, scripting, or styling. When comparing the appropriateness of W3C recommendations with other, non-W3C formats for a particular task, accessibility must be included as a comparison criteria, AND inform the author in marketing, packaging and other documentary material of the name and version of any W3C Recommendations used. This notice must specify whether the conformance with the Recommendation is full or partial.]
No. [Tool does not meet the above conditions.]

Details: [Provide an explanation for your answer.]

2.3 Ensure that the author can produce accessible content in the markup language(s) supported by the tool [Priority 1]

Yes. [Tools must always meet at least one of the following: (1) generate accessible content automatically, (2) provide a method for authoring "by hand", (3) provide the author with accessible options for every authoring task ]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

2.4 Ensure that the tool preserves all accessibility information during transformations, and conversions [Priority 1]

Yes. [During all transformations and conversions, any accessibility information is preserved, unless prevented by limitations of the target format AND when accessibility information cannot be preserved during a conversion or transformation, the author must notified beforehand.]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

2.5 Ensure that when the tool automatically generates content it conforms to the WCAG. [Relative Priority]

Evaluation Techniques:

Yes(Level-A)
Yes(Level-AA)
Yes(Level-AAA)
No (Does not meet Level-A)
Not Applicable
[All markup strings written automatically by the tool (i.e. not authored "by hand") must conform to WCAG. ]

Details: [Provide an explanation for your answer.]

Outstanding WCAG Checkpoints:

[List checkpoints]

2.6 Ensure that all pre-authored content for the tool conforms to WCAG. [Relative Priority]

Yes(Level-A)
Yes(Level-AA)
Yes(Level-AAA)
No(Does not meet Level-A)
Not Applicable
[Any Web content (e.g. templates, clip art, multimedia objects, scripts, applets, example pages, etc.) preferentially licensed (i.e. better terms of use for users of tool than for others) for users of the tool, must conform to WCAG.]

Details: [Provide an explanation for your answer.]

Outstanding WCAG Checkpoints:

[List checkpoints]

2.7 Allow the author to preserve markup not recognized by the tool. [Priority 2]

Yes. [When unrecognized markup (e.g. external entity, unrecognized element or attribute name) is detected, the tool must query the author for consent to modify the markup. If the author refuses, and the markup cannot be processed, the tool must refuse to open the markup for editing.]
No. [Tool does not meet the above condition.]
Not Applicable. [Tool does allow author to import or directly author markup - so tool recognizes all markup.]

Details: [Provide an explanation for your answer.]

GUIDELINE 3: Support the author in the production of accessible content

Guiding the author to produce accessible content:

3.1 Prompt and assist the author to create accessible content [Relative Priority]

Yes(Level-AAA)
Yes(Level-AA)
Yes(Level-A)
No (Does not meet Level-A)
Not Applicable
[When the actions of the author risk creating accessibility problems (e.g. image inserted, author typing invalid element into a code view, author initiating a page creation wizard, etc.), the tool intervenes to introduce the appropriate accessible authoring practice. This intervention may proceed according to a user-configurable schedule AND the intervention occurs at least once before completion of authoring (e.g. final save, publishing, etc.). ]

Details: [Provide an explanation for your answer.]

Outstanding WCAG Checkpoints:

[List checkpoints]

3.2 Check for and inform the author of accessibility problems. [Relative Priority]

Yes(Level-AAA)
Yes(Level-AA)
Yes(Level-A)
No (Does not meet Level-A)
Not Applicable
[The tool provides a check (automated check, semi-automated check or manual check) for detecting violations of each requirement of WCAG.]

Details: [Provide an explanation for your answer.]

Outstanding WCAG Checkpoints:

[List checkpoints]

3.3 Assist authors in repairing accessibility problems [Relative Priority]

Yes(Level-AAA)
Yes(Level-AA)
Yes(Level-A)
No (Does not meet Level-A)
Not Applicable
[The tool provides a repair (automated repair, semi-automated repair or manual repair) for correcting violations of each requirement of WCAG.]

Details: [Provide an explanation for your answer.]

Outstanding WCAG Checkpoints:

[List checkpoints]

3.4 Do not automatically generate equivalent alternatives or reuse previously authored alternatives without author confirmation, except when the function is known with certainty [Priority 1]

Yes. [When the author inserts an unrecognized non-text object, the tool does not insert an automatically generated text equivalent (e.g. label generated from the file name) AND when the author inserts a non-text object for which the tool has a previously authored equivalent (i.e. created by the author, tool designer, pre-authored content developer, etc.), but the function of the object is not known with certainty, the tool prompts the author to confirm insertion of the equivalent. However, where the function of the non-text object is known with certainty (e.g. "home button" on a navigation bar, etc.), the tool may automatically insert the equivalent. ]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

3.5 Provide functionality for managing, editing, and reusing alternative equivalents for multimedia objects [Priority 3]

Yes. [When non-text objects have been previously inserted using the tool, the tool suggests any previously authored textual equivalents for that non-text object.]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

3.6 Provide the author with a summary of the document's accessibility status [Priority 3]

Yes. [The tool provides the author with an option to view a listing of all current accessibility problems.]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

3.7 Document all features of the tool that promote the production of accessible content [Priority 1]

Yes. [All features that play a role in creating accessible content are documented in the help system..]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

3.8 Ensure that accessibility is modeled in all documentation and help, including examples [Priority 2]

Yes. [All examples of markup code and views of the user interface (dialog screenshots, etc.) meet the requirements of WCAG, regardless of whether the examples are intended to demonstrate accessibility authoring practices]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

3.9 Document the workflow process of using the tool to produce accessible content. [Priority 3]

Yes. [The documentation contains suggested content creation workflow descriptions that include how and when to use the accessibility-related features of the tool AND for tools that lack a particular accessibility-related feature, the workflow description includes a workaround for that feature.]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

GUIDELINE 4: Integrate accessibility solutions into the overall "look and feel"

4.1 Ensure that accessibility prompting, checking, repair functions and documentation are always clearly available to the author [Priority 1]

Yes. [If accessibility prompting (see Checkpoint 3.1), checking (see Checkpoint 3.2), and repairing (see Checkpoint 3.3) functions are not already active by default, the mechanism for activating them is available to the author at all times during authoring and, at most, one level down in the user interface (e.g. in the first level of a drop-down menu) AND the configuration mechanism (i.e. preferences, options, etc.) for these accessibility-related functions is designed so that typical authors searching for the configuration mechanism will be likely to find it and that typical authors performing general configuration tasks will be likely to notice the configuration mechanism, AND when these accessibility-related functions are combined with other authoring functions (i.e. one accessibility-related field in a general purpose dialog box), they are designed so that typical authors searching for the function will be likely to find it and that typical authors performing other general purpose tasks will be likely to notice the function.]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

4.2 Ensure that the most accessible option for an authoring task is given priority. [Priority 2]

Yes. [When a tool provides a means for markup to be added with a single mouse click or keystroke, that markup meets the requirements of WCAG unless the markup was authored "by hand", AND when an authoring action has several markup implementations (e.g. changing the color of text with presentation markup or style sheets), those markup implementation(s) that meet the requirements of WCAG are equal to or higher on all of the following scales than those markup implementations that do not meet the WCAG requirements: (1) Prominence of location (in "power tools" such as floating menus, toolbars, etc.), (2) Position in layout (top to bottom and left to right in menus, dialog boxes, etc. ), (3) Size of control (measured as screen area), and (4) Actions to activate (number of mouse clicks or keystrokes) ]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

4.3 Ensure that accessibility prompting, checking, repair functions and documentation are naturally integrated into the overall look and feel of the tool. [Priority 2]

Yes. [The mechanisms for accessibility prompting, checking, repair and documentation must be similar to comparable mechanisms in terms the following characteristics: (1) visual design (design metaphors, artistic sophistication, sizes, fonts, colors), (2) operation (degree of automation, number of actions for activation), (3) configurability (number and types of features) ]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]