Important note: This Wiki page is edited by participants of the EOWG. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.


Web Accessibility Preliminary Evaluation

From Education & Outreach
Revision as of 14:34, 26 October 2012 by Srush (Talk | contribs)

Jump to: navigation, search

Nav: EOWG wiki main page > Evaluation Pages
Old page on WAI website: Prelim Eval
Related: Preliminary Eval - old notes
See also: Eval Analysis for tasks, example user cases with audience, and focus for this and related documents.

Note:

Preliminary Review|Evaluation: Checking the Accessibility of a Web Page

Introduction

Testing and evaluating a web site for accessibility may seem intimidating but it need not be. There are simple ways to check on some basic features that do not require special skills or tools beyond your browser controls. Here you will find two approaches to doing Preliminary Evaluation of your pages. The first is a Quick Check - a list of 5 things you can do in 5 minutes. The second, while not a full conformance validation of WCAG2 Guidelines, will help ensure basic accessibility across a broader range of issues. While the second can quickly determine if the most important elements of a web page can be used by most persons with disabilities, it also requires more knowledge of accessibility principles and a few testing tools.

Quick Checks

Here are 5 things you can do to quickly check for accessibility barriers on a web page:
Group input needed to develop the top five list of things to include

  1. First thing.
  2. Second thing.
  3. Third thing.
  4. Fourth thing.
  5. Fifth thing.

Once you have taken this quick dip you may be ready to dive a bit deeper. The next section provides more context and additional things you can do to check for accessibility barriers.

Possible items to list above - please add to this list

  • Turn off images
  • Disable CSS
  • Zoom to 200%
  • Tab through the page (no mouse)
  • Use one-page auto checker

A Deeper Look

If you are interested in a more comprehensive look at the page(s), here more tests that require a little more time, skills, and/or tools.

  1. Load your tool kit. (List tools that can be freely accessed and/or installed in browser, or link to Complete list of Web Accessibility Evaluation Tools and Web AIM's Review of Free, Online Accessibility Tools)
  2. Choose or create a reporting template (Introduce Evaluation Templates from WAI)
  3. select a representative page sample (Introduce and link to WAI Conformance Evaluation Page
  4. Using your chosen template as a guide, examine the following features of the web page(s) you are evaluating:

    (Note to EO: Here is where we can describe testing procedures for each of these - and likely additional ones. Please suggest structure and additional content)

Smart analysis simplified (Basic web view)

This human-intelligence-based method can quickly determine if the most important elements of a web page can be used by most persons with disabilities. This checklist is no substitute for training, but once trained designers and developers can use this as they move from task to task. Used throughout the design and development process, this quick check will help to avoid accessibility errors that require major changes to the website's design or implementation.
{@@Note to EO: Techniques for testing these items are needed. Please think about structure and how to change the structure to include the testing protocols}

  1. Validation check: HTML and CSS code should comply with W3C standards.
    • Always check with W3C HTML and CSS Validators
    • Check that the document language is declared

  2. Visual check: Do each of the following common sense tests.
    • All text should be easily legible to fully-sighted readers.
    • When text-only enlargement is used in the browser, all text (except banner logos) should respond and nothing should overlap or be hidden.
    • Make sure nothing is flickering or flashing unless this activity is necessary for the meaning of the content.
    • Make sure the Title of the page (in the browser title bar) is descriptive of the content.
    • Check to see that there is a clear luminosity difference between the background and text in the foreground. Be sure to test special states like hover for contrast problems. An easy way to test contrast is to reduce the luminosity of the monitor by about 40%. Foreground and background should still be distinct.
  3. Dynamic Content: This category includes time based media, animations, and content management system content, and rich internet applications. You will only identify the most obvious barriers; most dynamic content will require specialized, detailed analysis to insure complete accessibility.
    • Visually, confirm access to captions and transcripts (when appropriate) for all time based media;
    • Do all testing with keyboard only.
    • Identify any time dependent responses.
    • Give all animation a quick Visual Check. Embedded text should be readable, enlargement capability should be present and effective, flashing and blinking should be confined to necessary semantic role, and test all states.
    • Treat CMS generated data just like normal web content, but try to separate template issues from local instance issues.
    • Check for WAI ARIA role, state and property presence in all ARIA widgets.
    • Check for WAI ARIA landmarks in all widgets.
    • Test every rich internet application with keyboard only.
  4. Parallel Content: Frequently a page will require an alternative page to support accessibility. This is OK when required but check:
    • Is there an automatic mechanism to update both versions simultaneously? There should be.
    • Is the alternative as rich semantically. For example replacing structured HTML with plain text is not acceptable.
  5. Color: Make sure that information is not conveyed by color alone. Verify that color contrast does not substitute for luminosity contrast.
  6. Headings: Headings should match the actual semantic structure of the document and should be properly nested by level. Headings should also be used to identify and navigate between groups of related links. Proper use of headings is now more accessible than adding "skip navigation" links. For ARIA widgets, use landmarks as you would use headings for text based content.
  7. Image maps: HTML still has a MAP element, but today image maps are also implemented with CSS, sprites, and live regions. All maps and map equivalents still need to provide alternative text equivalents and full keyboard access. All image map objects contain graphical regions with hot spots that contain links or controls. The same issues arise with all image map objects. So always check:
    •  Active graphical hot spots of an image map must have associated text alternatives to activate controls and links.
    • Keyboard traversal should be possible through the controls and links present in the map. This includes visual access for sighted users who want to tab through an image map visually.
  8. Forms: Each form control must have an associated label that describes its purpose. Tab order between form controls must match the order in which a user would normally complete them. Complex forms benefit from grouping controls with the FIELDSET element. The form title is optional if the purpose of the form can be determined from context. "Placeholder" text inside text boxes is no longer needed for screen readers; it is redundant in a properly-labeled form. Many forms will also have to be evaluated separately for dynamic behavior such as error response.
  9. Frames: Frames are deprecated and should never be used in new development. If your software maintenance cycle includes upgrading code that includes frames, it is time to remove them.
  10. Iframes: This tool is necessary for multi server access. Content introduced through iframes should be tested like any content.
  11. Images: With images replaced by their text equivalents, no information or navigation should be lost to any visitor to the page. Purely decorative images should have null (empty) text equivalents. All images should have text alternatives, content or explicit null.
  12. Styles and layout: View the page with all style off. The semantic structure of the page content should be readily understandable from the browser's default rendering (of headings, lists, and so on) and navigable by assistive technologies. No content should appear that was made visible by CSS solely with mouse action (hover) or otherwise hidden from sighted readers. With layout tables removed, the page should read in logical order from top to bottom; use of layout tables should be kept to an absolute minimum.
  13. Data Tables: Layout tables (those with no heading elements) should never be used to contain truly tabular data, and should never have summary attributes. True data tables should have each data cell associated with its column (and row, if appropriate) header or headers. Complex tables should have each data cell associated with all applicable heading levels.

(Contributed by Tom Jewett, Wayne Dick and the California State University Web Community of Practice)

More Thorough Evaluation

@@ point to Conformance Evaluation page and WCAG-EM.