Testing

From Challenge Gallery
Revision as of 19:52, 23 June 2011 by Jbrewer (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This is a planning page for the Grab and Go Gallery for Accessible Web Authoring, for easier authoring of accessible Web content.

Pages: Main_Page - Description - "Grab and Go Gallery" Draft Landing Page - Sources & Samples - Testing - Meetings - Gallery Requirements

Testing Your Submissions for Accessibility

Testing Overview

  • Web components that we will include in the "Grab and Go Gallery" should be accessible to people with disabilities. Even though we will review your submissions, please submit only templates and components that you have pre-tested for accessibility.
  • When you submit your template or widget, verify that you have evaluated your submissions for accessibility support using the following protocol.
  1. Test for conformance to W3C/WAI Web Content Accessibility Guidelines (WCAG) 2.0 at least Level AA, using How to Meet WCAG 2.0. Additional resources for WCAG 2.0 are below.
  2. If your submission is a rich internet application, use WAI-ARIA techniques. See WAI-ARIA for techniques, practices, and additional resources. Also see "Extended test procedure for dynamic template and widgets" below.
  3. If your submission requires an authoring tool to operate (e.g. a template that only works within a particular authoring tool) then test with the W3C-WAI Authoring Tool Accessibility Guidelines (ATAG) 2.0 level AA (Working Draft includes recommendations concerning templates and pre-authored content. The following guidelines and their associated success criteria are particularly applicable to templates and widgets:
    1. Assist authors with accessible templates.
    2. Assist authors with accessible pre-authored content.
  4. If your submission is itself an authoring tool (for instance, a widget for editing HTML), then test for conformance of the authoring tool to ATAG 2.0 Level AA.
  • In addition, please describe any additional accessibility tests that you have performed.

Sample basic test procedure for templates and widgets

  1. Create a demo web site that uses your submission.
  2. Unplug your mouse and make sure you can operate your demo site using only your keyboard.
  3. Use your browser to change the default size and color of text and make sure your demo site responds.
  4. Look for structure and order:
    1. Using a browser function or add-on that supports viewing page structure, such as the IE7 Developer Toolbar, IE8 Developer Tools (built-in, use the Tools -> Developer Tools menu) or Firefox Web Developer add-on:
    2. Disable “CSS”. Are there things that are acting as headings that aren’t big and bold in this mode? Do things that feel like lists have bullets? Are the clickable things either gray buttons or blue underlined links? Are things in a usable order?
  5. Check high contrast mode (Windows procedure follows.) @@ add high contrast test procedure for other operating systems @@
    1. In Windows, choose Start Menu/Control Panel/Ease of Access Center/Optimize Visual Display
    2. Check "turn on or off high contrast mode with left ALT + left SHIFT + PRINT SCREEN"
    3. Click "Choose a High Contrast Theme", scroll down to the bottom and pick one of the high contrast themes. Include the test for High Contrast Black, as this mode is visibly distinct from the standard theme.
    4. If the system isn't in high contrast mode after this, close the control panel dialogs, and press left ALT + left SHIFT + PRINT SCREEN
    5. Is the web app/widget black with white text? Are all background colors and images gone? Are all important images either still there or replaced with text? (It's a common bug to have all images, including buttons, disappear in high contrast mode since they have often been added with CSS background-image.) Is the layout not in a logical sequence? Can you read all the text?
    6. Run through the tasks again. Is all the information readable and tasks operational in all the states and steps?
    7. Press left ALT + left SHIFT + PRINT SCREEN to restore your display to how it was previously.
  6. Check your demo web site with an accessibility checker set to WCAG 2.0 AA (How to Meet WCAG 2.0). See Web Accessibility Evaluation Tools for a list of tools. Many are free online tools.
  7. Test your demo site with a screen reader. Some free screenreaders are: VoiceOver for MacOS, NVDA for Windows, Orca for Linux.
  8. If your submission is a rich internet application (where the web content changes without reloading the page), be sure to continue to the following "extended" steps.

Extended test procedure for dynamic template and widgets

  • Widgets and dynamic sites where the web content changes without reloading the page need additional testing. A suggested approach follows:
  1. Provide clear documentation on what your app or widget is supposed to do, because the Gallery's reviewers need to know what behavior to test for when they perform their own tests.
  2. Install an API viewing tool, such as Inspect (download as part of Windows SDK) or AccChecker. There is also one for the Mac platform.
  3. Instantiate it in a test page.
  4. Open your app and a test page in different browsers.
  5. Launch Inspect. Disable “watch cursor” so it follows keyboard focus. Enable “Show Highlight Rectangle” to make the focus rectangle big and yellow.
  6. Tab through the app or widget and attempt to do tasks it is documented to do without using a mouse.
    1. Can each task be accomplished using only the keyboard?
    2. For each tab stop, examine the MSAA and UIA information in the tool. (note that these can be set either from ARIA or by using native HTML controls.)
    3. Does the role/control type match the function of each control? For example do things that look and act like buttons have a role/control type of button?
    4. Does each tabstop have a name? (note that alt text from images doesn’t bubble up to containing links in this tool, even though it works in real AT)
    5. Try this in multiple browsers in case browser sniffing is making something inaccessible in a particular browser.

Identify any authoring tool, browser or viewer requirements

  • The Grab and Go Gallery welcomes templates and widgets that are specific to particular applications or platforms, but to be useful to others, we will need to categorize your web components appropriately. Please clearly identify and describe any specific authoring tool, browser or viewer requirements necessary to use your submission.

WCAG 2.0 Resources

  1. WCAG 2.0 at a Glance
  2. How to Meet WCAG 2.0
  3. WCAG 2.0 Overview
  4. WCAG 2.0
  5. Selecting Web Accessibility Evaluation Tools
  6. Web Accessibility Evaluation Tools

WAI-ARIA Resources

  1. Accessible Rich Internet Applications (WAI-ARIA) 1.0
  2. WAI-ARIA 1.0 Primer
  3. WAI-ARIA 1.0 Authoring Practices
  4. WAI-ARIA 1.0 User Agent Implementation Guide
  5. WAI-ARIA FAQ

Testing of Submissions by Reviewers

  • The tests above and additional tests may be performed by the reviewers when evaluating your submission.