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.

Difference between revisions of "Web Accessibility Preliminary Evaluation"

From Education & Outreach
Jump to: navigation, search
(A Deeper Look)
(Check color contrast [open for drafting])
Line 195: Line 195:
===Check color contrast [open for drafting]===
===Check color contrast [open for drafting]===
Wayne and Tom:
===Check color coding [open for drafting]===
===Check color coding [open for drafting]===

Revision as of 19:57, 13 November 2012

Nav: EOWG wiki main page > Evaluation Pages
Old page on WAI website: Prelim Eval


Important Note: For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way — for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.

Important Note: For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way — for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.

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


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.

... @@ first run on good BAD page to see what it should look like, then on the bad page ...

Quick Checks

Here are 5 things you can do to quickly check for accessibility barriers on a web page:
{EOWG note: Let's work on the longer section first, then decide what we can move up to the quick checks section later.

  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.

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.

{reminder: A template for the check draft items is at the top of the discussion tab.}

Check text descriptions for images [mostly drafted]

EOWG notes - importance: HIGH; 5min?: yes.

Text alternatives convey the purpose of an image or function to provide an equivalent user experience. For instance, an text alternative for a search button is "search". See also:


  • Text that is actually an image.
  • Important image should have alt text that provides adequate alternative of the image for people who cannot see it...
  • Image that doesn't convey important information...
  • @@ Some guidance on not saying things like "this is an image..." or "this is a link..."

Checking with WAVE

  1. Open WAVE
  2. In the "Enter a web site address" put the URI (for example, and click the "WAVE the page!" button.
  3. Look for a no alt icon that indicates that alt text is missing.
  4. Look for the alt icon that has the alt text next to it.

Disable images

  • Do: Disable images...
    • Check: @@For contrast problems...
  • Turn off CSS...


(See also Video & Sound below.)

Check headings and other semantic structure [some parts drafted]

EOWG notes - importance: HIGH; level: easy.

... @@ brief summary of why & what to check for ... See also:

What you're looking for: @@

  • Does the page have any headings?
  • Are the things that look like headings that aren't marked up as heading?
  • Are there things that are marked up as headings that aren't really headings?

Checking with WAVE

  1. Open WAVE
  2. Enter the web page:
    • If the website is online: Enter a web site address and click the "WAVE the page!" button.
    • ... Upload a file...
    • ... Check HTML code...
  3. Check headings:
    • ...
  4. Check lists:
    • ...

Checking headings with HTML Validator

  1. Open the W3C HTML Validator (The W3C Markup Validation Service).
  2. Select the appropriate tab and input the page:
    • If the web page is online, leave the Validate by URI tab selected.
      In the Address field, type the URI (e.g.,
    • If the web page is on your local computer, click the Validate by File Upload tab.
      In the File field, select "Choose..." and find the file on your computer.
    • If you will paste the HTML code/markup, Validate by Direct Input tab.
      Paste your HTML in the Enter the Markup to validate: field.
  3. Click the More Options link.
  4. Select the Outline checkbox.
  5. Click the Check button.
  6. In the results page at the top, click the Outline link.
  7. Compare the Document Outline to the visual rendering of the page.
    • Are the things that look like headings listed in the Document Outline?
    • Are there things in the Document Outline that aren't really headings?

Check keyboard access and visual focus [mostly drafted]

EOWG notes - importance: HIGH; 5min?: some yes.

Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires keyboard access to all functionality, including links, form controls, input, and other user interface components. See also:


  • Click in the address bar, then put your mouse aside and don't use it. Press the 'tab' key to move around the page.
    • Can you tab to all the elements, including links, form fields, buttons, and @@? Are there any actions you can't get to (e.g., if they are only available on mouse hover)?
    • Does the focus get stuck anywhere - that is, you can't tab away from a control (called a "keyboard trap")?
    • Does the order that items get focus make sense? (e.g., you don't jump around the page out of order logically)
    • Can you tab right through to the bottom of the page and then resume again from the top? (e.g. you don't get stuck anywhere and can't move on)
    • Can you clearly see where you've 'tabbed' to - that is, is the focus clearly visible all the time?
    • If there is a drop-down box (for example, for navigating to a different page): If you tab into the drop-down box, can you use the down/up arrow keys to move through the options, and @@use 'tab' to the following item@@? (Make sure it doesn't automatically select the first item.)

(see also Forms)


  • maybe don't see focus at all and are confused...
  • Mac browsers by default only tab through forms, will need to turn on...
  • not work easily in Opera...
  • ...

Check the page title [mostly drafted]

EOWG notes - importance: medium; 5min?: yes.

@@ add image showing only a few words with multiple tabs in browser...

Page titles are the first information read by a screen reader; useful for when users have multiple web pages opens, e.g., on different tabs and go between different windows. (Also good for adding to bookmarks & also search engine results.) See also:


  • Do: Look at the browser's window title bar.
    • Check: Should indicate the specific page and website as appropriate (often it is similar to the heading of the page).

Common failures:

  • Every page has the same title.
  • Long name of the website is first, then the specific page title.


  • Some browsers don't show title in browser title bar (Chrome, IE)

Check link text [partly drafted]

EOWG notes - importance: @@; 5min?: @@.

Wording the text that is linked to indicate clearly where the link goes or what the link does. Some people use a list of links where they don't see the text around it. See also:

Check this

  • @@
    • @@

Common failures:

  • Link text is something like "Click here" or "More" without any additional clarifying text.


  • List links (Can't find this in regular Firefox but easy in Opera where you can get a list of links from the standard tools menu, showing both title and url)
  • Issue - titles... (Ian P says never use titles on links, Sylvie agrees.)

Check usable with page zoomed and text enlarged [open for drafting]

  • Zoom to 200%
  • Text-only enlargement... (e.g., text actually changes in IE)

Check color contrast [open for drafting]

Wayne and Tom:

Check color coding [open for drafting]

Content order [open for drafting]

Visual focus [open for drafting]

Video, Sound, (multimedia) [open for drafting]


Forms [open for drafting]


Tables [open for drafting]


Check flickering, flashing, blinking [open for drafting]

Window resize [open for drafting]

... probably too complex an issue for preliminary eval ...

WAI-ARIA [open for drafting]

(note: not a requirement for accessibility)

Time-dependent responses [maybe not including this one]

Validate HTML & CSS [maybe not including this one]

Note: Validation not WCAG requirement...

  • ...
  • Check that the document language is declared

Check usable without CSS, javascript [probably not including this one]

NOTE: saz not WCAG requirement

  • Disable CSS
  • core content available
  • check images, check content displayed or not displayed (e.g., display:none), sequence
  • links
  • ...

Use an evaluation tool [probably won't include this generically]

  • Use one-page auto checker

EOWG discussion:

  • There are a number of simple tools where you just put in the URL of the page of interest and the results are returned automatically eg WAVE and TAW. The results aren't necessarily so easy to interpret if you are a newbie to accessibility. Perhaps we should put this after the top 5 easy checks - and add a paragraph to confirm the benefits and limitations, or discuss some of the common types of problem found {Suzette}

More Thorough Evaluation

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


Thanks to:

  • Those who drafted items for EOWG to review on Thursday 15 November:
    • {name} for drafting {section}
    • {name} for drafting {section}
  • Andrew & Shawn for editing the keyboard access & visual focus section in early Nov.
  • Ian, Suzette, Vicki, Sylvie, Helle, Shawn for working on an early draft at the f2f in Nov.
  • Sharron for help making all the drafts and versions less confusing.
  • Wayne and Ian for sharing colleagues' related work.
  • Denis for edits to the old page content.