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 reviews 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 eight Relative Priority (RP) checkpoints in ATAG (always version 1.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). ATAG checkpoint 7.1 is the only exception to this, since it refers to other accessibility standards, rather than WCAG.

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 1.0 techniques document 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 always 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 7.6 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 1.3 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 1.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 all operating environment conventions that benefit accessibility (Applies at three priority levels: [Priority 1] for standards and conventions that are essential to accessibility; [Priority 2] for those that are important to accessibility; [Priority 3] for those that are beneficial to accessibility).

Yes(Level-AAA). [Tool UI meets applicable Priority 1, 2 and 3 operating system and accessibility standards and conventions below.]
Yes(Level-AA). [Tool UI meets applicable Priority 1 and 2 operating system and accessibility standards and conventions below.]
Yes(Level-A). [Tool UI meets applicable Priority 1 operating system and accessibility standards and conventions below.]
No (Does not meet Level-A). [Tool UI does not meet applicable operating system and accessibility standards and conventions below.]

[This section only for Yes(Level-A), Yes(Level-AA), 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 Priority 1 Operating System and Accessibility Standards and Conventions
(Required to meet Relative Priority Levels A, AA, 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 Priority 2 Operating System and Accessibility Standards and Conventions
(Required to meet Relative Priority Levels AA and 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.
  
• Icons, Graphics, Sounds: Use icons that can be resized or are available in multiple sizes.
  
• Layout: Group related controls.
  
• Layout: Allow for window resizing (very small to very large).
  
• Documentation: Provide documentation for all features of the tool.
  
• Other:

Details: [Provide an explanation for your answer.]

Outstanding Priority 3 Operating System and Accessibility Standards and Conventions
(Required to meet Relative Priority Level AAA)

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

• Configurability: Allow users to create profiles.
  
• Configurability: Allow users to reshape the user interface - customize toolbars, keyboard commands, etc.
  
• Input Device Independence: Provide customizable keyboard shortcuts for common functions.
  
• Input Device Independence: Provide mouse access to functions where possible.
  
• Icons, Graphics, Sounds: Allow sounds to be turned off.
  
• Other:
  

Details: [Provide an explanation for your answer.]

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

Yes. [Tool has property editing functions that have proper (not just iconic) labels and relatively straightforward keyboard navigation.]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

1.3 Ensure that the authoring interface enables the author to edit the structure of the document [Priority 2]

Yes. [Tool allows author access to all the properties of the structural markup - headers, frames, etc.]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

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

Yes. [Tool has some means of changing the size and colors in the authoring view - this may simply be support for system wide display settings.]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

1.5 Ensure that the authoring interface enables accessible navigation of editing views via the document structure. [Priority 2]

Yes. [Tool has a some ability to move editing focus directly from element to element - "next element" or "next element of type", etc.]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

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

Background:

The purpose of this checkpoint is to encourage authoring tool developers to include search functions into their tools in order to facilitate navigation of the content as it is authored. This search capability may be as simple as a string matching "find" function in a basic text editor or as complex as search functions that take advantage of the structure (elements, attributes, etc.) inherent in marked-up content.

As this is a checkpoint within Guideline 7 (Ensure that the Authoring Tool is Accessible to Authors with Disabilities) there is one other implicit requirement: that is that the search function must able to move the editing focus immediately to the occurrences that it finds (one at a time s requested by the author). A tool that merely highlights all the found occurrences simultaneously without allowing the author to quickly move the editing focus to the occurrences is not helpful as a document navigation function.

Evaluation Techniques:

Meets Checkpoint?: Yes | No
Details: [Provide an explanation for your answer.]

This checkpoint should be applicable to any authoring tool, since every tool will have content that can be searched in some way (ex. even graphics can be searched using pattern matching).

Examine the tool for a search feature which queries the author for some search criteria and then moves the edit focus to the occurrences that it finds. If this is present, answer Yes. Otherwise, answer No.

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

Generating standard markup:

Yes. [Tool supports the most up to date version of its markup languages (as of 2 years prior to release.]
No. [Tool either does not meet the above condition or does not produces content in a non-W3C format for which a comparable W3C alternative existed (as of 2 years prior to release).]

Details: [Provide an explanation for your answer.]

2.2 Ensure that markup which the tool automatically generates is valid for the language the tool is generating. [Priority 1]

Yes. [Tool produces valid markup - automated validation for some languages available at http://validator.w3.org.]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

Supporting accessible authoring practices:

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

Background:

This checkpoint establishes an absolute minimum standard for accessibility-awareness in an authoring tool: enforce no harm. In other words, an authoring tool may meet this checkpoint, even if it "does harm" (by generating inaccessible code, failing to prompt the author for equivalents to multimedia, etc.), so long as the tool does not "enforce" that harm by failing to provide authors (who are aware of the WCAG guidelines) with a way to follow WCAG from within the authoring tool. The purpose of this checkpoint is to fail WYSIWYG editors that sometimes or always generate inaccessible markup despite author efforts and then prevent author access to that markup. On the other hand, plain text editors, WYSIWYG editors with text editor options, and WYSIWYG-only editors that always generate accessible Web content will pass this checkpoint as long as they also allow the author's changes to be properly saved. Remember, the markup editing functionality must be within the tool. Simply arguing that authors are free to make changes using an external editor will not be sufficient.

Notice that the Priority of the checkpoint is "1", not "Relative Priority", despite the checkpoint including the term "accessible content", which is defined as the contents of WCAG 1.0. This was is deliberate and intended to encourage non-interference as a first step towards the active facilitation of accessibility.

Evaluation Techniques:

Meets Checkpoint?: Yes | No | Not Applicable
Details: [Provide an explanation for your answer.]

This checkpoint is Not Applicable if the output of the authoring tool is not encoded in a markup language. This means most programming tools and non-markup based multimedia editor are exempt.

If the checkpoint is applicable, examine the authoring tool to see whether it includes a markup editing view of some kind. Test the markup editing view by adding accessible markup to make sure that any manual changes made by the author are saved properly. Some sample accessible markup is available for the for the following markup languages:

• HTML4.0

If so, answer Yes.

If no markup editing view is available, as may often be the case for very complex markup languages or authoring tools designed for beginners, the tool will have to be faultless in its automatic markup generation in order to pass. Since checkpoint 1.3 addresses the issue of automatic markup generation, wait until you have completed checkpoint 1.3. Then return to this checkpoint and answer Yes if checkpoint 1.3 is Yes(Level-AAA), otherwise answer No.

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

Background:

The purpose of this checkpoint is to ensure that once the author has made the effort to add accessible content, either manually or with the aid of the authoring tool, the authoring tool will take great care not to lose that content. The checkpoint specifies three general classes of operations (authoring, transformation, and conversion) that, in practice, cover almost every editing manipulation performed by an authoring tool.

"Authoring" operations are the most straightforward because the markup language and any accessible content is in the same format as the end result of the authoring operation and should therefore be easy to preserve. Of course, if an object has some accessibility content and the object is deleted (an authoring operation) the accessibility content also be removed - as long as it is retrieved intact if an "undo" action is performed. Saving a potential concern, since authoring tools may encode content differently during authoring than the final saved markup.

"Transformation" operations are those that involve modifying the encoding of content without changing the markup language. For example, taking content marked up in a table and reformatting it with list markup.

"Conversion" operations are those that take content encoded in one markup language and re-encode it in another. For example, if a word processor document contains image captions, this content should be preserved appropriately if the document is converted into a markup language that supports image captions or labeling.

Evaluation Techniques:

Meets Checkpoint?: Yes | No
Details: [Provide an explanation for your answer.]

This checkpoint should be applicable to any authoring tool, since every tool will perform at least the "authoring" operations.

Unless you are the tool developer it is probably best to test this checkpoint by treating the authoring tool as a blackbox - that takes content as input, performs some "authoring", "transformation" or "conversion" operation on it and then produces different content as output. To perform the test, you will require test files for each of the languages supported for input by the authoring tool. Test files are provided here for the following languages:

• HTML4.0

If no test file is available for a language, you will need to assemble one that is representative of the accessible authoring practices available in the input format. If possible, run the test document through an automated accessibility testing utility before using it.

Test "authoring" by opening/inserting the content into the tool, performing a representative assortment of edits (being sure not to intentionally remove any of the accessibility content) before saving out to the same format. Test the output by running it through the automated checking tool. Examine the results of the automated check to see whether any of the accessible authoring practices from the original (that you purposefully avoided modifying) are still intact. If they are not, answer No.

Test "transformation" by first examining the authoring tool and its documentation for transformation features, such as "table linearizers", "layout optimizers", etc. (anything that changes the way the content is encoded in the language). If you do not fin any such features, skip to the next paragraph. Once you have a list of these features design test input content for each so that it is maximally accessible. Then run the "transformation" feature and record whether any of the accessible content has been lost during the operation (Note: pay special attention to text content such as labels and descriptions of media and structural content such as proper use of headers). If this content has been lost, answer No.

Test "conversion" by first examining the authoring tool and its documentation for a full listing of the languages that it supports for input and output (Note: these may differ. For example, some Web editors read in Word processor formats but do not write them out). If the tool inputs or outputs more than one format it will be necessary to test the conversion between them. This can be done by opening/inserting the content into the tool and then saving/exporting/publishing it out as each of the formats available in the authoring tool. For example, if the tool supported the following input and output formats (see chart below), you would need to test each of the conversion combinations shown. If any of the conversions fail to preserve accessibility content in the input content, answer No (Note: pay special attention to text content such as labels and descriptions of media and structural content such as proper use of headers).

		INPUT FORMATS
		HTML	XHTML	RTF	HTML3.2	MS Word	WordPerfect
OUTPUT FORMATS	HTML4		Test	Test	Test	Test	Test
	XHTML	Test		Test	Test	Test	Test
	RTF	Test	Test		Test	Test	Test

Finally, if the authoring tool has passed all of the preceding steps, answer Yes.

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

Background:

This checkpoint is a catch-all for all markup that the authoring tool generates within the explicit direction of the author. Generated markup is any markup that the user has not specified the exact markup (either by directly typing them or choosing them by name).

Evaluation Techniques:

Meets Checkpoint?: Yes(Level-A) | Yes(Level-AA) | Yes(Level-AAA) | No (Does not meet Level-A) | Not Applicable
Details: [Provide an explanation for your answer.]

This checkpoint is Not Applicable if the output of the authoring tool is not encoded in a markup language. This means most programming tools and non-markup based multimedia editor are exempt.

Test this checkpoint by activating as many of the authoring tool's markup related features as possible that are at least one step removed from the actual elements and attributes. This includes site wizards, layout controllers, formatting controls, etc. but does not include features such as typing in a code view or choosing from a list of elements that require the author to specify exact elements or attributes. If the tool prompts you for any information during the test, ensure that you provide correct and complete responses. Once this is complete, save the resulting markup and test it for accessibility. If automated accessibility testing tools exist for the language, use them. However, in cases where no automated tool exists or the automated tool only checks a subset of possible errors, it will be necessary to do manual checks, perhaps using a basic text editor to display the markup.

If the generated markup meets all the WCAG Priority 1 checkpoints listed below, answer Yes(Level-A). If the generated markup meets all WCAG Priority 1 and 2 checkpoints listed below, answer Yes(Level-AA). If the generated markup meets all the WCAG checkpoints listed below, answer Yes(Level-AAA). If the generated markup does not meet some WCAG Priority 1 checkpoints, answer No(Does not meet Level-A)

Outstanding WCAG 1.0 Checkpoints:

The following WCAG 1.0 checkpoints still remain to be met by all generated markup in order for the tool to meet the compliance levels listed: [This section only for Yes(Level-AA), Yes(Level-A), No]

Outstanding WCAG Priority 1 checkpoints
(Required to meet Relative Priority Levels A, AA, and AAA)

[Delete checkpoints from this list that the tool DOES meet or that are Not Applicable]

• WCAG ???

Outstanding WCAG Priority 2 checkpoints
(Required to meet Relative Priority Levels AA and AAA)

[Delete checkpoints from this list that the tool DOES meet or that are Not Applicable]

• WCAG ???

Outstanding WCAG Priority 3 checkpoints
(Required to meet Relative Priority Level AAA)

[Delete checkpoints from this list that the tool DOES meet or that are Not Applicable]

• WCAG ???

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

Background:

The purpose of this checkpoint is to ensure that whenever possible authoring will begin with Web content that is already accessible. Imagine loading a template only to find misspelled words and clumsy grammar. Performing a spell check in this situation feels like you're doing someone else's work. The same holds true for accessibility. If the first accessibility check that an author performs turns up problems with the template itself, the author is bound to question the professionalism of the developer or the necessity for accessibility, or both.

For the purposes of ATAG 1.0, templates are considered to be "provided" if they are included with the authoring tool on distribution media (e.g. CD's) or if they are made available specifically to users of the authoring tool (i.e. templates that may be downloaded upon registration).

Evaluation Techniques:

Meets Checkpoint: Yes(Level-A)| Yes(Level-AA) | Yes(Level-AAA) | No(Does not meet Level-A) | Not Applicable
Details: [Provide an explanation for your answer.]

This checkpoint is Not Applicable if the authoring tool does not include any templates.

The test for this checkpoint is very similar to that in the last checkpoint: testing a representative sample of the template files for accessibility, using an automated accessibility testing tool if one exists for the language. Where no automated tool exists or the automated tool only checks a subset of possible errors, it will once again be necessary to do manual checks, perhaps using a basic text editor to display the markup.

If all the tested templates meet all the WCAG Priority 1 checkpoints listed below, answer Yes(Level-A). If the all the tested templates meet all WCAG Priority 1 and 2 checkpoints listed below, answer Yes(Level-AA). If the all the tested templates meet all the WCAG checkpoints listed below, answer Yes(Level-AAA). If the any of the tested templates do not meet some WCAG Priority 1 checkpoints, answer No(Does not meet Level-A)

Outstanding WCAG 1.0 Checkpoints:

The following WCAG 1.0 checkpoints still remain to be met by all the templates in order for the tool to meet the compliance levels listed:[This section only for Yes(Level-A), Yes(Level-AA), No.]

Outstanding WCAG Priority 1 checkpoints
(Required to meet Relative Priority Levels A, AA, and AAA)

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

• WCAG ???

Outstanding WCAG Priority 2 checkpoints
(Required to meet Relative Priority Levels AA and AAA)

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

• WCAG ???

Outstanding WCAG Priority 3 checkpoints
(Required to meet Relative Priority Level AAA)

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

• WCAG ???

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

Yes. [Tool does not remove novel elements and attributes - may refuse to open file.]
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 the author to provide equivalent alternative information (e.g., captions, auditory descriptions, and collated text transcripts for video). [Relative Priority]

Background:

The purpose of this checkpoint is to ensure that authoring tools ask authors for descriptive information that simply cannot be extracted automatically at the present time. This includes labels for images, captions and auditory descriptions for video and text transcripts for audio, along with others.

Evaluation Techniques:

Meets Checkpoint: Yes(Level-AAA) | Yes(Level-AA) | Yes(Level-A) | No (Does not meet Level-A) | Not Applicable
Details: [Provide an explanation for your answer.]

Yes(Level-AAA). [Tool prompts for all WCAG Priority 1, 2 and 3 checkpoints below.]
Yes(Level-AA). [Tool prompts for all WCAG Priority 1 and 2 checkpoints below.]
Yes(Level-A). [Tool prompts for all WCAG Priority 1 checkpoints below.]
No (Does not meet Level-A). [Tool does not prompt for all WCAG Priority 1 checkpoints below.]

Outstanding WCAG 1.0 Checkpoints:

The following WCAG 1.0 checkpoints related to equivalent alternatives still remain to be prompted for within the tool interface in order to meet the compliance levels listed: [This section only for Yes(Level-A), Yes(Level-AA), No.]

Outstanding WCAG Priority 1 checkpoints
(Required to meet Relative Priority Levels A, AA, and AAA)

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

• WCAG ???

Details: [Provide an explanation for your answer.]

Outstanding WCAG Priority 2 checkpoints
(Required to meet Relative Priority Levels AA and AAA)

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

• WCAG ???

Details: [Provide an explanation for your answer.]

Outstanding WCAG Priority 3 checkpoints
(Required to meet Relative Priority Level AAA)

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

• WCAG ???

3.2 Help the author create structured content and separate information from its presentation. [Relative Priority]

Yes(Level-AAA). [Tool helps to create content that meets all WCAG Priority 1, 2 and 3 checkpoints below.]
Yes(Level-AA). [Tool helps to create content that meets all WCAG Priority 1 and 2 checkpoints below.]
Yes(Level-A). [Tool helps to create content that meets all WCAG Priority 1 checkpoints below.]
No (Does not meet Level-A). [Tool does not help to create content that meets all WCAG Priority 1 checkpoints below.]

[This section only for Yes(Level-A), Yes(Level-AA), No]
The following WCAG 1.0 checkpoints related to this separation still remain to be addressed within the tool interface in order to meet the compliance levels listed:

Outstanding WCAG Priority 1 checkpoints
(Required to meet Relative Priority Levels A, AA, and AAA)

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

• WCAG ???

Details: [Provide an explanation for your answer.]

Outstanding WCAG Priority 2 checkpoints
(Required to meet Relative Priority Levels AA and AAA)

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

• WCAG ???

Details: [Provide an explanation for your answer.]

Outstanding WCAG Priority 3 checkpoints
(Required to meet Relative Priority Level AAA)

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

• WCAG ???

Details: [Provide an explanation for your answer.]

3.3 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. [Tool does not create "alt" text or other equivalent alternatives from the file name, etc. and place the text into the markup without notifying the author.]
No. [Tool does not meet the above condition.]
Not Applicable. [Tool does not allow non-text elements to be produced.]

Details: [Provide an explanation for your answer.]

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

Yes. [Tool manages alternative equivalents - may include suggesting text previously written for an object.]
No. [Tool does not meet the above condition.]
Not Applicable. [Tool does not allow non-text elements to be produced.]

Details: [Provide an explanation for your answer.]

Checking and correcting inaccessible content:

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

Yes(Level-AAA). [Tool checks for all WCAG Priority 1, 2 and 3 checkpoints below.]
Yes(Level-AA). [Tool checks for all WCAG Priority 1 and 2 checkpoints below.]
Yes(Level-A). [Tool checks for all WCAG Priority 1 checkpoints below.]
No Checker (Does not meet Level-A). [No checking function.]
No (Does not meet Level-A). [Tool has checker but it does not check for all WCAG Priority 1 checkpoints below.]

[This section only for Yes(Level-A), Yes(Level-AA), No]
The following WCAG 1.0 checkpoints still remain to be checked in order for the tool to meet the compliance levels listed:

Outstanding WCAG Priority 1 checkpoints
(Required to meet Relative Priority Levels A, AA, and AAA)

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

• WCAG ???

Details: [Provide an explanation for your answer.]

Outstanding WCAG Priority 2 checkpoints
(Required to meet Relative Priority Levels AA and AAA)

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

• WCAG ???

Details: [Provide an explanation for your answer.]

Outstanding WCAG Priority 3 checkpoints
(Required to meet Relative Priority Level AAA)

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

• WCAG ???

Details: [Provide an explanation for your answer.]

3.6 Assist authors in correcting accessibility problems. [Relative Priority]

Yes(Level-AAA). [Tool helps correct all WCAG Priority 1, 2 and 3 checkpoints below.]
Yes(Level-AA). [Tool helps correct all WCAG Priority 1 and 2 checkpoints below.]
Yes(Level-A). [Tool helps correct all WCAG Priority 1 checkpoints below.]
No Correcting (Does not meet Level-A). [No correcting function.]
No (Does not meet Level-A). [Tool does not help to correct all WCAG Priority 1 checkpoints below.]

[This section only for Yes(Level-A), Yes(Level-AA), No]
The following WCAG 1.0 checkpoints still remain to be implemented in a correction assistance system in order for the tool to meet the compliance levels listed:

Outstanding WCAG Priority 1 checkpoints
(Required to meet Relative Priority Levels A, AA, and AAA)

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

• WCAG ???

Details: [Provide an explanation for your answer.]

Outstanding WCAG Priority 2 checkpoints
(Required to meet Relative Priority Levels AA and AAA)

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

• WCAG ???

Details: [Provide an explanation for your answer.]

Outstanding WCAG Priority 3 checkpoints
(Required to meet Relative Priority Level AAA)

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

• WCAG ???

Details: [Provide an explanation for your answer.]

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

Yes. [Tool provides a summary - ex. checker results.]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

Promoting accessibility in help and documentation:

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

Yes. [Tool documents the features of the tool (prompts, checker, etc.) that are involved with the production of accessible content.]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

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

Yes. [Tool has the documentation from 6.1 set aside in a single section of the Help documentation.]
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 the functionalities for checkpoints 3.1, 3.2, 3.5 and 3.6 are always clearly available to the user [Priority 1]

4.2 Ensure that accessible authoring practices supporting the minimum requirements for all WCAG checkpoints are among the most obvious and easily initiated by the author. [Priority 2]

Yes. [Tool ensures that accessible markup practices are used for all one click functionality - including formatting tool bar buttons, menus, etc.]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

4.3 Ensure that all functionality (prompts, checkers, information icons, etc.) related to accessible authoring practices is naturally integrated into the overall look and feel of the tool. [Priority 2]

Yes. [Tool integrates has accessibility-related functions such as checkers and prompts to the point that they look and act like all the other parts of the program - they do not appear separate.]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]

4.4 Ensure that creating accessible content is a naturally integrated part of the documentation, including examples. [Priority ?]

Yes. [Tool does not include examples of inaccessible markup (except to show inaccessible markup).]
No. [Tool does not meet the above condition.]

Details: [Provide an explanation for your answer.]