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 link text)
(Check keyboard access and visual focus)
Line 135: Line 135:
 
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:
 
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:
 
* [http://www.w3.org/WAI/intro/people-use-web/principles#keyboard Functionality is available from a keyboard]
 
* [http://www.w3.org/WAI/intro/people-use-web/principles#keyboard Functionality is available from a keyboard]
 +
* [http://www.w3.org/WAI/users/browsing#keyboard Browsing the Web by Keyboard] section in [http://www.w3.org/WAI/users/browsing Better Web Browsing: Tips for Customizing Your Computer]
 
* [BAD example]
 
* [BAD example]
  
Line 145: Line 146:
 
** Check {@@explain better}drop-down automatically goes to new page & can't do to other than first item
 
** Check {@@explain better}drop-down automatically goes to new page & can't do to other than first item
 
''(see also Forms)''
 
''(see also Forms)''
 +
 +
<span style="color:#808080;">{Alternative instructions - Andrew}</span>
 +
* Click in the address bar, then put your mouse aside - press the 'tab' key to move around the page
 +
** Does the order that items (links and forms) get focus make sense? (e.g you don't move around the page out of expected order)
 +
** Can you 'tab' to all the expected elements?
 +
** 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? (i.e. is the focus clearly visible - all the time)
 +
** If you're on a page with a form:
 +
*** Does the 'tab' order match the logical form structure?
 +
*** If you 'tab' into a 'drop-down' box, can you use the down/up arrow keys to move through the options? And can you then 'tab' to the following item?
  
 
Notes:
 
Notes:

Revision as of 13:58, 9 November 2012

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

Note:

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

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.

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

Check text descriptions for images

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:

Notes:

  • 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, www.w3.org) 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...

More

(See also Video & Sound below.)

Check headings and other semantic structure

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., www.w3.org).
    • 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 usable without CSS, javascript

NOTE: saz not WCAG requirement

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

Check keyboard access and visual focus

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:

Checks

  • Tab through the page (no mouse)
    • check that you can access all functionality -- including tab order get to all controls, actions aren't only available on hover
    • check focus order makes sense (e.g., doesn't jump around the page out of order)
    • check that the tab order doesn't get stuck ("keyboard trap")
    • check that the focus is clearly visible (also that the tab focus doesn't disappear off screen)
    • Check {@@explain better}drop-down automatically goes to new page & can't do to other than first item

(see also Forms)

{Alternative instructions - Andrew}

  • Click in the address bar, then put your mouse aside - press the 'tab' key to move around the page
    • Does the order that items (links and forms) get focus make sense? (e.g you don't move around the page out of expected order)
    • Can you 'tab' to all the expected elements?
    • 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? (i.e. is the focus clearly visible - all the time)
    • If you're on a page with a form:
      • Does the 'tab' order match the logical form structure?
      • If you 'tab' into a 'drop-down' box, can you use the down/up arrow keys to move through the options? And can you then 'tab' to the following item?

Notes:

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

Check the page title

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:

Checks

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

Note:

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

Check link text

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.

Notes:

  • 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

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

Check color contrast

Check color coding

Content order

Visual focus

Use an evaluation tool

  • 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}

Video, Sound, (multimedia)

alt...

Validate HTML & CSS

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

Forms

...

Tables

...

Check flickering, flashing, blinking

WAI-ARIA

(note: not a requirement for accessibility)

Window resize

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

time-dependent responses



More Thorough Evaluation

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

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 the WAI-Engage wiki where people can easily add other tools.