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
(Check usable with page zoomed and text enlarged [Suzette is drafting])
(Video, Sound, (multimedia))
Line 242: Line 242:
===Content order [open for drafting]===
===Content order [open for drafting]===
===Video, Sound, (multimedia)===
===Video, Sound, (multimedia) [partly drafted]===
<span style="color:#808080;">EOWG notes - importance: high/medium/low; 5min?: some/yes/no/.is this appropriate for the short list at the top?).</span>
<span style="color:#808080;">EOWG notes - importance: high/medium/low; 5min?: some/yes/no/.is this appropriate for the short list at the top?).</span>

Revision as of 15:32, 21 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 a user who may not see the images. For instance, a text alternative for a search button is "search".

What to do

  1. Disable images in the browser
  2. Turn off CSS in the browser
  3. Use free checking tools to list the text alternatives (or lack of them) for all graphic elements
  4. If content is multimedia, see also

What to look for

If the images are CSS (background images), visually inspect when CSS is disabled to ensure that no meaningful element is removed from the content

For content delivered as an HTML img element, examine the result and follow this decision tree. For each element of type img:

  • Is there an attribute of type alt?
    • No: Item fails, this check is complete.
    • Yes: Continue on
  • Is the image purely decorative?
    • No: Continue on
    • Yes: Verify that alt="". Test complete
  • Is image the only content of a link or form control?
    • No: Continue on
    • Yes: Verify that the alt attribute clearly communicates the destination of the link or action taken.
  • Is image link also present as link text nearby?
    • No: Continue on
    • Yes: ensure that image and text are both within one anchor tag and that alt="". Test complete.
  • Does image contain text?
    • No: Continue on
    • Yes: Is image text also available as real text nearby?
      • No: Verify that the alt attribute echoes the onscreen text exactly. Test complete.
      • Yes: Verify that alt="" Test complete.
  • Does the image contribute meaning to the current page or context?
  • No: Continue on
  • Yes: Is image a simple graphic or photo?
    • Yes: Verify that alt=“brief description of image meaning”. Also verify that brief description does NOT contain words like photo, image, picture, graphic, etc, unless intrinsic to the meaning. Test complete.
    • No: Is image visually complex (for example, a graph, chart, or other image of complex meaning)?
      • Yes: Verify that alt=“brief description” AND that there is also an explanation of the full information as a caption, a data table, a long description, or a paragraph positioned off screen that provides equivalent meaning. Test complete.



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

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 [mostly drafted]

EOWG notes - importance: HIGH; 5 min?: 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.

What To Do

  • Click in the address bar, then put your mouse aside and don't use it.
  • Press the 'tab' key to move around the page.

(see also Forms)

(see also Visible Focus)

What To Look For

  • Can you tab to all the elements, including links, form fields, buttons, and media player controls? 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 tab into a control but not out? (called a "keyboard trap")?
  • Does the order that items get focus make sense to sighted users? (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)
  • 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.)



  • Mac browsers by default only tab through forms, will need to turn on...
  • not work easily in Opera...
  • ...

Visible focus [mostly drafted]

NOTE: Should this be merged with the section above?

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

Use keyboard only navigation to ensure that a user who relies on the keyboard will be able to know which element among multiple elements has the keyboard focus. This is an important element in facilitating success for keyboard users to operate the page, by letting them visually determine the component on which keyboard operations will interact at any point in time. People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located.

What to do

  1. Use the keyboard to set the focus to all focusable elements on the page.

What to look for

  1. Visually examine progress through elements and verify that the focus indicator is visible.
  2. Common failures occur when the default focus indicator is turned off in CSS or when the element is styled with borders that occlude the focus indicator.
  3. Verify that any visual changes that occur with mouse hover also are triggered with keyboard focus


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.)

What to do

  1. Look at the browser's window title bar.
  2. Look at titles of other pages within the site.

What to look for

  • Verify that the title indicates the specific page and website and distinguishes the current page from others in the set of pages.
  • Make sure that every page in the site does not have the same title.
  • Check that the specific page title is listed BEFORE the name of the website. (for example, About Us - Our Long Web Site Name)



  • 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 [Suzette is drafting]

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

Check color contrast [Wayne is drafting]

Check color coding [open for drafting]

Content order [open for drafting]

Video, Sound, (multimedia) [partly drafted]

EOWG notes - importance: high/medium/low; 5min?: some/yes/no/.is this appropriate for the short list at the top?).

What to do

  1. Play the audio content
  2. Play the video content
  3. Toggle closed captions on (if available)
  4. Toggle audio description on (if available)

What to look for

  • Captions:
    • Verify that they synchronized to the spoken content
    • Ensure they are accurate and complete (not missing any content)?
    • Verify that they are properly formed? (correct spelling, sentence structure, punctuation)
    • Make sure that audio content other than dialogue is inlcuded (music, relevant ambient sounds, etc)
  • Audio Description
    • (Judgement call) Watch the video content to verify that audio description is needed for complete understanding.
    • If needed, verify that they are provided in a separate track that can be toggled on and that they provide context for those who do not see the video.
  • Transcript: As a fall-back when captions and audio descriptions are not provided, check to see if there is text-based content that contains dialogue, any other audio content, and any necessary description of video content. Check for spelling and accuracy.

(see also keyboard access for player controls)

(see also text alternatives for graphic content)



[can be internal notes for now or maybe will be included in final doc]

  • ...

Forms [Sharron is drafting]

EOWG notes - importance: high/medium/low; 5min?: some/yes/no/.is this appropriate for the short list at the top?).

One or two sentences on what this is and why it is important — ideally wording directly from the Accessibility Requirements page or Understanding WCAG 2.0.

What to do

  1. steps to check the item

What to look for

  • What *should* happen.
  • What are common failures occur when ... list or narrative, as appropriate



[can be internal notes for now or maybe will be included in final doc]

  • ...

Tables [open for drafting]


Check flickering, flashing, blinking [open for drafting]

WAI-ARIA [Wayne is drafting (although probably not including this one)]

(note: not a requirement for accessibility and WAI-ARIA is not finalized yet, so probably won't include WAI-ARIA in the 15 minute check)

Time-dependent responses [probably not including this one]

Window resize [probably not including this one]

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

Validate HTML & CSS [probably not including this one]

Note: Validation not WCAG requirement...

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

Check usable without CSS, javascript [Wayne is drafting (though maybe not including this one)]

NOTE: Shadi notes this is not a WCAG requirement

NOTE: Wayne notes this is a technique for finding WCAG compliance problems (not that it is a requirement itself)

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

Reasonable display without style is a US Section 508 requirement, and is a significant weakening of accessibility in WCAG 2.0. I think this needs to be discussed. Most pages than cannot pass this, cannot pass SC 1.4.4 (Resize Text). Also, pages that pass this pass SC 1.4.4 . The user applies no style, then enlarges at will. I will cover this. Wayne

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.