W3C

(Draft) ATAG 2.0 Testing Resources

6 December 2013

This page provides an overview of the tools and resources that are needed to test authoring tools for conformance with ATAG 2.0 and provides a listing of all of the test cases that will be loaded into the W3C Conformance Test Framework.

Decisions to Make Prior to Testing:

  1. Decide on a target ATAG 2.0 level to test for (Level A, AA, AAA). This decision will determine (a) the number of ATAG 2.0 success criteria that need to be evaluated and (b) the number of WCAG 2.0 success criteria that will need to be evaluated as part of the Web Content Accessibility Test Procedure. If the tool was only designed to conform at Level A, it will be much easier to simply test it at that level.
  2. Decide on the web content technologies produced by the authoring tool that are to be "included". Some authoring tools, especially general-purpose editors, provide support for authoring with a variety of web content technologies (e.g. HTML4, HTML5, SVG, MathML, etc.). ATAG 2.0 allows authoring tools to conform with respect to just a defined subset of the technologies produced.
    Note: If the authoring tool produces any web content technologies by default, then these must be included.

Tools and Resources Needed for Testing ATAG 2.0 Success Criteria:

1. Web Content Accessibility Test Procedure (Level A, AA, AAA):

Many ATAG 2.0 success criteria refer to meeting WCAG 2.0 success criteria. In order to test these success criteria, you will need a Web Content Accessibility Testing Procedure that is: (a) specific to the "included" web content technology (e.g. HTML, CSS, SVG, etc.) produced by the authoring tool and (b) designed to test WCAG 2.0 conformance to at least the target level (e.g. Level AA). Such a test procedure may include:

Note: The WCAG 2.0 requirement that "only accessibility-supported ways of using technologies are relied upon to satisfy the WCAG 2.0 success criteria" does not need to be applied as described in ATAG 2.0 section Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0.

2. Platform Accessibility Service Test Procedure:

