Nav: EOWG wiki main page > Curriculum & Course Materials > current draft Web Accessibility Preliminary Evaluation

misc

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)
Choose or create a reporting template (Introduce Evaluation Templates from WAI)
select a representative page sample (Introduce and link to WAI Conformance Evaluation Page
Using your chosen template as a guide, examine the following features of the web page(s) you are evaluating:

[DRAFT, very rough] Web Accessibility Preliminary Evaluation

{@@ note for editing: See Analysis & Comments in the Discussion tab. ~shawn}
{@@ note for editing: Feel free to totally restructure and rewrite this page. ~shawn}

Introduction

A preliminary review can quickly identify some accessibility problems on a Web site. A preliminary review does not check every accessibility issue and will not catch all of the problems on a site. Thus the method described in this page is not sufficient to determine if a Web site conforms to Web accessibility guidelines. Other pages in this Evaluation Resource Suite address conformance evaluation and related evaluation topics.

A preliminary review combines some manual checking of representative pages on a Web site, along with the use of several semi-automatic accessibility evaluation tools. Reviewers do not need to know Web mark-up languages, but should be able to download software and familiarize themselves with some evaluation tools, and change certain settings on their browser. To conduct a preliminary review, complete all five tasks below.

Select a representative page sample

From the Web site to be reviewed, select a representative sampling of pages that match the following criteria:

Include all pages on which people are more likely to enter your site ("welcome page", etc.).
Include a variety of pages with different layouts and functionality, for example:
- Web pages with tables, forms, or dynamically generated results;
- Web pages with informative images such as diagrams or graphs;
- Web pages with scripts or applications that perform functionality.
Note: there are special considerations for web sites with database driven dynamically generated web content.

Examine pages using graphical browsers

Use a web browser (such as Firefox, Internet Explorer, Chrome, Opera, Safari, or others) and examine the selection of pages for the following (some of these manual checks may require additional software, such as the Web Developer Extension for Firefox):

Turn off images, and check whether appropriate alternative text for the images is available.
Turn off css, and check whether informative images remain visible.
Outline the document's section headings to see if they are marked up using h1 to h6 elements or use the HeadingsMap Firefox extension to show the heading structure of the document.
Turn off the sound, and check whether audio content is still available through text equivalents.
Use browser controls to vary font-size: verify that the font size changes on the screen accordingly; and that the page is still usable at larger font sizes.
Test with different screen resolution, and/or by resizing the application window to less than maximum, to verify that horizontal scrolling is not required (caution: test with different browsers, or examine code for absolute sizing, to ensure that it is a content problem not a browser problem).
Change the display color to gray scale (or print out page in gray scale or black and white) and observe whether the color contrast is adequate or use Vision Australia's Color contrast analyzer tool to measure specific contrasts.
Without using the mouse, use the keyboard to navigate through the links and form controls on a page (for example, using the "Tab" key), making sure that you can access all links and form controls, and that the links clearly indicate what they lead to.

Note: Browser extensions and other plug-in evaluation tools (such as AIS Toolbar for Internet Explorer, WAVE Toolbar for Firefox, Web Developer Extension for Firefox or Accessibility Evaluation toolbar) provide functionality to help perform some of these manual checks and many more.

Note: For reviewers who have disabilities, certain of the following tasks may need to be done with another person who does not have the same disability.

Examine pages using specialized browsers

Use a screen reader (such as NVDA), a screen reader emulator (such as the Fangs extension for Firefox) or a text browser (such as Lynx) and examine the selection of pages while answering these questions:

Is there a conforming alternate version of the information available through the screen reader or text browser as is available through the browser?
Is the information presented in a meaningful order if read serially?

Note: experienced users of screen readers may substitute a screen reader for a text browser, but if blind, may need a sighted partner to compare information available visually; if sighted, listen to it with eyes closed, then open eyes and confirm whether the information is equivalent.

Use automated Web accessibility evaluation tools

Use at least two automated Web accessibility evaluation tools to analyze the selection of pages and note any problems indicated by the tools. Note: these tools will only check the accessibility aspects that can be tested automatically, the results from these tools should not be used to determine a conformance level without further manual testing.

Browser based tests

{@@note: some of these seem much more than 'basic' tests that could be carried out by non-technical folk ~Andrew}
{@@note: definitely some are more advanced. this section was just added in for ideas. the whole page needs to be significantly re-structured and edited, including this section. ~shawn}

Credit: Al Duggin

1. In a browser - javascript off and css off - does everything make sense?

Is all core content accessible?
Has correct semantic markup been used?
Has heading heirachy been used?
Are there any duplicate links or links without useful labels?
Check wai-aria landmark roles

2. In a browser - javascript off and css on

Is all core content available?
Check for any broken functionality - e.g do all links work (Make sure that no links have <a href=”#”>)
Has progressive enhancement been used?
Check for display:none
Load in a users stylesheet to confirm that your stylesheet is overrideable - e.g Custom Styles for iOS

3. In a browser - javascript on and css on - use a keyboard instead of a mouse

Can you do everything effciently? Can you complete all actions?
Is it obvious what has focus? (use :focus as well as :hover)?
Have correct controls been used - e.g links, buttons and inputs?
Does the space bar work on all elements that have role=”button”?
Has focus and linear flow been managed properly? Make sure there aren’t any keyboard traps?
Forms - check for success case, error case, the ‘correction’ case
Make sure you are not ‘killing other keyboard functionality
Can pop-ups/dialogs be closed with the escape key? Does focus return to item then opened it?
Is the virtual buffer updated when ajax is used to insert new content into the page - is the user notified of an update or focus set to the new content?

4. In a browser - with css and javascript on - increase the font size by +2.

Is text still readable?
Does the text or content truncate or overlay?
Are there huge empty spaces between form fields and labels?

5. In a browser - with css and javascript on - turn off all images

Is page still usable - checking for alt text and color contrast (e.g no white text on white a white background)

6. In a browser - with css and javascript on - use ZOOM or a screen magnifier

Are all parts of the page usable?

7. In a browser with javascript on - use a screenreader (NVDA, JAWS, VoiceOver)

Is all content and functionality accessible and usable?
Are tables accessible?
Are forms accessible?
Has wai-aria been used to improve accessibility/usability?
Are users notified of new content or taken to it by setting focus to it?

8. Use an old browser with javascript on and css on - e.g explorer 5

Is all core content available/usable?
We don’t want any javascript error - or broken layout - should work the same as no js and no css. We also don't want a user to be offered links/buttons that don't do anything etc

9. Use a tablet - e.g iPad

Does eveything work on a touch device?
With Voiceover on are all images labeled?
Are changes of state notified?

10. Use a Printer

Is core content readable?
Make sure width of content is not too wide for paper
Is a minium number of pages printed out - don’t want to infuriate users by wasting paper!

11. Automated tests

Run a colour contrast checker
HTML validation (if you page is html5 and has microdata choose: HTML5 + SVG 1.1 + MathML 2.0 + RDFa 1.1 + Microdata)
Use a link checker

Summarize obtained results

Summarize results obtained from previous four tasks:

Summarize the types of problems encountered, as well as positive aspects that should be continued or expanded on the site.
Indicate the method by which problems were identified, and clearly state that this was not a full conformance evaluation.
Recommend follow-up steps, including full conformance evaluation which includes validation of markup and other tests, and ways to address any problems identified.

Related pages

This document is part of a multi-page Evaluating Web Accessibility resource suite that outlines different approaches for evaluating Web accessibility. @@ some of that info out of date...

Acknowledgements

Recent contributors: Denis Boudreau, Al Duggin (browser-based test material)
Previous editor: Shadi Abou-Zahra
Developed by W3C WAI Education and Outreach Working Group (EOWG) participants.