This is the procedure that is to be used whenever it is necessary to determine whether information has been properly communicated to an Platform Accessibility Service (e.g. MSAA, IAccessible2 and UI Automation for Windows applications, AXAPI for Mac OS X applications, GNOME Accessibility Toolkit API for GNOME applications, Java Access for Java applications.

For some platforms, semi-automated testing solutions may also exist (e.g. inspect32 (for Windows), AccProbe (for Windows), Accersisor (for Gnome) , Accessibility Inspector (for Mac OSX).

3. User Agent Accessibility Test Procedure (Level A only):

This procedure is used if it is necessary to determine whether a preview meets UAAG. For UAAG 1.0, the most complete test is the UAAG 1.0 Test Suite for HTML 4.01.

Important Note: This tool is not required if previews can be performed in an in-market user agent (see ATAG 2.0 Success Criterion A.3.7.1 for more information).

4. Accessible test content file (Level A, AA, AAA):

This pristine, accessible content is needed to test criteria such as whether content transformations lose accessibility information and whether checkers detect false positives, etc. The method for loading this content will depend on the nature of the authoring tool (e.g. opening a test file, pasting in content, authoring the content manually). The test content should:

Note: This test content may not be needed if the tool does not import content or allow markup to be pasted in.

5. Non-accessible test content file (Level A, AA, AAA):

This non-accessible content is used to whether test checkers are effective at detecting issues. The method for loading this content will depend on the nature of the authoring tool (e.g. opening a test file, pasting in content, authoring the content manually)

Note: This test content may not be needed if the tool does not import content or allow markup to be pasted in.

6. A selection of separate pieces of content:

These pieces of content will be used, as needed, to test various success criteria. The method for loading this content will depend on the nature of the authoring tool (e.g. opening a test file, pasting in content, authoring the content manually). Should include:

7. List of "accessible content support features" (may be created during testing):

While testing the authoring tool against all of the following relevant success criteria, compile a list of the authoring tool features that are relevant to each test (they do not necessarily have to pass) as well as whether the feature can be turned off, either directly from where it appears in the user interface (e.g. via a "Do not show this again" dialog) or from the authoring tool settings.

Relevant Success Criteria:

Test Cases for the ATAG 2.0 Success Criteria

Once approved, these test cases will be loaded into the W3C Conformance Test Framework.

Note: ATAG 2.0 includes "applicability notes" that help constrain the scope of the success criteria.

PART A: Make the authoring tool user interface accessible Tests
PRINCIPLE A.1: Authoring tool user interfaces follow applicable accessibility guidelines Tests
Guideline A.1.1: (For the authoring tool user interface) Ensure that web-based functionality is accessible. Tests

A.1.1.1 Web-Based Accessible (WCAG):

If the authoring tool contains web-based user interfaces, then those web-based user interfaces meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

@@[Approved: https://www.w3.org/2002/09/wbs/35520/20130107/results#xq5]

Test 0001 Assertion: Any web-based portions of an authoring tool user interface meet WCAG 2.0 at A level.

  1. If no parts of the authoring tool are web-based (i.e. they are rendered within a user agent), then select SKIP.
  2. If the web-based parts include editing views (as opposed to only documentation, etc.), then load the accessible test content file (Level A).
  3. Check the web-based parts of the authoring tool with the Web Content Accessibility Test Procedure (Level A).
  4. If WCAG 2.0 Level A is reached, select PASS, otherwise select FAIL.

Test 0002 Assertion: Any web-based portions of an authoring tool user interface meet WCAG 2.0 at AA level. (Note: Only shown if the user has specified AA or AAA as the target level)

  1. If no parts of the authoring tool are web-based (i.e. they are rendered within a user agent), then select SKIP.
  2. If the web-based parts include editing views (as opposed to only documentation, etc.), then load the accessible test content file (Level AA).
  3. Check the web-based parts of the authoring tool with the Web Content Accessibility Test Procedure (Level AA).
  4. If WCAG 2.0 Level AA is reached, select PASS, otherwise select FAIL.

Test 0003 Assertion: Any web-based portions of an authoring tool user interface meet WCAG 2.0 at AAA level. (Note: Only shown if the user has specified AAA as the target level)

  1. If no parts of the authoring tool are web-based (i.e. they are rendered within a user agent), then select SKIP.
  2. If the web-based parts include editing views (as opposed to only documentation, etc.), then load the accessible test content file (Level AAA).
  3. Check the web-based parts of the authoring tool with the Web Content Accessibility Test Procedure (Level AAA).
  4. If WCAG 2.0 Level AAA is reached, select PASS, otherwise select FAIL.
Guideline A.1.2: (For the authoring tool user interface) Ensure that non-web-based functionality is accessible. Tests

A.1.2.1 Accessibility Guidelines:

If the authoring tool contains non-web-based user interfaces, then those non-web-based user interfaces follow user interface accessibility guidelines for the platform. (Level A)
  • Note: The (optional) explanation of conformance claim results should record the user interface accessibility guidelines that were followed.

@@[Approved https://www.w3.org/2002/09/wbs/35520/20130107/results#xq6]

Test 0001 Assertion: Any non-web-based portions of the authoring tool user interface follow the accessibility guidelines for the platform.

  1. If the authoring tool is entirely web-based (i.e. lacking any functionality that runs outside of a user agent), then select SKIP.
  2. If the non-web-based parts include editing views (as opposed to only a file uploader, etc.), then load the accessible test content file (any level).
  3. If the accessibility guideline (for the platform) that was used by the developer is known, this should be used to test the accessibility of the user interface. If the user interface has followed the guidelines, then select PASS, otherwise select FAIL.
  4. If the accessibility guideline (for the platform) that was used by the developer is not known, choose the most relevant from this list of user interface accessibility guidelines for various platforms and use it to test the accessibility of the user interface. If you find instances where the user interface has not followed the guidelines, then select FAIL, otherwise select PASS.

A.1.2.2 Platform Accessibility Services:

If the authoring tool contains non-web-based user interfaces, then those non-web-based user interfaces expose accessibility information through platform accessibility services. (Level A)
  • Note: The (optional) explanation of conformance claim results should record the platform accessibility service(s) that were implemented.

@@[Approved https://www.w3.org/2002/09/wbs/35520/20130107/results#xq7]

Test 0001 Assertion: Any non-web-based components of the authoring tool user interface successfully communicate name and role with the platform accessibility services (accessibility APIs).

  1. Examine the authoring tool user interface to determine whether any parts of it are not web-based (i.e. they run outside of a user agent).
  2. If the authoring tool is entirely web-based, then select SKIP.
  3. For each non-web-based operable user interface component in the authoring tool user interface:
    1. Check the component with the Platform Accessibility Service Test Procedure to determine if it is (a) present, (b) has an accessible name and (c) has an appropriate UI component role.
    2. If any of (a)-(c) are not the case for any user interface components, then select FAIL.
    3. Go to the next non-web-based operable user interface component (if any).
  4. Select PASS (all of the non-web-based components must have passed)
PRINCIPLE A.2: Editing-views are perceivable Tests
Guideline A.2.1: (For the authoring tool user interface) Make alternative content available to authors. Tests

A.2.1.1 Text Alternatives for Rendered Non-Text Content:

If an editing-view renders non-text content, then any programmatically associated text alternatives for the non-text content can be programmatically determined. (Level A)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: In any web-based editing views, rendered non-text content include any text alternatives to meet WCAG 2.0 1.1.1.

  1. If the authoring tool does not include editing views that are capable of rendering non-text content (e.g. images), then select SKIP.
  2. If the authoring tool's editing views that render non-text content are only non-web-based, then select SKIP.
  3. For each web-based editing view that renders non-text content:
    1. If the editing view is situated in an authoring workflow prior to the point at which text alternatives exist (e.g. the editing view is intended to be used to create graphics for import into a markup editor), then go to the next web-based editing view that renders non-text content (if any).
    2. Load the accessible test content file (any level), which contains non-text content with text alternatives, in the editing view.
    3. Using the Web Content Accessibility Test Procedure, check if WCAG2 SC 1.1.1 is passed by the editing view. If not, select FAIL.
    4. Go to the next web-based editing view that renders non-text content (if any).
  4. Select PASS (all editing views must have passed)

Test 0002 Assertion: In any non-web-based editing views, rendered non-text content with text alternatives can have those text alternatives programmatically determined.

  1. If the authoring tool does not include editing views that are capable of rendering non-text content (e.g. images), then select SKIP.
  2. If the authoring tool's editing views that render non-text content are only web-based, then select SKIP.
  3. For each non-web-based editing view that renders non-text content:
    1. If the editing view is situated in an authoring workflow prior to the point at which text alternatives exist (e.g. the editing view is intended to be used to create graphics for import into a markup editor), then go to the next non-web-based editing view that renders non-text content (if any).
    2. Load the accessible test content file (any level), which contains non-text content with text alternatives, in the editing view.
    3. For each rendered instance of non-text content:
      1. Check with Platform Accessibility Service Test Procedure to determine if an accessible name/label is present in the accessibility API. If not, select FAIL.
      2. Go to the next rendered instance of non-text content (if any).
    4. Go to the next non-web-based editing view that renders non-text content (if any).
  4. Select PASS (all editing views must have passed)

A.2.1.2 Alternatives for Rendered Time-Based Media:

If an editing-view renders time-based media, then at least one of the following is true: (Level A)

  • (a) Option to Render: The authoring tool provides the option to render alternatives for the time-based media; or
  • (b) User Agent Option: Authors have the option to preview the time-based media in a user agent that is able to render the alternatives.

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Any editing views that render audio-video include an option to display alternatives or an option to preview the media in user agent capable of rendering the alternatives.

  1. If the media alternatives for the format are in a non-included format, then select SKIP.
  2. If the authoring tool does not include editing views that are capable of rendering audio-video content, then select SKIP.
  3. For each editing view that renders audio-video:
    1. If the editing view is situated in an authoring workflow prior to the point at which alternatives exist (e.g. the editing view is intended to be used to create audio-video for import into a caption editor), then go to the editing view that renders audio-video (if any).
    2. Load the accessible test content file (any level), which contains time-based media (audio-video) with alternatives (e.g. captions, transcripts, audio-description), in the editing view.
    3. Check if the authoring tool allows the content being edited to be previewed in a user agent (e.g. browser or media player) where the alternatives can be rendered. If so, go to the next editing view that renders audio-video.
    4. Check if the authoring tool can render the alternatives itself. If not, select FAIL.
    5. Go to the next editing view that renders audio-video (if any).
  4. Select PASS (all editing views must have passed)

Test 0002 Assertion: Any editing views that render video-only media include an option to display alternatives or an option to preview the media in user agent capable of rendering the alternatives.

  1. If the media alternatives for the format are in a non-included format, then select SKIP.
  2. If the authoring tool does not include editing views that are capable of rendering video-only content, then select SKIP.
  3. For each editing view that renders video-only media:
    1. If the editing view is situated in an authoring workflow prior to the point at which alternatives exist (e.g. the editing view is intended to be used to create video-only content for import into an audio description utility), then go to the editing view that renders video-only (if any).
    2. Load the accessible test content file (any level), which contains time-based media (video-only) with alternatives (e.g. transcripts, audio-description), in the editing view.
    3. Check if the authoring tool allows the content being edited to be previewed in a user agent (e.g. browser or media player) where the alternatives can be rendered. If so, go to the next editing view that renders video-only media.
    4. Check if the authoring tool can render the alternatives itself. If not, select FAIL.
    5. Go to the next editing view that renders video-only media (if any).
  4. Select PASS (all editing views must have passed)

Test 0003 Assertion: Any editing views that render audio-only media include an option to display alternatives or an option to preview the media in user agent capable of rendering the alternatives.

  1. If the media alternatives for the format are in a non-included format, then select SKIP.
  2. If the authoring tool does not include editing views that are capable of rendering audio-only content, then select SKIP.
  3. For each editing view that renders audio-only media:
    1. If the editing view is situated in an authoring workflow prior to the point at which alternatives exist (e.g. the editing view is intended to be used to create audio-only content for import into a transcript editor), then go to the editing view that renders audio-only (if any).
    2. Load the accessible test content file (any level), which contains time-based media (audio-only) with alternatives (e.g. transcripts, alternative for time-based media), in the editing view.
    3. Check if the authoring tool allows the content being edited to be previewed in a user agent (e.g. browser or media player) where the alternatives can be rendered. If so, go to the next editing view that renders audio-only media.
    4. Check if the authoring tool can render the alternatives itself. If not, select FAIL.
    5. Go to the next editing view that renders audio-only media (if any).
  4. Select PASS (all editing views must have passed)
Guideline A.2.2: (For the authoring tool user interface) Ensure that editing-view presentation can be programmatically determined. Tests

A.2.2.1 Editing-View Status Indicators:

If an editing-view adds status indicators to the content being edited, then the information being conveyed by the status indicators can be programmatically determined. (Level A)

  • Note: Status indicators may indicate errors (e.g. spelling errors), tracked changes, hidden elements, or other information.

@@[Approved https://www.w3.org/2002/09/wbs/35520/20130107/results#xq10]

Test 0001 Assertion: For web-based tools: Status information about the content (e.g. spell checking) can be programmatically determined.

  1. If the editing view is non-web-based, then select SKIP.
  2. Check all of the editing-views for status indicators (often used to indicate errors (e.g. spelling errors), tracked changes, hidden elements, or other information.), possibly from a product feature list or trial and error.
  3. If the authoring tool does not provide status indicators in any of its editing-views, select SKIP.
  4. For each type of status indicator:
    1. Open or author content that will trigger the status indicator (e.g. with spelling errors, add a hidden element, etc.), then examine the indicator with the Web Content Accessibility Test Procedure. If an indicator does not pass, then select FAIL.
    2. Go to the next type of status indicator (if any).
  5. Select PASS (all indicators must have passed)

Test 0002 Assertion: For non-web-based tools: Status information about the content (e.g. spell checking) can be programmatically determined.

  1. If the editing view is web-based, then select SKIP.
  2. Check all of the editing-views for status indicators (often used to indicate errors (e.g. spelling errors), tracked changes, hidden elements, or other information.), possibly from a product feature list or trial and error.
  3. If the authoring tool does not provide status indicators in any of its editing-views, select SKIP.
  4. For each type of status indicator:
    1. Open or author content that will trigger the status indicator (e.g. with spelling errors, add a hidden element, etc.), then examine the indicator with the Platform Accessibility Service Test Procedure to determine if the indicator (e.g. the validation error) has been communicated to the accessibility API. If an indicator does not pass, then select FAIL.
    2. Go to the next type of status indicator (if any).
  5. Select PASS (all indicators must have passed)

A.2.2.2 Access to Rendered Text Properties:

If an editing-view renders any text formatting properties that authors can also edit using the editing-view, then the properties can be programmatically determined. (Level AA)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: For web-based tools, if rich text formatting can be produced then authors the same formatting is programmatically determinable within the authoring tool.

  1. If the authoring tool does not include any web-based editing views, then select SKIP.
  2. If the authoring tool cannot be used to author rich text content (e.g. because it is only edits non-text graphics), then select SKIP.
  3. If the authoring tool can be used to author rich text content, but none of its editing views render this rich text content, then select SKIP. (Note: Some text editors render text content (e.g. markup tags, programming keywords, etc.) with various colors, bold weight, etc. These author supports are not part of the content and do not qualify here)
  4. For each editing view that renders rich text content:
    1. Add some text content and (one per line to avoid overlap), use as many rich text formats as possible (e.g. bold, italic, font face, superscript, etc).
    2. Produce a version of the final output (for comparison)
    3. Use a web content markup examination tool to examine how the rich text in the editing-view is actually presented via the user agent.
    4. If the markup matches that produced in the final output, then go the next editing view that renders rich text content.
    5. If the rich text is presented via means that block programmatic determinability (e.g. using space gifs to mimic wider spacing, using a positioned div to mimic superscript), then select FAIL.
    6. Go the next editing view that renders rich text content (if any).
  5. Select PASS (all editing views must have passed)

Test 0002 Assertion: For non-web-based tools: Text formatting is available via the platform accessibility service (e.g. API).

  1. If the authoring tool only includes web-based editing views, then select SKIP.
  2. If the authoring tool cannot be used to author rich text content (e.g. because it is only edits non-text graphics), then select SKIP.
  3. If the authoring tool can be used to author rich text content, but none of its editing views render this rich text content, then select SKIP. (Note: Some text editors render text content (e.g. markup tags, programming keywords, etc.) with various colors, bold weight, etc. These author supports are not part of the content and do not qualify here)
  4. For each editing view that renders rich text content:
    1. Add some text content and (one per line to avoid overlap), use as many rich text formats as possible (e.g. bold, italic, underlined, font face, superscript, etc).
    2. Using a platform accessibility service test procedure (or screen reader that is appropriate to the platform), attempt to identify the following text formatting properties (if they could be edited in the previous step): font face, font size, font color, whether text is bold, whether text is italic. If they cannot be identified, then select FAIL.
    3. Go the next editing view that renders rich text content (if any).
  5. Select PASS (all editing views must have passed)
PRINCIPLE A.3: Editing-views are operable Tests
Guideline A.3.1: (For the authoring tool user interface) Provide keyboard access to authoring features. Tests

A.3.1.1 Keyboard Access (Minimum):

All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)

  • Note 1: Keyboard interfaces are programmatic services provided by many platforms that allow operation in a device independent manner. This success criterion does not imply the presence of a hardware keyboard.
  • Note 2: The path exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input, but the underlying function (text input) does not. The path exception encompasses other input variables that are continuously sampled from pointing devices, including pressure, speed, and angle.
  • Note 3: This success criterion does not forbid and should not discourage other input methods (e.g. mouse, touch) in addition to keyboard operation.

@@[Approved http://www.w3.org/2013/02/11-au-minutes.html]

Test 0001 Assertion: For web-based tools: All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

  1. If the authoring tool does not include any web-based user interface functionality, then select SKIP.
  2. Using the Web Content Accessibility Test Procedure, check the entire web-based user interface to determine whether WCAG2 SC 2.1.1 is passed. If the success criterion has been satisfied, then select PASS, otherwise select FAIL.

Test 0002 Assertion: For non-web-based tools: All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

  1. If the authoring tool only includes web-based user interface functionality, then select SKIP.
  2. If the platform on which the authoring tool is installed cannot be used with a keyboard (i.e. a mobile device that lacks a built in keyboard and cannot be connected via USB, Bluetooth, etc. to any form of external keyboard), then select FAIL. (Note: If this is due to limitations of the platform, "Partial Conformance due to Platform Limitation" is still possible.)
  3. If an external keyboard is required, attach one.
  4. Open authoring tool on the selected platform and document (list) all functions of authoring tool (this could be from authoring tool documentation or author experience with the tool). Do not include any functions where path-dependent input is required. The path exception includes the any data continuously collected from pointing devices, including pressure, speed, and angle (e.g. a paintbrush tool in a graphics editor).
  5. For each function in the list:
    1. Check that the function works correctly with the keyboard. If it does not, then select FAIL.
    2. Check the system for situations in which a key press has a time limit. If any key press time limit is found to be less than 20 seconds, then select FAIL.
    3. Go to the next function in the list (if any).
  6. Select PASS (all functions must have passed)

A.3.1.2 No Keyboard Traps:

If keyboard focus can be moved to a component using a keyboard interface, then focus can be moved away from that component using only a keyboard interface. If it requires more than unmodified arrow or tab keys or other standard exit methods, authors are advised of the method for moving focus away. (Level A)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: For web-based tools: If keyboard focus can be moved to a component using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, authors are advised of the method for moving focus away.

  1. If the authoring tool does not include any web-based user interface functionality, then select SKIP.
  2. Using the Web Content Accessibility Test Procedure, check the entire web-based user interface to determine whether WCAG2 SC 2.1.2 is passed. If the success criterion has been satisfied, then select PASS, otherwise select FAIL.

Test 0002 Assertion: For non-web-based tools: If keyboard focus can be moved to a component using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, authors are advised of the method for moving focus away.

  1. If the authoring tool only includes web-based user interface functionality, then select SKIP.
  2. If the platform on which the authoring tool is installed cannot be used with a keyboard (i.e. a mobile device that lacks a built in keyboard and cannot be connected via USB, Bluetooth, etc. to any form of external keyboard), then select SKIP. (Note: If this is due to limitations of the platform, "Partial Conformance due to Platform Limitation" is still possible.)
  3. Determine whether there is a mechanism for traversing a visible keyboard focus through the user interface. If not, then select SKIP.
  4. For each screen of the user interface:
    1. Use the mechanism to traverse the user interface controls.
    2. If all of the user interface controls that receive focus from the keyboard can also relinquish it (to the next or previous control), then go to the next screen of the user interface.
    3. If keyboard focus can be forced to leave a control using a standard exit method (e.g. Esc), then go to the next screen of the user interface.
    4. If the author is advised, from the current control, of a keyboard-only method for moving focus away, then go to the next screen of the user interface.
    5. Go to the next screen (if any).
  5. Select PASS (all of the screens must not include any keyboard traps)

A.3.1.3 Efficient Keyboard Access:

The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard access. (Level AA)

@@[Approved https://www.w3.org/2002/09/wbs/35520/20130107-2/results#xq5]

Test 0001 Assertion: The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard access.

  1. If the platform on which the authoring tool is installed cannot be used with a keyboard (i.e. a mobile device that lacks a built in keyboard and cannot be connected via USB, Bluetooth, etc. to any form of external keyboard), then select SKIP. (Note: If this is due to limitations of the platform, "Partial Conformance due to Platform Limitation" is still possible.)
  2. If the authoring tool supports at least two direct keyboard commands (e.g. a special key such as command, control, alt, shift, etc. plus another key), then select PASS.
  3. Determine whether there is a mechanism for traversing a visible keyboard focus through the user interface. If not, then select SKIP.
  4. Determine whether there is a mechanism for traversing a visible keyboard focus through all of the user interface components in a sequential fashion. If not, then select SKIP.
  5. Determine if there is any method of moving the focus more directly to interface components that occur later in the sequential order than simply traversing all of the intervening controls (e.g. page up, page down, home, end, skip to links, etc.). If at least two exist, then select select PASS. Otherwise, select FAIL.

A.3.1.4 Keyboard Access (Enhanced):

All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level AAA)

 

@@[Approved http://www.w3.org/2013/02/11-au-minutes.html]

Test 0001 Assertion: All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes.

  1. If the platform on which the authoring tool is installed cannot be used with a keyboard (i.e. a mobile device that lacks a built in keyboard and cannot be connected via USB, Bluetooth, etc. to any form of external keyboard), then select FAIL. (Note: If this is due to limitations of the platform, "Partial Conformance due to Platform Limitation" is still possible.)
  2. If an external keyboard is required, attach one.
  3. Open authoring tool on the selected platform and document (list) all functions of authoring tool (this could be from authoring tool documentation or author experience with the tool).
  4. For each function in the list:
    1. Check that the function works correctly with the keyboard. If it does not, then select FAIL.
    2. Check that the system never requires the user to press a key within a time period of less than 20 seconds. If this is ever the case, then select FAIL.
    3. Go to the next function in the list (if any).
  5. Select PASS (all functions must have passed)

A.3.1.5 Customize Keyboard Access:

If the authoring tool includes keyboard commands, then those keyboard commands can be customized. (Level AAA)

 

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Keyboard commands can be customized.

  1. If the authoring tool does not include keyboard commands, then select SKIP.
  2. Examine the authoring tool for at least one mechanism whereby a keyboard command can be customized such that another keyboard command can accomplish the same action (e.g. some tools have utilities that present all available actions and then allow the author to set which keyboard command activates each).
  3. If a mechanism is found, select PASS. Otherwise, select FAIL.

A.3.1.6 Present Keyboard Commands:

If the authoring tool includes keyboard commands,

then the authoring tool provides a way for authors to determine the keyboard commands associated with authoring tool user interface components. (Level AAA)

@@[Approved https://www.w3.org/2002/09/wbs/35520/20130107-2/results#xq8]

Test 0001 Assertion: Keyboard Commands can be associated with User Interface Components

  1. If the authoring tool does not include keyboard commands, then select SKIP.
  2. For each user interface screen:
    1. Document all keyboard commands that can directly activate user interface components on this screen (from user experience or authoring tool documentation).
    2. For each user interface control that can be activated with a direct keyboard command:
      1. Check whether the command is visually associated with the control, either always or via any kind of keyboard command overlay. If not, then select FAIL.
      2. Go to the next user interface control that can be activated with a direct keyboard command (if any).
    3. Go to the next user interface screen (if any).
  3. Select PASS (all authoring tool user interface components must have associated keyboard command(s))
Guideline A.3.2: (For the authoring tool user interface) Provide authors with enough time. Tests

A.3.2.1 Auto-Save (Minimum):

The authoring tool does not include session time limits or the authoring tool can automatically save edits made before the session time limits are reached. (Level A)

@@[Approved https://www.w3.org/2002/09/wbs/35520/20130107-2/results#xq9]

Test 0001 Assertion: All time limits implement auto-save.

  1. Examine the user interface of the authoring tools for time limits on authoring sessions (e.g. automatic logout).
  2. If the authoring tool does not have any time limits, then select PASS.
  3. For each time limit on an authoring session:
    1. Check to determine if the authoring tool can be configured (or is already configured) to automatically save any edits to web content before that time limit is reached. If not, then select FAIL.
    2. Test the functionality by authoring content and then allowing the time limit to occur. If the web content changes cannot be recovered, then select FAIL.
    3. Go to the next time limit on an authoring session (if any).
  4. Select PASS (all time limits must have passed)

 

A.3.2.2 Timing Adjustable:

The authoring tool does not include time limits or at least one of the following is true: (Level A)

  • (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.

@@[Approved https://www.w3.org/2002/09/wbs/35520/20130107-2/results#xq10]

Test 0001 Time limits set by authoring tools can be turned off, adjusted, extended, are real-time exceptions, are essential, or exceed 20 hours.

  1. Examine the user interface of the authoring tools for time limits (e.g. automatic logout). The time limit must be controlled by the authoring tool and not a larger system of which the authoring tool might be just a part.
  2. If the authoring tool does not have any time limits (e.g. an automatic logout), then select PASS.
  3. For each time limit set by the authoring tool:
    1. If the authoring tool time limit is a real-time exception, meaning that 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, then go to the next time limit.
    2. If the time limit is essential and extending it would invalidate the activity, then go to the next time limit.
    3. If the time limit is longer than 20 hours, then go to the next time limit.
    4. If authors can turn off the time limit before encountering, then go to the next time limit.
    5. If authors are warned before each time limit expires and are 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, then go to the next time limit.
    6. If authors are allowed to adjust the time limit before encountering it, check the configuration parameters to insure that the time adjustment options are over a wide range that is at least ten times the length of the default setting. If this is true, then go to the next time limit.
    7. If the authoring tool has time limits, and none of the above statements are true, then select FAIL.
    8. Go to the next time limit (if any).
  4. Select PASS (all time limits must have passed)

A.3.2.3 Static Input Components:

The authoring tool does not include moving user interface components that accespt input where the movement of these components cannot be paused by authors. (Level A)

@@[Approved http://www.w3.org/2013/02/11-au-minutes.html]

Test 0001 Assertion: If components of the authoring tool user interface can move, the author can pause the movement.

  1. If no parts of the authoring tool user interface can move (e.g. a moving scrub bar control), then select PASS.
  2. For each part of the authoring tool user interface that can move:
    1. If there is no way to pause or stop the motion (e.g. stop button, pause button), then select FAIL.
    2. Go to the next part of the authoring tool user interface that can move (if any).
  3. Select PASS (all moving parts of the user interface must have passed).

A.3.2.4 Content Edits Saved (Extended):

The authoring tool can be set to automatically save web content edits made using the authoring tool. (Level AAA)

@@[Approved http://www.w3.org/2013/02/11-au-minutes.html]

Test 0001 Assertion: The authoring tool automatically saves edits or has a configuration option to automatically save edits.

  1. Check the preference settings and documentation. If there is an option to automatically save edits, activate that feature.
  2. Use a sample test file to load some content into the authoring tool. Make a noticeable, but minor change to the content. If there is a visible indication that the file has been automatically saved, select PASS.
  3. Otherwise, wait for a period that exceeds the auto-save period, close the file without manually saving the changes.
  4. Reopen the file. If the change you made is displayed correctly, select PASS. If the change was not saved, select FAIL.
Guideline A.3.3: (For the authoring tool user interface) Help authors avoid flashing that could cause seizures. Tests

A.3.3.1 Static View Option:

If an editing-view can play visual time-based content, then playing is not necessarily automatic upon loading the content and playing can be paused. (Level A)

@@[Approved http://www.w3.org/2013/02/11-au-minutes.html]

Test 0001 Assertion: If the authoring tool contains editing-views that play visual time-based content, then those editing-views do not necessarily play the media automatically and can be paused

  1. If the authoring tool cannot be used to edit time-based content such as video, animation, animated gifs etc., then select SKIP
  2. If the authoring tool does not include editing views that render visual time-based content such as video, animation, animated gifs etc., then select SKIP
  3. If the renderings are non-editable, such as previews, then select SKIP.
  4. For each editing view that renders and plays visual time-based content:
    1. Load sample video (audio, animation, animated gifs etc.)
    2. If the editing view does not automatically play time-based content automatically, then go the next editing view that renders and plays visual time-based content (if any).
    3. If the authoring tool can be set to never play time-based content automatically AND once playing the content can be paused, then go the next editing view that renders and plays visual time-based content (if any).
    4. If the editing view is web-based and the browser can be used to prevent auto-play and to pause the playing content then go the next editing view that renders and plays visual time-based content (if any).
    5. Go the next editing view that renders and plays visual time-based content (if any).
  5. Select PASS (all editing views must have passed)
Guideline A.3.4: (For the authoring tool user interface) Enhance navigation and editing via content structure. Tests

A.3.4.1 Navigate By Structure:

If editing-views expose the markup elements in the web content being edited, then the markup elements (e.g. source code, content renderings) are selectable and navigation mechanisms are provided to move the selection focus between elements. (Level AA)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Markup elements (e.g. source code, content renderings) are selectable and navigation mechanisms are provided to move the selection focus between elements

  1. If the web content technology(ies) being produced do not include any structure (e.g. plain text editing, raster graphic editing) then select is SKIP
  2. If the authoring tool is designed such that markup elements are never exposed to the author, then select is SKIP
  3. Where markup elements are exposed to the user (e.g. document outline view, source view, etc.), check whether it is possible to select a single exposed element (without selecting other content that surrounds it. If not, then select FAIL.
  4. With focus on a single element, check whether there is a mechanism for moving focus to another element (e.g. in a tree hierarchy to a child, parent or sibling element). If the only way to move selection from one element to another is in a text source view by clearing the first selection and manually selecting the start and end point of the new element, then FAIL.
  5. Otherwise, select PASS.

A.3.4.2 Navigate by Programmatic Relationships:

If editing-views allow editing of programmatic relationships within web content, then mechanisms are provided that support navigation between the related content. (Level AAA)

  • Note: Depending on the web content technology and the nature of the authoring tool, relationships may include, but are not limited to, element nesting, headings, labeling, programmatic definitions, and ID relationships.

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Mechanisms are provided that support navigation between the related content

  1. If the web content technology(ies) being produced do not include any programmatic relationships (e.g. plain text editing, raster graphic editing) then select is SKIP
  2. If the tool is designed such that programmatic relationships (ID reference, data structure definition, function definition, etc.) are never exposed to the author, then select SKIP
  3. If the tool is designed such that programmatic relationships (ID reference, data structure definition, function definition, etc.) are never editable by the author, then select SKIP
  4. Check whether a mechanism exists that allows direct navigation of focus between at least one piece of web content (elements, functions, etc.) to another where there is a programmatic relationship (e.g. direct navigation to parent or children nodes in nested element structure, direct navigation to the heading for an element, direct navigation to the ID used in an ID reference, direct navigation to the definition for a data structure from an instance of use, direct navigation to the definition for a function definition from an instance of use, etc.), then select PASS
  5. Otherwise, select FAIL.
Guideline A.3.5: (For the authoring tool user interface) Provide text search of the content. Tests

A.3.5.1 Text Search:

If the authoring tool provides an editing-view of text-based content, then the editing-view enables text search, such that all of the following are true: (Level AA)

  • (a) All Editable Text: Any text content that is editable by the editing-view is searchable (including alternative content); and
  • (b) Match: Matching results can be presented to authors and given focus; and
  • (c) No Match: Authors are informed when no results are found; and
  • (d) Two-way: The search can be made forwards or backwards.

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: All editing-views enable text search where any text content that is editable by the editing-view is searchable, results can be made visible to authors and given focus, authors are informed when no results are found and search can be made forwards or backwards.

  1. If the authoring tool does not allow the editing of text content (e.g. because it is a graphics editor), then select SKIP.
  2. For each editing view that enables the editing of text content:
    1. Load the accessible test content file (any level), which contains non-text content with text alternatives, in the editing view.
    2. Choose a word that is repeated in the text and then determine whether a search function exists for the editing view that can find all of the instances of the word. In web-based tools, the search function may be part of the user agent. If this is not possible, then select FAIL.
    3. When a match is found, check whether the match can be presentwed and given focus in the editing view. If this is not done, then select FAIL
    4. Determine whether search is possible forwards and backwards. If it is not, then select FAIL
    5. Choose a search term that is not in the content (e.g. a nonsense word) and search for it. If no indication is made of the failure of the search, then select FAIL
    6. If the editing view enables editing of text alternatives for non-text content, choose a search term from within the text alternative. If the term cannot be found, then select FAIL.
    7. Go to the next editing view that enables the editing of text content (if any).
  3. Select PASS (all of the editing views must have passed)
Guideline A.3.6: (For the authoring tool user interface) Manage preference settings. Tests

A.3.6.1 Independence of Display:

If the authoring tool includes display settings for editing-views, then the authoring tool allows authors to adjust these settings without modifying the web content being edited. (Level A)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Authors can adjust display settings of editing views without affecting the display of the final content (test for tools that enable "save as").

  1. Determine (from the user interface or documentation) whether the authoring tool includes settings that affect how the content being edited is perceived by the author. If these settings exist, then document them. If not, then select SKIP.
  2. Determine whether the authoring tool has an efficient way to save multiple versions of content, such that they can be easily compared for differences. If not or if unsure, then select SKIP.
  3. Determine a "method for detecting differences between instances of web content" (e.g. W3C's HTML Diff service)
  4. Create/open web content with the authoring tool.
  5. Publish the web content.
  6. For each setting (or group of settings) that affects how the content being edited is perceived by the author:
    1. Change the setting(s) to a different value. Try to choose values that are as different as possible from the starting values, since this will make detecting differences easier.
    2. Publish the web content, being careful not to overwrite the earlier copy (e.g. by saving as a different file name).
    3. Use the "method for detecting differences between instances of web content". If the web content, has changed in substantive ways (e.g. not whitespace, not changes related to the later save time), then select FAIL.
    4. Go to the next setting (or group of settings) that affects how the content being edited is perceived by the author (if any).
  7. Select PASS (all of the settings must have passed)

Test 0002 Assertion: Authors can adjust display settings of editing views without affecting the display of the final content (test for tools that do not enable "save as")

  1. Determine (from the user interface or documentation) whether the authoring tool includes settings that affect how the content being edited is perceived by the author. If these settings exist, then document them. If not, then select SKIP.
  2. Determine whether the authoring tool has an efficient way to save multiple versions of content, such that they can be easily compared for differences. If so, then select SKIP.
  3. Create/open web content with the authoring tool.
  4. Publish the web content and open it in a user agent as an end-user would open it.
  5. For each setting (or group of settings) that affects how the content being edited is perceived by the author:
    1. Change the setting(s) to a different value (and note these values). Try to choose values that are as different as possible from the starting values, since this will make detecting differences easier.
    2. Publish the web content.
    3. Refresh the user agent view of the web content. Check for evidence that the new setting values have affected the content. If the web content has changed, then select FAIL.
    4. Go to the next setting (or group of settings) that affects how the content being edited is perceived by the author (if any).
  6. Select PASS (all of the settings must have passed)

A.3.6.2 Save Settings:

If the authoring tool includes display and/or control settings, then these settings can be saved between authoring sessions. (Level AA)

 

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Preferences for display or control settings can be saved between authoring sessions.

  1. Determine (from the user interface or documentation) whether the authoring tool includes settings that affect how the author tool's user interface or the content being edited is perceived by the author (not the end-user). If these settings do not exist, then select SKIP.
  2. For each method of changing display or control settings (e.g. "Edit Preferences" utility, "Zoom" setting in the menus, etc.). Note: It is not necessary to check every individual setting:
    1. Does the preference or preference group include a control to allow the settings to be saved? If so, go to the next method of changing display or control settings.
    2. Make change to a setting, then logout or end the authoring session. Then return back to the content being edited.
    3. If the setting change has persisted, go to the next method of changing display or control settings. If not, then select FAIL.
    4. Go to the next method of changing display or control settings (if any).
  3. Select PASS (all of the methods of changing display or control settings must have passed)

A.3.6.3 Apply Platform Settings:

The authoring tool respects changes in platform display and control settings, unless authors select more specific display and control settings using the authoring tool. (Level AA)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: If the user makes a change to the platform display or control settings, then those changes appear in the authoring tool. If the user makes a change to the platform display or control settings and that change does NOT appear in the authoring tool, then the authoring tool has more specific display and control settings inside the authoring tool.

  1. If the platform for the authoring tool does not allow changes to the platform display (e.g. high contrast mode, large fonts, volume, etc.) or control settings (e.g. keyboard, mouse preference changes), then select SKIP. (Note: It is rare that a platform does not allow any such customization)
  2. Launch the authoring tool and load the accessible test content file (any level). Record the state of the display (e.g. with a screenshot) and controls.
  3. Change the platform accessibility settings (e.g. to high contrast mode or another settings change) from the platform accessibility options. Record the change made.
  4. Return to the authoring tool and observe whether the change made in step 3 are reflected in the display or controls of the authoring tool. If yes, select PASS.
  5. If the change made to the display or control settings in step 3 are not apparent, then open the authoring tool's own preferences/settings. If the authoring tool's preferences/settings allow the same or more customization than was allowed by the platform (e.g. if the platform includes a single white-on-black high contrast mode, but the authoring tool provides several high contrast options), then select PASS.
  6. Otherwise, select FAIL.
Guideline A.3.7: (For the authoring tool user interface) Ensure that previews are at least as accessible as in-market user agents. Tests

A.3.7.1 Preview (Minimum):

If a preview is provided, then at least one of the following is true: (Level A)

  • (a) In-Market User Agent: The preview renders content using a user agent that is in-market; or
  • (b) UAAG (Level A): The preview conforms to the User Agent Accessibility Guidelines 1.0 Level A.

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Previews use either in-market user agents or conform to Level A of the User Agent Accessibility Guidelines 1.0.

  1. Determine from the user interface, online help, or documentation that the application provides a preview function. If no preview mode exists, then select SKIP.
    Note: A preview is non-editable view of how the content would appear to end users of user agents.
  2. If at least one of the preview options employs an in-market user agent, then select PASS.
    Note: A user agent, that can be procured by members of the public (free or otherwise). Usually, an in-market user agent will be a separate software from the authoring tool, however, sometimes a software may combine user agent and authoring tool functionality) (Note: if this is the case, the user agent need not meet UAAG in order to meet ATAG2)
  3. Create or open web content in the editing view.
  4. Invoke the preview function.
  5. If the preview function meets the User Agent Accessibility Test Procedure (Level A), then selectPASS
  6. Otherwise, select FAIL.

A.3.7.2 Preview (Enhanced):

If a preview is provided, then authors can specify which user agent performs the preview. (Level AAA)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Authors can choose from a set of in-market user agents for previews.

  1. Determine from the user interface, online help, or documentation that the application provides a preview function. If no preview mode exists, then select SKIP.
    Note: A preview is non-editable view of how the content would appear to end users of user agents.
  2. If authors can specify which user agent (of those installed on their system that can render the content technology in question) is to be used to perform the preview, then select PASS.
  3. Otherwise, select FAIL.
PRINCIPLE A.4: Editing-views are understandable Tests
Guideline A.4.1: (For the authoring tool user interface) Help authors avoid and correct mistakes. Tests

A.4.1.1 Content Changes Reversible (Minimum):

All authoring actions are either reversible or the authoring tool requires author confirmation to proceed. (Level A)

 

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: All authoring actions are either reversible or the authoring tool requires author confirmation to proceed.

  1. Open or author sample content (e.g. accessible test content file).
  2. Decide on a number of authoring actions (e.g. typing text, inserting an object, deleting text, deleting objects, etc.)
  3. For each authoring action:
    1. Perform the authoring action.
    2. If a confirmation was required to proceed, check whether the confirmation stated that the authoring action would be irreversible. If so, then go to the next authoring action.
    3. Attempt to reverse the authoring action (e.g. via mechanisms such as "Undo" or "Cancel"). For web-based tools, the user agent's undo function(s) may be utilized. If this is not possible, then select FAIL.
    4. Go to the next authoring action (if any).
  4. Select PASS. (all of the authoring actions must have met the requirement)

A.4.1.2 Settings Change Confirmation:

If the authoring tool provides mechanisms for changing authoring tool user interface settings, then those mechanisms can reverse the setting changes, or the authoring tool requires author confirmation to proceed. (Level A)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: User interface setting changes can be reversed, or require author confirmation to proceed.

  1. Examine the authoring tool (including in the documentation) for mechanisms to change any preference settings within that authoring tool user interface. If there are none, then selectSKIP.
  2. For each mechanism for changing the preference settings:
    1. Note "values" of preference settings within the mechanism.
    2. Use the mechanisms to change the relevant preference settings, so that the "value" of those preference settings is different.
    3. If an OK button (or similar) is required to save the preferences, select the button.
    4. If the authoring tool prompts the user for confirmation to proceed, then go to the next mechanism for changing the preference settings (if any).
    5. Attempt to "reverse" the change. If the original value can be set, then go to the next mechanism for changing the preference settings (if any).
    6. Otherwise, selectFAIL.
  3. Select PASS. (all of the settings must have met the requirement)

A.4.1.3 Content Changes Reversible (Enhanced):

Authors can sequentially reverse a series of reversible authoring actions. (Level AAA)

  • Note: It is acceptable to clear the authoring action history at the end of authoring sessions.

@@[Approved http://www.w3.org/2013/02/25-au-minutes.html]

Test 0001 Assertion: A sequence of authoring actions can be reversed sequentially.

  1. Open or author sample content (e.g. accessible test content file).
  2. Decide on a number of authoring actions (e.g. typing text, inserting an object, deleting text, deleting objects, etc.)
  3. Perform all of the authoring actions in sequence (do not save, close the session, etc.)
  4. Attempt to reverse the authoring actions (e.g. via mechanisms such as "Undo" or "Cancel") one by one. If this is possible, then select PASS. Otherwise, select FAIL.
Guideline A.4.2: (For the authoring tool user interface) Document the user interface including all accessibility features. Tests

A.4.2.1 Describe Accessibility Features:

For each authoring tool feature that is used to meet Part A of ATAG 2.0, at least one of the following is true: (Level A)

  • (a) Described in the Documentation: Use of the feature is explained in the authoring tool's documentation; or
  • (b) Described in the Interface: Use of the feature is explained in the authoring tool user interface; or
  • (c) Platform Service: The feature is a service provided by an underlying platform; or
  • (d) Not Used by Authors: The feature is not used directly by authors (e.g. passing information to a platform accessibility service).
  • Note: The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2.

@@[Approved http://www.w3.org/2013/02/25-au-minutes.html]

Test 0001 Assertion: Accessibility features are either described, part of the platform, or not used directly by authors.

  1. Examine the user interface of the authoring tool, noting each user interface component that is necessary in order to meet part A of ATAG 2.0 (e.g. search functions).
    Note: Many of the success criteria in Part A are more qualitative and will not require particular user interface functionality (e.g. the requirement to follow WCAG 2.0). (Components are checked because they are the constituents of features)
  2. For each of these user interface components:
    1. If the user interface component is part of functionality provided by the platform (e.g. the menu bar of the browser in the case of a web-based tool), then go to the next component.
    2. If use of the user interface component is a convention of the platform (e.g. how to operate scroll-bars, standard Save and Open dialog boxes), then go to the next component.
    3. If use of the user interface component is clear from its context (e.g. a page zoom feature with percentage values in a drop-down list), then go to the next component.
    4. If the user interface component is documented in the interface (e.g. with text next to the item, context-sensitive help), then go to the next component.
    5. Look up the user interface component (or its associated functionality) in the documentation. If documentation exists, then go to the next component.
    6. If there is no way to discover how to use the user interface component besides trial-and-error, then select FAIL.
    7. Go to the next user interface component (if any).
  3. Select PASS (all of the user interface components must meet the requirements)

A.4.2.2 Document All Features:

For each authoring tool feature, at least one of the following is true: (Level AA)

  • (a) Described in the Documentation: Use of the feature is explained in the authoring tool's documentation; or
  • (b) Described in the Interface: Use of the feature is explained in the authoring tool user interface; or
  • (c) Platform Service: The feature is a service provided by an underlying platform; or
  • (d) Not Used by Authors: The feature is not used directly by authors (e.g. passing information to a platform accessibility service).
  • Note: The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2.

@@[Approved http://www.w3.org/2013/02/25-au-minutes.html]

Test 0001 Assertion: All features are either described, part of the platform, or not used directly by authors.

  1. Examine the user interface of the authoring tool, noting each user interface component that accepts input and is available to the author. (Components are checked because they are the constituents of features)
  2. For each of these user interface components:
    1. If the user interface component is part of functionality provided by the platform (e.g. the menu bar of the browser in the case of a web-based tool), then go to the next component.
    2. If use of the user interface component is a convention of the platform (e.g. how to operate scroll-bars, standard Save and Open dialog boxes), then go to the next component.
    3. If use of the user interface component is clear from its context (e.g. a page zoom feature with percentage values in a drop-down list), then go to the next component.
    4. If the user interface component is documented in the interface (e.g. with text next to the item, context-sensitive help), then go to the next component.
    5. Look up the user interface component (or its associated functionality) in the documentation. If documentation exists, then go to the next component.
    6. If there is no way to discover how to use the user interface component besides trial-and-error then, select FAIL.
    7. Go to the next user interface component (if any).
  3. Select PASS (all of the user interface components must meet the requirements)
PART B: Support the production of accessible content Tests
PRINCIPLE B.1: Fully automatic processes produce accessible content Tests
Guideline B.1.1: Ensure automatically-specified content is accessible. Tests

B.1.1.1 Content Auto-Generation After Authoring Sessions (WCAG):

The authoring tool does not automatically generate web content after the end of an authoring session or authors can specify that the content be accessible web content (WCAG). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

  • Note: This success criterion applies only to automatic processes specified by the authoring tool developer. It does not apply when author actions prevent generation of accessible web content (WCAG).

@@[Approved http://www.w3.org/2013/02/25-au-minutes.html]

Test 0001 Assertion: If the authoring tool provides the functionality for automatically generating web content after the end of an authoring session, authors can specify that the content be accessible.

  1. If the authoring tool does not add any content after the authoring session ends (e.g. the author closes a file, logs out, etc.), then select PASS.
  2. The SC's note makes it clear that the SC refers to developer-provided processes, not processes created by the author or other third-parties. If there are no relevant developer-provided process, then select SKIP.
  3. If the auto-generation system primarily works by creating a wrapper around the author's entries, try to test the auto-generation system with as little author-entered content as possible.
  4. If author input is required, ensure that only accessible content is added and that all prompts are followed correctly.
  5. If the auto-generation system acts differently depending on the author's entries, try to test the auto-generation system with the "accessible test content file"
  6. If additional author input is required, ensure that only accessible content is added and that all prompts are followed correctly.
  7. Once the system produces output, follow the Web Content Accessibility Test Procedure (TARGET_LEVEL) to determine if it meets the WCAG 2.0 success criteria TARGET_LEVEL. If the produced output meets WCAG 2.0 at the TARGET_LEVEL, select PASS. Otherwise select FAIL.

B.1.1.2 Content Auto-Generation During Authoring Sessions (WCAG):

If the authoring tool provides the functionality for automatically generating web content during an authoring session, then at least one of the following is true: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
  • (a) Accessible: The content is accessible web content (WCAG) without author input; or
  • (b) Prompting: During the automatic generation process, authors are prompted for any required accessibility information (WCAG); or
  • (c) Automatic Checking: After the automatic generation process, accessibility checking is automatically performed; or
  • (d) Checking Suggested: After the automatic generation process, the authoring tool prompts authors to perform accessibility checking.
  • Note 1: Automatic generation includes automatically selecting templates for authors.
  • Note 2: This success criterion applies only to automatic processes specified by the authoring tool developer. It does not apply when author actions prevent generation of accessible web content (WCAG).

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Content generated automatically during authoring sessions is either accessible or the user is prompted or checking is enabled automatically or checking is suggested.

  1. Determine whether the authoring tools automatically adds content during the authoring session. Such processes can range from complex (e.g. a process that builds a whole page from just a few user entries - Note 1 applies here) to basic (e.g. adding a <strong> formatting tag when the user has selected to have text made "bold"). If the authoring tool does not automatically generate content, select SKIP.
  2. For each automatic authoring process:
    1. Trigger the automatic authoring process with as little author-entered content as possible (e.g. triggering the automated processes on nearly empty pages).
    2. If the produced content (not necessarily the document as a whole) passes the "Web Content Accessibility Test Procedure (TARGET_LEVEL)", then go to the next automatic authoring process.
    3. If, during the automatic authoring process, authors are prompted for any required accessibility information (WCAG) and if this is properly supplied then the produced content passes the "Web Content Accessibility Test Procedure (TARGET_LEVEL)", then go to the next automatic authoring process.
    4. If, after the automatic generation process, accessibility checking is automatically performed (check-as-you-type systems that check for accessibility continuously will meet this), then go to the next automatic authoring process.
    5. If, after the automatic generation process, the authoring tool prompts authors to perform accessibility checking (such prompts need not be obtrusive), then go to the next automatic authoring process.
    6. Otherwise, select FAIL.
  3. Select PASS (all of the automatic authoring processes must meet the requirements)
Guideline B.1.2: Ensure accessibility information is preserved. Tests

B.1.2.1 Restructuring and Recoding Transformations (WCAG):

If the authoring tool provides restructuring transformations or re-coding transformations, and if equivalent mechanisms exist in the web content technology of the output, then at least one of the following is true: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

  • (a) Preserve: Accessibility information (WCAG) is preserved in the output; or
  • (b) Warning: Authors have the default option to be warned that accessibility information (WCAG) may be lost (e.g. when saving a vector graphic into a raster image format); or
  • (c) Automatic Checking: After the transformation, accessibility checking is automatically performed; or
  • (d) Checking Suggested: After the transformation, the authoring tool prompts authors to perform accessibility checking.
  • Note 1: For text alternatives for non-text content, see Success Criterion B.1.2.4.
  • Note 2: This success criteria only applies when the output technology is "included" for conformance.

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Restructuring transformations either preserve accessibility information or the user is prompted or checking is enabled automatically or checking is suggested.

  1. Determine which are the "included" technologies.
  2. Determine if (for these "included" technologies only) the authoring tool provides any features that involve restructuring transformation (in which the content technology stays the same, but the structural features of the technology used to markup the content are changed (e.g. linearizing tables, splitting a document into pages)) that meet the following conditions:
    • must be automatic processes (e.g. a general find-and-replace mechanism does not qualify),
    • clipboard actions (such as copy and paste), are excluded because they are addressed by B.1.2.2.
    • transformations related to text alternatives for non-text content are excluded because they are addressed by B.1.2.4.
  3. If no transformations that meet these conditions are identified, then select SKIP.
  4. For each restructuring transformation:
    1. Open the accessible test content file (TARGET_LEVEL)
    2. Invoke the transformation.
    3. If the resulting content (when published) meets the "Web Content Accessibility Test Procedure (TARGET_LEVEL)", then go to the next restructuring transformation.
    4. If before the transformation proceeds, the author is warned that accessibility information may be lost, then go to the next restructuring transformation.
    5. If, after the transformation, accessibility checking is automatically performed (check-as-you-type systems that check for accessibility continuously will meet this), then go to the next restructuring transformation.
    6. If, after the transformation, the authoring tool prompts authors to perform accessibility checking (such prompts need not be obtrusive), then go to the next restructuring transformation.
    7. Otherwise, select FAIL.
  5. Select PASS (all of the relevant restructuring transformations must meet the requirements)

Test 0002 Assertion: Recoding transformations either preserve accessibility information or the user is prompted or checking is enabled automatically or checking is suggested.

  1. Determine which are the "included" technologies.
  2. Determine if the authoring tool provides any features that involve recoding transformations (Transformations in which the content technology used to encode the content is changed (e.g. HTML4 to XHTML, a word processing format to HTML4)) that meet the following conditions:
    • where the output is an "included" technology
    • must be automatic processes,
    • clipboard actions (such as copy and paste), are excluded because they are addressed by B.1.2.2.
    • transformations related to text alternatives for non-text content are excluded because they are addressed by B.1.2.4.
  3. If no transformations that meet these conditions are identified, then select SKIP.
  4. For each recoding transformation:
    1. Open the accessible test content file (TARGET_LEVEL)
    2. Invoke the transformation.
    3. If the resulting content (when published) meets the "Web Content Accessibility Test Procedure (TARGET_LEVEL)", then go to the next recoding transformation.
    4. If before the transformation proceeds, the author is warned that accessibility information may be lost, then go to the next recoding transformation.
    5. If, after the transformation, accessibility checking is automatically performed (check-as-you-type systems that check for accessibility continuously will meet this), then go to the next recoding transformation.
    6. If, after the transformation, the authoring tool prompts authors to perform accessibility checking (such prompts need not be obtrusive), then go to the next recoding transformation.
    7. Otherwise, select FAIL.
  5. Select PASS (all of the relevant restructuring transformations must meet the requirements)

B.1.2.2 Copy-Paste Inside Authoring Tool (WCAG):

If the authoring tool supports copy and paste of structured content, then any accessibility information (WCAG) in the copied content is preserved when the authoring tool is both the source and destination of the copy-paste and the source and destination use the same web content technology. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Accessibility information in the copied content is preserved when the same authoring tool editing view is both the source and destination of the copy-paste.

  1. If the authoring tool does not support copy-paste of structured content, then select SKIP.
  2. Open accessible test content file (TARGET_LEVEL).
  3. Copy as much of the content as possible and paste it back into the same editing view.
  4. Once the system produces output, compare it to the accessible test content file (TARGET_LEVEL). If it is identical or if the differences only affect whitespace, then select PASS.
  5. Follow the Web Content Accessibility Test Procedure to determine whether the output meets the WCAG 2.0 success criteria TARGET_LEVEL. If it does, then select PASS. Otherwise, select FAIL.

B.1.2.3 Optimizations Preserve Accessibility:

If the authoring tool provides optimizing web content transformations, then any accessibility information (WCAG) in the input is preserved in the output. (Level A).

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Optimizing web content transformations preserve accessibility information.

  1. If the authoring tool does not include any optimizations (e.g. "pretty print"), then select SKIP.
  2. For each type of optimization:
    1. Open accessible test content file
    2. Once the system produces output, compare it to the accessible test content file. If it is identical or if the differences only affect whitespace, then go to the next type of optimization.
    3. Otherwise, follow the Web Content Accessibility Test Procedure to determine if it meets the WCAG 2.0 success criteria TARGET_LEVEL. If it does not, select FAIL.
    4. Go to the next type of optimization (if any).
  3. Select PASS (all of the optimizations must have preserved accessibility information)

B.1.2.4 Text Alternatives for Non-Text Content are Preserved:

If the authoring tool provides web content transformations that preserve non-text content in the output, then any text alternatives for that non-text content are also preserved, if equivalent mechanisms exist in the web content technology of the output. (Level A).

  • Note: This success criterion only applies when the output technology is "included" for conformance.

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: If the authoring tool provides web content transformations that preserve non-text content in the output, then any text alternatives for that non-text content are also preserved, if equivalent mechanisms exist in the web content technology of the output.

  1. Determine which are the "included" technologies. If there is only one technology or set of inter-twined technologies (e.g. HTML4.01 with JavaScript and images), then select SKIP.
  2. Determine if the authoring tool provides any transformations between any of the "included" technologies (e.g. HTML4.01 to HTML5). If there are no such transformations, then select SKIP.
  3. For each included technology:
    1. Open accessible test content file (for that content technology)
    2. For each transformation from that included technology to another included technology:
      1. Proceed to transform the content into that other included technology.
      2. Once the system produces output, follow the Web Content Accessibility Test Procedure (Level A) for the non-text content only. If it is the case that any of the non-text content (e.g. images) are maintained across the transformation, but without the associated text alternatives, then select FAIL.
      3. Go to the next transformation to another included technology (if any).
    3. Go to the next "included" technology (if any).
  4. Select PASS (all of the transformations between "included" technologies that preserve non-text content must also have preserved their text alternatives)
PRINCIPLE B.2: Authors are supported in producing accessible content Tests
Guideline B.2.1: Ensure that accessible content production is possible. Tests

B.2.1.1 Accessible Content Possible (WCAG):

The authoring tool does not place restrictions on the web content that authors can specify or those restrictions do not prevent WCAG 2.0 success criteria from being met. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Any restrictions on the web content that authors can edit do not prevent the web content from conforming to WCAG.

  1. If the authoring tool does not place any restrictions on the web content that users can edit, then select PASS.
  2. Create some content using the following two rules:
    • Correctly follows any instructions provided (e.g. correctly responding to prompts, correctly replacing highlighted placeholders); and
    • Do no more authoring than requested by the instructions
  3. Once the system produces output, follow the Web Content Accessibility Test Procedure (TARGET_LEVEL) to determine if it meets the WCAG 2.0 success criteria TARGET_LEVEL.
  4. If any of the content fails a WCAG 2.0 success criteria at the target level, then select FAIL. (a range of WCAG-conformant web content must not have been found)
  5. Select PASS (accessible content must at least be possible)
Guideline B.2.2: Guide authors to produce accessible content. Tests

B.2.2.1 Accessible Option Prominence (WCAG):

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 accessible web content (WCAG) are at least as prominent as options that will not. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: The authoring tool interface first presents authors with the most accessible options when provided with several choices for achieving a desired result.

  1. Examine the user interface, online help, or documentation for any options that would necessarily result in the production of inaccessible content even if the author:
    • Correctly follows any instructions provided (e.g. correctly responding to prompts, correctly replacing highlighted placeholders); and
    • Does no more authoring than requested by the instructions
  2. If no options necessarily resulting in inaccessible content are found, then select SKIP.
  3. For each option resulting in inaccessible content:
    1. Examine the user interface, online help, or documentation for the existence of an accessible alternative to the inaccessible option. If none exist, then go to the next option resulting in inaccessible content.
    2. If at least one accessible alternative exists, determine the minimum number of "opening actions" required to arrive at an accessible alternative. "Opening actions" are actions made by authors on components within the user interface that result in new components becoming displayed or enabled. (e.g. keyboard shortcut to a top-level menu item to display a sub-menu, keyboard selection on a button to display a dialog box, mouse click on a checkbox to enable previously disabled sub-items, etc. Actions that do not cause new components to become actionable (e.g. moving focus, scrolling a list), are not counted as "opening actions".)
    3. If the inaccessible option is arrived at via fewer opening actions than the accessible alternative, then select FAIL.
    4. Go to the next option resulting in inaccessible content (if any).
  4. Select PASS (all of options leading to inaccessible content must be of lower prominence as measured by "opening actions")

B.2.2.2 Setting Accessibility Properties (WCAG):

If the authoring tool provides mechanisms to set web content properties (e.g. attribute values), then mechanisms are also provided to set web content properties related to accessibility information (WCAG). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

  • Note: For the prominence of the mechanisms, see Success Criterion B.4.1.4.

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: The authoring tool provides access to content properties related to accessibility information.

  1. Examine the user interface, online help, or documentation for mechanisms that allow the author to set of modify content properties (e.g. HTML4 element attribute values). If this is not the case (e.g. tools that give authors very little low-level control), then select SKIP.
  2. Check whether mechanisms also exist for establishing or modifying accessibility properties (since different properties of the same object may be set in different places, be prepared to search).
  3. If there are no mechanisms for establishing or modifying accessibility properties, then select FAIL.
  4. If there is a mechanism for establishing content properties is available through the user interface (e.g. a dialog box) but users must modify accessibility settings externally (e.g. by editing an ini file or external preferences file), then select FAIL.
  5. Select PASS.
Guideline B.2.3: Assist authors with managing alternative content for non-text content. Tests

B.2.3.1 Alternative Content is Editable (WCAG):

If the authoring tool provides functionality for adding non-text content, then authors are able to modify programmatically associated text alternatives for non-text content. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: : Authors are able to modify programmatically associated text alternatives for non-text content.

  1. Identify, to yourself, the parts of the accessible test content file that are considered programmatically associated text alternatives for non-text content (e.g. alt-text, long descriptions, etc.; captions are not included).
  2. Open the accessible test content file with the authoring tool (if no open/import is provided, it may need to be pasted).
  3. If none of the types of programmatically associated text alternatives for non-text content can be opened with or inserted by the authoring tool, then select SKIP.
  4. For each type of programmatically associated text alternatives for non-text content:
    1. Attempt to modify the alternative content. If this is not possible, then select FAIL.
    2. Go to the next type of programmatically associated text alternatives for non-text content (if any).
  5. Select PASS (all of types of alternative content could be edited)

B.2.3.2 Automating Repair of Text Alternatives:

The authoring tool does not attempt to repair text alternatives for non-text content or the following are all true: (Level A)

  • (a) No Generic or Irrelevant Strings:Generic strings (e.g. "image") and irrelevant strings (e.g. the file name, file format) are not used as text alternatives; and
  • (b) In-Session Repairs: If the repair attempt occurs during an authoring session, authors have the opportunity to accept, modify, or reject the repair attempt prior to insertion of the text alternative into the content; and
  • (c) Out-of-Session Repairs: If the repair attempt occurs after an authoring session has ended, the repaired text alternatives are indicated during subsequent authoring sessions (if any) and authors have the opportunity to accept, modify, or reject the repair strings prior to insertion in the content.

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Any in-session repair attempts for text alternatives for non-text content made by the authoring during an authoring session do not use generic strings and irrelevant strings and allow for author control.

  1. Determine whether the authoring tool ever automatically (the tool acting alone) or semi-automatically (the tool prompting the author for some input) inserts text alternatives for non-text content while an authoring session is open.
    1. An example of automatic repair: when the author inserts an image, the tool automatically sets the alt attribute to alt="" without informing the author.
    2. An example of semi-automatic repair: when the author inserts an image they are shown an "Inset Image" dialog. The dialog includes an "alt" field that has been pre-filled with the filename of the image.
  2. If no automatic or semi-automatic repairs are attempted, then select PASS.
  3. For each repair:
    1. If the repair includes a generic string that is specific to the image (e.g. "image", "picture", "graphic", "", " ", etc.), then select FAIL.
    2. If the repair includes text that is somewhat specific to the image, but is irrelevant to its description (e.g. "pic123.png", "PNG image", "200px by 300px", etc.), then select FAIL.
    3. If the authoring tool does not give you an opportunity to accept, modify or reject strings before they are used, then select FAIL. (In other words, purely automatic repairs with no opportunity for author acceptance are not permitted)
    4. Go to the next repair (if any).
  4. Select PASS (all of repairs passed the requirements)

Test 0002 Assertion: Any automatic or semi-automatic repair attempts for text alternatives for non-text content ("repair strings") made after authoring sessions do not use generic strings and irrelevant strings and authors have the opportunity to control them in the next session.

  1. Determine whether the authoring tool ever automatically inserts text alternatives for non-text content (e.g. a CMS displaying alt="" for images that the author has not specified an alt value for, descriptions of photographs created using geo-tagging metadata).
  2. If no automatic repairs are attempted, then select PASS.
  3. For each repair:
    1. If the repair includes a generic string that is specific to the image (e.g. "image", "picture", "graphic", "", " ", etc.), then select FAIL.
    2. If the repair includes text that is somewhat specific to the image, but is irrelevant to its description (e.g. "pic123.png", "PNG image", "200px by 300px", etc.), then select FAIL.
    3. Attempt to go back in and edit the content. If images with automatically generated text alternatives are not highlighted in some way then, then select FAIL.
    4. If the authoring tool does not give you an opportunity to accept, modify or reject the string, then select FAIL.
    5. Go to the next repair (if any).
  4. Select PASS (all of repairs passed the requirements)

B.2.3.3 Save for Reuse:

 

If the authoring tool provides the functionality for adding non-text content,

when authors enter programmatically associated text alternatives for non-text content, then both of the following are true: (Level AAA)
  • (a) Save and Suggest: The text alternatives are automatically saved and suggested by the authoring tool, if the same non-text content is reused; and
  • (b) Edit Option: The author has the option to edit or delete the saved text alternatives.

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: When authors enter programmatically associated text alternatives for non-text content, then the text alternatives are automatically saved and suggested by the authoring tool, if the same non-text content is reused, and the author has the option to edit or delete the saved text alternatives.

  1. Identify programmatically associated text alternatives that are candidates for being saved by the authoring tool (e.g. alt text for images, long descriptions for images, etc.; captions are not included).
  2. If the authoring tool does not provide any functionality for adding non-text content, then select SKIP.
  3. If the authoring tool does not provide any functionality for adding text alternatives for non-text content, then select SKIP.
  4. For each type of text alternatives for non-text content:
    1. Insert the relevant type of non-text content and a text alternative test string. Save, if relevant.
    2. Insert the same non-text content object again.
    3. If the the previously entered text alternative is not somehow suggested as a possible text alternative for the new instance, then select FAIL.
    4. Determine whether is is possible to edit and/or delete these saved text entries (e.g. in case of a spelling error). This functionality may be available when the text alternative is suggested or the text alternatives may be managed elsewhere in the authoring tool user interface. If not, then then select FAIL.
  5. Select PASS (all of types of alternatives for non-text content passed the requirements)
Guideline B.2.4: Assist authors with accessible templates. Tests

B.2.4.1 Accessible Template Options (WCAG):

If the authoring tool provides templates, then there are accessible template (WCAG) options for a range of template uses. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: There are accessible template (WCAG) options for a range of template uses

  1. Examine the authoring tool interface (and documentation, etc.) to determine if and how tempates are used.
  2. If the authoring tool does not provide templates (i.e. content patterns that are filled in by authors or the authoring tool to produce content for end users), then select SKIP.
  3. If only blank document templates (resulting in empty documents if not filled in) are provided, then select PASS.
  4. For each template:
    1. Create some content using the template following these two rules:
      1. Correctly follows any instructions provided (e.g. correctly responding to prompts, correctly replacing highlighted placeholders); and
      2. Do no more authoring than requested by the instructions
    2. Once the system produces output, follow the Web Content Accessibility Test Procedure to determine if it meets the WCAG 2.0 success criteria TARGET_LEVEL.
    3. Once two templates are found that meet WCAG 2.0 (or one, if there is only one template), select PASS.
    4. Go to the next template.
  5. Select FAIL. (a range of templates must not have been found)

B.2.4.2 Identify Template Accessibility:

If the authoring tool includes a template selection mechanism and provides any non-accessible template (WCAG) options, then the template selection mechanism can display distinctions between the accessible and non-accessible options. (Level AA)

  • Note: The distinction can involve providing information for the accessible templates, the non-accessible templates or both.

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Template selection mechanisms can display distinctions between the accessible and non-accessible options.

  1. Examine the authoring tool interface (and documentation, etc.) to determine if and how tempates are used.
  2. If the authoring tool does not provide templates (Content patterns that are filled in by authors or the authoring tool to produce content for end users ), then select SKIP.
  3. If the authoring tool only provides templates that meet WCAG 2.0 (according to B.2.4.1), then select SKIP.
  4. If the authoring tool only provides templates that do not meet WCAG 2.0 (according to B.2.4.1), then select SKIP.
  5. If the authoring tool only provides a standard file selection mechanism for selecting templates, then select SKIP.
  6. For each template selection mechanism:
    1. Identify one template that is accessible and one template that is not.
    2. Observe how the two templates are displayed in the template selection mechanism. If there is no distinction between how they are displayed that could help the author to understand that one is accessible and the other not, then select FAIL.
    3. Go to the next template selection mechanism (if any).
  7. Select PASS (all of the template selection mechanisms must indicated the distinction)

B.2.4.3 Author-Created Templates:

If the authoring tool includes a template selection mechanism and allows authors to create new non-accessible templates (WCAG), then authors can enable the template selection mechanism to display distinctions between accessible and non-accessible templates that they create. (Level AA)

  • Note: The distinction can involve providing information for the accessible templates (WCAG), the non-accessible templates or both.

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: authors can enable the template selection mechanism to display distinctions between accessible and non-accessible templates that they create.

  1. Examine the authoring tool interface (and documentation, etc.) to determine if and how authors can create new templates.
  2. If the authoring tool does not provide templates (Content patterns that are filled in by authors or the authoring tool to produce content for end users ), then select SKIP.
  3. If the authoring tool only provides a standard file selection mechanism for selecting templates, then select SKIP.
  4. For each template selection mechanism:
    1. If the authoring tool does not allow authors to create templates (Content patterns that are filled in by authors or the authoring tool to produce content for end users ) for that selection mechanism, then select SKIP.
    2. Using as little content as possible, attempt to create a non-accessible template (e.g. by adding an image with no alternative text content). If this is possible, follow any instructions provided. If it is not possible to create a non-accessible template then select SKIP.
    3. Using as little content as possible, attempt to create an accessible template. If this is possible, follow any instructions provided. If it is not possible to create a accessible template then select FAIL.
    4. Compare how the two templates you created are displayed in the template selection mechanism. If there is no distinction between how they are displayed that could help the author to understand that one is accessible and the other not, then select FAIL.
    5. Go to the next template selection mechanism (if any).
  5. Select PASS (all of the template selection mechanisms must indicated the distinction)

B.2.4.4 Accessible Template Options (Enhanced):

If the authoring tool provides templates, then all of the templates are accessible template (to WCAG Level AA). (Level AAA)

Test 0001 Assertion: All templates are accessible (WCAG Level AA)

  1. Examine the authoring tool interface (and documentation, etc.) to determine if and how tempates are used.
  2. If the authoring tool does not provide templates (i.e. content patterns that are filled in by authors or the authoring tool to produce content for end users), then select SKIP.
  3. If only blank document templates (resulting in empty documents if not filled in) are provided, then select PASS.
  4. For each template:
    1. Create some content using the template following these two rules:
      1. Correctly follows any instructions provided (e.g. correctly responding to prompts, correctly replacing highlighted placeholders); and
      2. Do no more authoring than requested by the instructions.
    2. Once the system produces output, follow the Web Content Accessibility Test Procedure to determine if it meets the WCAG 2.0 success criteria to Level AA. If not, then select FAIL.
    3. Go to the next template (if any).
  5. Select PASS. (all of the templates must have met WCAG 2.0 Level AA when used)
Guideline B.2.5: Assist authors with accessible pre-authored content. Tests

B.2.5.1 Accessible Pre-Authored Content Options:

If the authoring tool provides pre-authored content, then a range of accessible pre-authored content (to WCAG Level AA) options are provided. (Level AA)

Test 0001 Assertion: There are a range of accessible (WCAG Level AA) pre-authored content options.
  1. Examine the authoring tool interface (and documentation, etc.) to determine if and how pre-authored content is used.
  2. If the authoring tool does not provide pre-authored content (i.e. clip art, widget palettes, etc.), then select SKIP.
  3. For each piece of pre-authored content:
    1. Make use of the pre-authored following these three rules:
      1. Insert the pre-authored content into the simplist container possible (e.g. a blank document)
      2. Correctly follows any instructions provided; and
      3. Do no more authoring than requested by the instructions.
    2. Once the system produces output, follow the Web Content Accessibility Test Procedure to determine if it meets the WCAG 2.0 success criteria to Level AA.
    3. Once two templates are found that meet WCAG 2.0 Level AA (or one, if there is only one piece of pre-authored content), select PASS.
    4. Go to the next piece of pre-authored content.
  4. Select FAIL. (a range of pre-authored content must not have been found)

B.2.5.2 Identify Pre-Authored Content Accessibility:

If the authoring tool includes a pre-authored content selection mechanism and provides any non-accessible pre-authored content (WCAG Level AA) options, then the selection mechanism can display distinctions between the accessible and non-accessible options (Level AA)

  • Note: The distinction can involve providing information for the accessible pre-authored content, the non-accessible pre-authored content or both.

Test 0001 Assertion: Pre-authored content selection mechanisms can display distinctions between the accessible and non-accessible options.

  1. Examine the authoring tool interface (and documentation, etc.) to determine if and how pre-authored content is used.
  2. If the authoring tool does not provide pre-authored content (i.e. clip art, widget palettes, etc.), then select SKIP.
  3. If the authoring tool only provides pre-authored content that meet WCAG 2.0 (according to B.2.5.1), then select SKIP.
  4. If the authoring tool only provides pre-authored content that do not meet WCAG 2.0 (according to B.2.5.1), then select SKIP.
  5. If the authoring tool only provides a standard file selection mechanism for selecting pre-authored content, then select SKIP.
  6. For each pre-authored content selection mechanism:
    1. Identify one piece of pre-authored content that is accessible and one piece that is not.
    2. Observe how the two pieces of pre-authored content are displayed in the selection mechanism. If there is no distinction between how they are displayed that could help the author to understand that one is accessible and the other not, then select FAIL.
    3. Go to the next pre-authored content selection mechanism (if any).
  7. Select PASS (all of the pre-authored content selection mechanisms must indicated the distinction)
PRINCIPLE B.3: Authors are supported in improving the accessibility of existing content Tests
Guideline B.3.1: Assist authors in checking for accessibility problems. Tests

B.3.1.1 Checking Assistance (WCAG):

If the authoring tool provides authors with the ability to add or modify web content in such a way that a WCAG 2.0 success criterion can be violated, then accessibility checking for that success criterion 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). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

  • Note: Automated and semi-automated checking is possible (and encouraged) for many types of web content accessibility problems (WCAG). 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.

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Checking assistance (WCAG Level A) is present in less-restrictive authoring tools.

  1. Determine whether the authoring tool allows authors to open/paste-in pre-existing content (i.e. non-accessible test content file (Level A)). If this is not possible, then select SKIP.
  2. Search the user interface (and documentation) for accessibility checking functionality (which can be automated, semi-automated, manual instructions or a combination). If checking functionality is not present, then select FAIL.
  3. Run the checker (if the checker is manual, this will entail following ALL checking instructions). If the checker provides detail about individual errors then you can open/paste-in all of the non-accessible test content file (Level A) at once. If the checker provides only aggregate results, open/paste-in the non-accessible test content file (Level A) one piece at a time.
  4. If the checker is able to cause all of the accessibility problems to be detected (automatically, semi-automatically, manually or a combination), then select PASS. Otherwise, select FAIL.

Test 0002 Assertion: Checking assistance (WCAG Level AA) is present in less-restrictive authoring tools. (Note: Only shown if the user has specified AA or AAA as the target level)

  1. Determine whether the authoring tool allows authors to open/paste-in pre-existing content (i.e. non-accessible test content file (Level AA)). If this is not possible, then select SKIP.
  2. Search the user interface (and documentation) for accessibility checking functionality (which can be automated, semi-automated, manual instructions or a combination). If checking functionality is not present, then select FAIL.
  3. Run the checker (if the checker is manual, this will entail following ALL checking instructions). If the checker provides detail about individual errors then you can open/paste-in all of the non-accessible test content file (Level AA) at once. If the checker provides only aggregate results, open/paste-in the non-accessible test content file (Level AA) one piece at a time.
  4. If the checker is able to cause all of the accessibility problems to be detected (automatically, semi-automatically, manually or a combination), then select PASS. Otherwise, select FAIL.

Test 0003 Assertion: Checking assistance (WCAG Level AAA) is present in less-restrictive authoring tools. (Note: Only shown if the user has specified AAA as the target level)

  1. Determine whether the authoring tool allows authors to open/paste-in pre-existing content (i.e. non-accessible test content file (Level AAA)). If this is not possible, then select SKIP.
  2. Search the user interface (and documentation) for accessibility checking functionality (which can be automated, semi-automated, manual instructions or a combination). If checking functionality is not present, then select FAIL.
  3. Run the checker (if the checker is manual, this will entail following ALL checking instructions). If the checker provides detail about individual errors then you can open/paste-in all of the non-accessible test content file (Level AAA) at once. If the checker provides only aggregate results, open/paste-in the non-accessible test content file (Level AAA) one piece at a time.
  4. If the checker is able to cause all of the accessibility problems to be detected (automatically, semi-automatically, manually or a combination), then select PASS. Otherwise, select FAIL.

Test 0004 Assertion: Checking assistance (WCAG Level A) is present in more-restrictive authoring tools.

  1. If the authoring tool allows allow authors to open/paste-in pre-existing content, select SKIP.
  2. Using non-accessible test content file (Level A) as a guide, attempt to create accessibility problems using the authoring tool. If this is not possible due to authoring restrictions (such as highly limited editing scope or compulsory fields), then select SKIP.
  3. If accessibility problems have been added to the content, search the user interface (and documentation) for accessibility checking functionality (which can be automated, semi-automated, manual instructions or a combination). If checking functionality is not present, then select FAIL.
  4. Run the checker (if the checker is manual, this will entail following ALL checking instructions).
  5. If the checker is able to cause all of the accessibility problems to be detected (automatically, semi-automatically, manually or a combination), then select PASS. Otherwise, select FAIL.

Test 0005 Assertion: Checking assistance (WCAG Level AA) is present in more-restrictive authoring tools. (Note: Only shown if the user has specified AA or AAA as the target level)

  1. If the authoring tool allows allow authors to open/paste-in pre-existing content, select SKIP.
  2. Using non-accessible test content file (Level AA) as a guide, attempt to create accessibility problems using the authoring tool. If this is not possible due to authoring restrictions (such as highly limited editing scope or compulsory fields), then select SKIP.
  3. If accessibility problems have been added to the content, search the user interface (and documentation) for accessibility checking functionality (which can be automated, semi-automated, manual instructions or a combination). If checking functionality is not present, then select FAIL.
  4. Run the checker (if the checker is manual, this will entail following ALL checking instructions).
  5. If the checker is able to cause all of the accessibility problems to be detected (automatically, semi-automatically, manually or a combination), then select PASS. Otherwise, select FAIL.

Test 0006 Assertion: Checking assistance (WCAG Level AAA) is present in more-restrictive authoring tools. (Note: Only shown if the user has specified AAA as the target level)

  1. If the authoring tool allows allow authors to open/paste-in pre-existing content, select SKIP.
  2. Using non-accessible test content file (Level AAA) as a guide, attempt to create accessibility problems using the authoring tool. If this is not possible due to authoring restrictions (such as highly limited editing scope or compulsory fields), then select SKIP.
  3. If accessibility problems have been added to the content, search the user interface (and documentation) for accessibility checking functionality (which can be automated, semi-automated, manual instructions or a combination). If checking functionality is not present, then select FAIL.
  4. Run the checker (if the checker is manual, this will entail following ALL checking instructions).
  5. If the checker is able to cause all of the accessibility problems to be detected (automatically, semi-automatically, manually or a combination), then select PASS. Otherwise, select FAIL.

B.3.1.2 Help Authors Decide:

If the authoring tool provides accessibility checking that relies on authors to decide whether potential web content accessibility problems (WCAG) are correctly identified (i.e. manual checking and semi-automated checking), then the accessibility checking process provides instructions that describe how to decide. (Level A)

 

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Checking assistance (WCAG Level A) includes help to decide whether potential issues are actual issues, if user judgement is required.

  1. Examine the checking functionality identified in the WCAG Level A-related tests for B.3.1.1. If no checking functionality exists, then select SKIP.
  2. If the checker automatically identifies all of the issues, then select SKIP.
  3. If the checker relies on the author to verify any found issues (as semi-automatic checks do) or find issues (as manual instructions do), then check whether support of some kind (e.g. instructions) is provided in each case to help the user make the required decision. If such support is always provided, then select PASS, otherwise select FAIL.

Test 0002 Assertion: Checking assistance (WCAG Level AA) includes help to decide whether potential issues are actual issues, if user judgement is required. (Note: Only shown if the user has specified AA or AAA as the target level)

  1. Examine the checking functionality identified in the WCAG Level AA-related tests for B.3.1.1. If no checking functionality exists, then select SKIP.
  2. If the checker automatically identifies all of the issues, then select SKIP.
  3. If the checker relies on the author to verify any found issues (as semi-automatic checks do) or find issues (as manual instructions do), then check whether support of some kind (e.g. instructions) is provided in each case to help the user make the required decision. If such support is always provided, then select PASS, otherwise select FAIL.

Test 0003 Assertion: Checking assistance (WCAG Level AAA) includes help to decide whether potential issues are actual issues, if user judgement is required. (Note: Only shown if the user has specified AAA as the target level)

  1. Examine the checking functionality identified in the WCAG Level AAA-related tests for B.3.1.1. If no checking functionality exists, then select SKIP.
  2. If the checker automatically identifies all of the issues, then select SKIP.
  3. If the checker relies on the author to verify any found issues (as semi-automatic checks do) or find issues (as manual instructions do), then check whether support of some kind (e.g. instructions) is provided in each case to help the user make the required decision. If such support is always provided, then select PASS, otherwise select FAIL.

B.3.1.3 Help Authors Locate:

If the authoring tool provides checks that require authors to decide whether a potential web content accessibility problem (WCAG) is correctly identified (i.e. manual checking and semi-automated checking), then the relevant content is identified to the authors. (Level A)

  • Note: Depending on the nature of the editing-view and the scope of the potential web content accessibility problem (WCAG), identification might involve highlighting elements or renderings of elements, displaying line numbers, or providing instructions.

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Checking assistance (WCAG Level A) includes help to locate potential issues if user judgement is required.

  1. Examine the checking functionality identified in the WCAG Level A-related tests for B.3.1.1. If no checking functionality exists, then select SKIP.
  2. If the checker automatically identifies all of the issues, then select SKIP.
  3. If the checker relies on the author to verify any found issues (as semi-automatic checks do) or find issues (as manual instructions do), then check whether a mechanism of some kind (e.g. hyperlink to the location, identification by line number, instructions on how to locate, etc.) is provided in each case to help the user determine where the potential issue is located within the content. If such a mechanism is always provided, then select PASS, otherwise select FAIL.

Test 0002 Assertion: Checking assistance (WCAG Level AA) includes help to locate potential issues if user judgement is required. (Note: Only shown if the user has specified AA or AAA as the target level)

  1. Examine the checking functionality identified in the WCAG Level AA-related tests for B.3.1.1. If no checking functionality exists, then select SKIP.
  2. If the checker automatically identifies all of the issues, then select SKIP.
  3. If the checker relies on the author to verify any found issues (as semi-automatic checks do) or find issues (as manual instructions do), then check whether a mechanism of some kind (e.g. hyperlink to the location, identification by line number, instructions on how to locate, etc.) is provided in each case to help the user determine where the potential issue is located within the content. If such a mechanism is always provided, then select PASS, otherwise select FAIL.

Test 0003 Assertion: Checking assistance (WCAG Level AAA) includes help to locate potential issues if user judgement is required. (Note: Only shown if the user has specified AAA as the target level)

  1. Examine the checking functionality identified in the WCAG Level AAA-related tests for B.3.1.1. If no checking functionality exists, then select SKIP.
  2. If the checker automatically identifies all of the issues, then select SKIP.
  3. If the checker relies on the author to verify any found issues (as semi-automatic checks do) or find issues (as manual instructions do), then check whether a mechanism of some kind (e.g. hyperlink to the location, identification by line number, instructions on how to locate, etc.) is provided in each case to help the user determine where the potential issue is located within the content. If such a mechanism is always provided, then select PASS, otherwise select FAIL.

B.3.1.4 Status Report:

If the authoring tool provides checks, then authors can receive an accessibility status report based on the results of the accessibility checks. (Level AA)

  • Note: The format of the accessibility status report is not specified and they might include a listing of problems detected or a WCAG 2.0 conformance level, etc.

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Accessibility status reporting is present.

  1. Examine the checking functionality identified for B.3.1.1. If no checking functionality exists, then select SKIP.
  2. If the checking functionality does not result in any information being returned to the author about accessibility issues, then select FAIL.
  3. If the information returned is gathered together in some way (e.g. a conformance statement, a list of accessibility problems, etc.), then select PASS.

B.3.1.5 Programmatic Association of Results:

If the authoring tool provides checks, then the authoring tool can programmatically associate accessibility checking results with the web content that was checked. (Level AA)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Checking results can be programmatically associated to the content.

  1. Examine the checking functionality identified for B.3.1.1. If no checking functionality exists, then select SKIP.
  2. Examine the checking functionality (including settings and documentation) to see if it includes any functionality that allows the results of the checking to be programmatically associated with the content (e.g. as a file containing the checking results that includes a hyperlink back to the checked content).
  3. If the checking results can be programmatically associated with the content, then select PASS. Otherwise, select FAIL.
Guideline B.3.2: Assist authors in repairing accessibility problems. Tests

B.3.2.1 Repair Assistance (WCAG):

If checking (see Success Criterion B.3.1.1) can detect that a WCAG 2.0 success criterion is not met, then repair suggestion(s) are provided: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

  • Note: Automated and semi-automated repair is possible (and encouraged) for many types of web content accessibility problems (WCAG). 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.

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Checking assistance (WCAG Level A) includes help to repair all detected issues.

  1. Examine the checking functionality identified in the WCAG Level A-related tests for B.3.1.1. If no checking functionality exists, then select SKIP.
  2. If the authoring tool automatically repairs all identified issues, then select SKIP.
  3. For each identified issue, that is not automatically fixed:
    1. Check whether support of some kind (e.g. dialog with repair options, instructions on how to repair, etc.) is provided. If it is, go to the next issue.
    2. If no support is provided, then select FAIL.
    3. Go to the next issue (if any).
  4. Select PASS (all of the issues must have repair support)

Test 0002 Assertion: Checking assistance (WCAG Level AA) includes help to repair all detected issues. (Note: Only shown if the user has specified AA or AAA as the target level)

  1. Examine the checking functionality identified in the WCAG Level A-related tests for B.3.1.1. If no checking functionality exists, then select SKIP.
  2. If the authoring tool automatically repairs all identified issues, then select SKIP.
  3. For each identified issue, that is not automatically fixed:
    1. Check whether support of some kind (e.g. dialog with repair options, instructions on how to repair, etc.) is provided. If it is, go to the next issue.
    2. If no support is provided, then select FAIL.
    3. Go to the next issue (if any).
  4. Select PASS (all of the issues must have repair support)

Test 0003 Assertion: Checking assistance (WCAG Level AAA) includes help to repair all detected issues. (Note: Only shown if the user has specified AAA as the target level)

  1. Examine the checking functionality identified in the WCAG Level A-related tests for B.3.1.1. If no checking functionality exists, then select SKIP.
  2. If the authoring tool automatically repairs all identified issues, then select SKIP.
  3. For each identified issue, that is not automatically fixed:
    1. Check whether support of some kind (e.g. dialog with repair options, instructions on how to repair, etc.) is provided. If it is, go to the next issue.
    2. If no support is provided, then select FAIL.
    3. Go to the next issue (if any).
  4. Select PASS (all of the issues must have repair support)
PRINCIPLE B.4: Authoring tools promote and integrate their accessibility features Tests
Guideline B.4.1: Ensure the availability of features that support the production of accessible content. Tests

B.4.1.1 Features Active by Default:

All accessible content support features are turned on by default. (Level A)

 

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: All accessible content support features are turned on by default.

  1. Create or retrieve the List of Accessible Content Support Features (the "List')
  2. For each feature on the "List":
    1. If the feature is "always on", go to the next feature.
    2. If the feature can be turned off, check whether it is on by default. If it is, go to the next feature.
    3. If the feuture is off by default, then then select FAIL.
    4. Go to the next feature (if any).
  3. Select PASS (all of the accessible content support features must have passed)

B.4.1.2 Option to Reactivate Features:

The authoring tool does not include the option to turn off its accessible content support features or features which have been turned off can be turned back on. (Level A)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: All accessible content support features that can be turned off, can also be turned back on.

  1. Retrieve or create the List of Accessible Content Support Features (the "List").
  2. For each feature on the "List":
    1. Determine whether the feature can be turned off. If not, go to the next feature.
    2. Turn off the feature and then check whether it can be turned back on. If it can be turned back on, go to the next feature.
    3. If the feature cannot be turned back on, then select FAIL.
    4. Go to the next feature (if any).
  3. Select PASS (all of the accessible content support features must have passed)

B.4.1.3 Feature Deactivation Warning:

The authoring tool does not include the option to turn off its accessible content support features or, if these features can be turned off, authors are informed that this may increase the risk of content accessibility problems (WCAG). (Level AA)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: All accessible content support features that can be turned off include a warning of the potential consequences.

  1. Retrieve or create the List of Accessible Content Support Features (the "List").
  2. For each feature on the "List":
    1. Determine whether the feature can be turned off. If not, go to the next feature.
    2. If it can be turned off, turn it off and check for any type of warning (text, icon, pop-up, etc.), before and/or after the feature is turned off, explaining that turning off the feature may increase the risk of accessibility problems being introduced. If a warning is present, go to the next feature.
    3. If no warning is presented, then select FAIL.
    4. Go to the next feature (if any).
  3. Select PASS (all of the accessible content support features must have passed)

B.4.1.4 Feature Prominence:

All accessible content support features are at least as prominent as features related to either invalid markup, syntax errors, spelling errors or grammar errors. (Level AA)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Content support features are as prominent as features related to either invalid markup, syntax errors, spelling errors or grammar errors.

  1. Retrieve or create the List of Accessible Content Support Features (the "List").
  2. For each feature on the "List":
    1. Identify whether the feature is comparable to another feature of the authoring tool related to either invalid markup, syntax errors, spelling errors, or grammar errors (e.g. an accessibility checker is comparable with a spell checker). If there is no comparable feature, go to the next feature.
    2. If there is a comparable feature, for both the accessible feature and its comparator-feature, determine how many "opening actions" are required to access each. "Opening actions" are actions made by authors on components within the user interface that result in new components becoming displayed or enabled. (e.g. keyboard shortcut to a top-level menu item to display a sub-menu, keyboard selection on a button to display a dialog box, mouse click on a checkbox to enable previously disabled sub-items, etc. Actions that do not cause new components to become actionable (e.g. moving focus, scrolling a list), are not counted as "opening actions".)
    3. If the accessible content support feature requires the same or less "opening actions", go to the next feature.
    4. If the comparator feature requires less "opening actions", then select FAIL.
    5. Go to the next feature (if any).
  3. Select PASS (all of the accessible content support features must have passed)
Guideline B.4.2: Ensure that documentation promotes the production of accessible content. Tests

B.4.2.1 Model Practice (WCAG):

A range of examples in the documentation (e.g. markup, screen shots of WYSIWYG editing-views) demonstrate accessible authoring practices (WCAG). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: At least two examples of Level A accessible authoring practices appear in the documentation. (Note: Only shown if the user has specified A as the target level)

  1. Locate the authoring tool's documentation.
  2. Locate examples of authoring practice being used in the documentation (e.g. examples of markup, screenshots, etc.).
  3. Referring to the Web Content Accessibility Test Procedure (Level A), determine whether the demonstrated authoring practice would meet WCAG 2.0 Level A (e.g. if an image insertion dialog box is shown with an inappropriately empty alt field).
  4. If two practices can be found that would meet WCAG 2.0 Level A, select PASS. Otherwise, select FAIL.

Test 0002 Assertion: At least two examples of Level AA accessible authoring practices appear in the documentation. (Note: Only shown if the user has specified AA as the target level)

  1. Locate the authoring tool's documentation.
  2. Locate examples of authoring practice being used in the documentation (e.g. examples of markup, screenshots, etc.).
  3. Referring to the Web Content Accessibility Test Procedure (Level AA), determine whether the demonstrated authoring practice would meet WCAG 2.0 Level AA (e.g. if an image insertion dialog box is shown with an inappropriately empty alt field).
  4. If two practices can be found that would meet WCAG 2.0 Level AA, select PASS. Otherwise, select FAIL.

Test 0003 Assertion: At least two examples of Level AAA accessible authoring practices appear in the documentation. (Note: Only shown if the user has specified AAA as the target level)

  1. Locate the authoring tool's documentation.
  2. Locate examples of authoring practice being used in the documentation (e.g. examples of markup, screenshots, etc.).
  3. Referring to the Web Content Accessibility Test Procedure (Level AAA), determine whether the demonstrated authoring practice would meet WCAG 2.0 Level AAA (e.g. if an image insertion dialog box is shown with an inappropriately empty alt field).
  4. If two practices can be found that would meet WCAG 2.0 Level AAA, select PASS. Otherwise, select FAIL.

B.4.2.2 Feature Instructions:

Instructions for using any accessible content support features appear in the documentation. (Level A)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: Instructions for using any accessible content support features appear in the documentation.

  1. Search the authoring tool user interface (and linked support material) for documentation (e.g. a help system)
  2. If no documentation can be found, then select FAIL.
  3. Retrieve or create the List of Accessible Content Support Features (the "List").
  4. For each feature on the "List":
    1. If the feature does have instructions in the documentation, go to the next feature.
    2. If the feature does not have instructions in the documentation, then select FAIL.
    3. Go to the next feature (if any).
  5. Select PASS (all of the accessible content support features must have passed)

B.4.2.3 Tutorial:

The authoring tool provides a tutorial for an accessible authoring process that is specific to that authoring tool. (Level AAA)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: The authoring tool provides a tutorial for an accessible authoring process that is specific to that authoring tool.

  1. Search the authoring tool user interface (and linked support material) for a step-by-step tutorial explaining how to use the tool to produce accessible web content.
  2. If no accessibility-related tutorials can be found, then select FAIL.
  3. If one or more accessibility-related tutorials are found, review the tutorials checking whether any of the tutorials are specific to the authoring tool or whether they only treat the subject generally (such that the tutorials could equally serve as a tutorial for a different authoring tool).
  4. If any of the tutorials is specific to the authoring tool , then select PASS. Otherwise, select FAIL.

B.4.2.4 Instruction Index:

The authoring tool documentation contains an index to the instructions for using any accessible content support features. (Level AAA)

@@Changes approved http://www.w3.org/2013/03/18-au-minutes.html#item02

Test 0001 Assertion: The authoring tool documentation contains an index to the instructions for using any accessible content support features.

  1. Search the authoring tool user interface (and linked support material) for an instruction index (e.g. "Search Help", list of help topics, etc.).
  2. If no index can be found, then select FAIL.
  3. Retrieve or create the List of Accessible Content Support Features (the "List").
  4. For each feature on the "List":
    1. If the feature does not have instructions in the documentation, go to the next feature.
    2. If the feature does have instructions in the documentation, and is reachable from the index, go to the next feature.
    3. If the feature does have instructions in the documentation, but is not reachable from the index, then select FAIL.
    4. Go to the next feature (if any).
  5. Select PASS (all of the accessible content support features must have passed)

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 concerned with producing the "included" web content technologies. This includes views of the web content being edited and features that are independent of the content being edited (e.g. menus, button bars, status bars, user preferences, documentation).
  2. Reflected content accessibility problems: The authoring tool is responsible for ensuring that editing-views display the web content being edited in a way that is more accessible to authors with disabilities (e.g. ensuring that text alternatives in the content can be programmatically determined). However, where an authoring tool user interface accessibility problem is caused directly by the content being edited (e.g. if an image in the content lacks a text alternative), then this would not be considered a deficiency in the accessibility of the authoring tool user interface.
  3. Developer control: The Part A success criteria only apply to the authoring tool user interface as it is provided by the developer. They do not apply to any subsequent modifications by parties other than the authoring tool developer (e.g. user modifications of default settings, third-party plug-ins).
  4. User agent features: Web-based authoring tools may rely on user agent features (e.g. keyboard navigation, find functions, display preferences, undo features) to satisfy success criteria. Conformance claims are optional, but any claim that is made must record the user agent(s).
  5. Accessibility of features provided to meet Part A: 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). The only exemption is for preview features, as long as they meet the relevant success criteria in 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 functionality of user agents that are actually in use by end users.
  6. Unrecognizable content: When success criteria require authoring tools to treat web content according to semantic criteria, the success criteria do not apply when these semantics are missing (e.g. text that describes an image is only considered to be a text alternative when this role is encoded within markup).

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. Developer control: The Part B success criteria only apply to the authoring tool as it is provided by the developer. This does not include subsequent modifications by parties other than the authoring tool developer (e.g. third-party plug-ins, user-defined templates, user modifications of default settings).
  3. Applicability after the end of an authoring session: Authoring tools are responsible for the web content accessibility (WCAG) of web content that they automatically generate after the end of an author's authoring session (see Success Criterion B.1.1.1). For example, if the developer changes the site-wide templates of a content management system, these would be required to meet the accessibility requirements for automatically-generated content. Authoring tools are not responsible for changes to the accessibility of content that the author causes, whether it is author-generated or automatically-generated by another system that the author has specified (e.g. a third-party feed).
  4. 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 tool).
  5. Accessibility of features provided to meet Part B: The Part A success criteria apply to the entire authoring tool user interface, including any features that must be present to meet the success criteria in Part B (e.g. checking tools, repair tools, tutorials, documentation).
  6. Multiple authoring roles: Some authoring tools 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 authoring role. Accessible content support features should be made available to any authoring role where it would be useful.
  7. Unrecognizable content: When success criteria require authoring tools to treat web content according to semantic criteria, the success criteria do not apply when these semantics are missing (e.g. text that describes an image is only considered to be a text alternative when this role is encoded within markup).