Testing Accessibility for keyboard users

The web was originally designed for use without a mouse. Many disabled users cannot use a mouse and so still rely upon the keyboard for navigating a web-site.

This is probably the easiest test to do. Simply push your mouse out of reach and try to navigate your site using just the keyboard. A list of typical keyboard functions is given at the end of this page.

  1. Check that you can see each link as it is in focus. A common mistake is to use the CSS a:hover element for "roll-over" buttons without including duplicate styles for a:active and a:focus.
  2. Check that you can navigate the site map easily, Keyboard users make more use of the site map than mouse users.
  3. Check that any forms work with teh keyboard. Check that field selection is logical as you work through the form and that the "Submit" button works.
  4. If you use scripts on a page check that they work with a keyboard. A common mistake is to use OnMouseOver and OnMouseOut without corresponding keyboard commands (OnFocus & OnBlur)

 

Use the Keyboard to Navigate Screens

Use these common keyboard commands to navigate web pages without a mouse. Some keystrokes may not work with every Internet browser.

IF you want to...THEN select
Move forward from link to link or to controls Tab
Move backward from link to link or to controls Shift + Tab
Select buttons Spacebar
Navigate and select Radio Buttons Arrow
Select/deselect boxes Spacebar
Move from box to box Tab
Open a List Box ALT + Down arrow
Read the prior screen CTRL + Page Up
Read the next screen CTRL + Page Down
Go to the top of the page CTRL + Home
Go to the bottom of the page CTRL + End
Close the current window (in Internet Explorer) CTRL + W
Refresh the screen F5
Go back a page ALT + Left Arrow
Go forward a page ALT + Right Arrow
Navigate to & select teh text in the address combo box ALT + D

Using Hotkeys Or Access Keys

Most applications contain hotkeys to improve navigation and provide information. On many screens there is a continue button that allows you to go to the next page or a previous button to return to the prior page.

Other keyboard commands, hotkeys or access keys will vary based upon your type and version of browser.

You will find a list of these commands in the Help section of your browser. Locate the Help feature on the Menu bar of your browser or by using your keyboard F1 function key.

Use these common keyboard commands to navigate web pages without a mouse. Some keystrokes may not work with every Internet browser.

Testing web sites for compliance with accessibility guidelines

Aim

This lesson explains the techniques and tools available to help you deliver an accessible web site. It stresses the need for human involvement in the testing process. For accessibility testing the best method is to ask a wide range of disabled people to check the site for you. But before you do there are some tests you can do yourself to remove the majority of errors.

The testing Process

Before starting to test a site for accessibility it is important to have a clearly defined process to follow, otherwise it is easy to get side-tracked on some minor issue and fail to notice something far more important. The first thing to do is to devise a checklist of potential accessibility problems to test against. The W3C has issued a comprehensive list of potential barriers to accessibility together with detailed guidelines for how to avoid them. We shall look at this list in greater detail in the next lesson (and provide a sample checklist to use). The next decision is whether to test the site page by page (looking at each page for any accessibility barriers) or issue by issue (looking at the site as a whole to check that different types of user can access all your content). The second approach is preferable because it enables you to check that the complete site works and makes sense to any user. We provide a process for conducting a thorough test of a web site using this technique in section 2 of this lesson

 

Some simple initial tests

The following three tests do not need any special equipment or skill. They are easy to carry out and will give you a quick idea of how accessible (or not) your site is.

Test 1 - Navigating with the Tab key

 

<br > Many disabled people cannot use the mouse, ether because they cannot see the mouse cursor on the screen or because they do not have the motor control to position the cursor accurately. To test for this barrier try to explore your web site without using your mouse. Put your mouse well out of reach so that you are not tempted to cheat! <br >

Image of a tab key To navigate without a mouse you press the Tab key on the left of your keyboard. Each time you press the Tab key you select the next navigation button or hyperlink on the page. (Use the Shift key + the Tab key to go back to a previous link). When you are on the required button or hyperlink just press the Enter key to go to the new page. The "Back Delete" button returns you to the previous page. The "Page Up" and "Page Down" buttons scroll the whole page up or down one screen-full at a time. The up and down cursor keys scroll the page more slowly. In select (option) boxes the up and down cursor keys allow you to select the required option.

If you find that your site is impossible to navigate without using a mouse then your site is not accessible to many disabled people.

<hr >

Test 2 - Alternative text for images.

Visually impaired users may not be able to see the images - but they still need to know what the picture was about. This is done by including an alternative piece of text that shows up if the image does not arrive, or if the user holds the mouse cursor over the image for a moment. This is called the "alternative text tag" or the "Alt Tag".

Image with cursor over to show the alternative text tagThe picture on the left shows how the alternative text tag is displayed as you rest your cursor for a second over the image. 

Use your mouse to rest the cursor on the images on your web site. Check that the alternative text is relevant to the purpose of the image. Some Netscape based browsers (such as Firefox) don't always display the alt tag when the cursor rests on the image (they seem to prefer the "title" attribute). If you are using Firefox to test your site you may need to right click on the image to view its properties. Fortunately an accessibility checking toolbar is available for Firefox and we shall explore this later when we cover manual testing.

<hr >

Test 3 - Large text option

Image showing how to use the View menu to change text size

People with poor eyesight may need to adjust the size of the text on your web sites.

To check if people can change your text size, select the View menu in your browser toolbar, from the pull-down list select Text Size and click on the Largest option.

If your pages have been written using the proper html codes you should see the text and links on your page written in a larger font size. This means that you have used proportional font sizes - well done.

If the text size remains the same then you have used fixed, or absolute, font sizes and people with weak vision may not be able to read your content. This includes most older people !


Robot tests

There are a number of automated checking programmes available that will check the machine readable code of your web pages. Whilst these tools will tell you if your code is "robust" or "semantically structured" they will not tell you if your pages make sense to a human being. However, if they are used carefully, some of these tools can save considerable time and effort in checking your web site.

VALIDATING XHTML, HTML & CSS CODE

It is possible to check automatically that the X/HTML and CSS code uses valid syntax. There are a number of services available but the most popular are :

  • http://validator.w3.org/ - to check your HTML code
  • http://jigsaw.w3.org/css-validator/ - to check your CSS code

Health Warning – The above tools only check if the code uses the correct syntax. They do not check if the results are what you expect from your code. For example, the following CSS code is valid -
body { display:none}
but the result would be an invisible web page !

Furthermore these tools will not check if you have used the most efficient code. For example, both versions of a navigation bar shown below are valid and produce the same visual effect. Guess which one is most efficient and therefore easier to maintain.

<ul class="mainMenu">
<li><a href="/../index.htm">Home page</a></li>
<li><a href="/../solutions.htm">Our Services</a></li>
<li><a href="/../library.htm" >Our Library</a></li>
<li><a href="/../company.htm" >Our Details</a></li>
<li><a href="/../siteindex.htm" >Site Map</a></li>
</ul>
<ul >
<li class="mainMenu"><a href="/../index.htm">Home page</a></li>
<li class="mainMenu"><a href="/../solutions.htm" >Our Services</a></li>
<li class="mainMenu"><a href="/../library.htm">Our Library</a></li>
<li class="mainMenu"><a href="/../company.htm">Our Details</a></li>
<li class="mainMenu"><a href="/../siteindex.htm">Site Map</a></li>
</ul>

Once you are happy that the basic HTML and CSS code is correct you can go on to test for general accessibility

Accessibility robots

There are a number of tools available that claim to automatically test your web site for accessibility. Unfortunately, as these are robots, they can only test for issues that are "machine readable". They cannot tell if your content actually makes sense, or if the text is meaningful. However, if used with care, they can provide quick indications of where some problems may be occurring.

Many robots only conduct tests on one page at a time but a useful tool that can cope with a complete web site (or sections of a site) is the Functional Accessibility Evaluator provided by the University of Illinois. (http://fae.cita.uiuc.edu/ )

Using the W3C Accessibility Guidelines

The W3C Accessibility Initiative (WAI) has produced a set of guidelines for creating accessible web sites. The latest version (version 2) was published in December 2008 and is considered to be the the standard for accessibility by governments and compliance with discrimination legislation. We shall look at these guidelines in more detail in lesson 13 where we will also link each guideline to the relevant part of this course. We shall also provide a checklist that you can print out and "tick off" each guideline as you check through your site.

If you can't wait until then you can have a look at the requirements at the official web site http://www.w3.org/WAI/WCAG20/quickref/Overview.php

 

Using real people

The purpose of your web site is to communicate with people, so asking real people to check your web site is the most logical solution to testing for accessibility and usability.

Try to ask people who have not been involved in the web site design to undertake some specific tasks using the site.

  1. Ask at least one person to do the tasks using a text-only browser such as Lynx.
  2. Ask another person to do the tasks without using a mouse.
  3. Ask another person to do the tasks with the style sheet option disabled.

The above three tests should show you if you have any serious barriers to accessibility. Once you are happy with this level of accessibility the next test is to ask a blind person who uses a screen reader to check that they can also perform the tasks required.

Independent evaluation

The safest way to be sure that your web site is accessible is to ask an expert to evaluate it for you. There are a number of organisations around that offer this service (including us at Userite). When choosing a company to check your site make sure that they include testing with disabled people because they will often find issues that are not picked up by "experts" or the W3C guidelines. It is also, probably, worth avoiding companies that offer to rebuild your site for you, you will never learn to maintain the site properly if you don't understand the practicality of accessibility by doing it yourself.

 

Checklist for test 1 (Internet Explorer)

Using just the keyboard controls check the following on every page:

  1. Is the style consistent
  2. Is the navigation system consistent
  3. As you tab through the page can you see where the focus is
  4. Can you tab into the main content area reasonably easily
  5. Does the page heading <h1> reflect the page content
  6. Will the first few lines on the page tell a first time visitor what the page is about
  7. Are there any flashing images or distracting flickering issues with the page
  8. If the page contains a form
  9. can you tab through the form entering data in a logical path ?
  10. can you submit the form if important fields are left empty ?
  11. do you get helpful feedback and can you make corrections easily ?
  12. If a page contains any pop-up windows,
  13. are you warned
  14. can you close the pop-up window easily
  15. Are there any automatic background sounds
  16. Can users control the sounds

Checklist for test 2 (Firefox with add-ons)

Using Firefox with the accessibility toolbar (and your mouse) check the following

  1. Is the HTML code valid
  2. Is the CSS code valid
  3. Does the page title match the page heading
  4. Are sub-heading sequential and meaningful
  5. Do navigation bars have headings
  6. Are text links in navigation bars meaningful
  7. Do all the links on the page have meaningful link text
  8. If the page is a form do the controls have labels
  9. If the page contains a data table
    1. Does the table have a title
    2. Does the table have a summary
    3. Are row and column headings coded with <th>
  10. Can you navigate through the headers
  11. If the page uses frames, are they titled
  12. Is the page useable in High contrast
  13. Is the page useable without CSS
  14. Is the colour contrast adequate for all elements on the page
  15. Do the pages still work when the stylesheet is disabled
  16. Do the pages still work when scripting is disabled

 

The following procedure for testing a website for accessibility is suitable for most standard websites

Tools required

Before you start make sure that you have the following available

  1. Notepad and paper to record location of any errors found
  2. List of all the pages on your site (this could be a print out of your site map)
  3. Accessibility issue checksheet (copy available to download)
  4. Internet Explorer (version 6 or better) with audio facilities (i.e speakers switched on)
  5. Firefox (version 3 or better) with the following additional toolbars
    1. Accessibility Extension 1.4.5.0 toolbar (https://addons.mozilla.org/en-US/firefox/addon/accessibility-evaluation-toolb/)
    2. Colour Contrast Analyser (http://www.checkmycolours.com/)
  6. A screen mask (piece of A4 card with a hole approximately 10 cm ( 4 inches) square.

Basic checks

The following test checks the most common errors found on standard websites. This test checks that every page of the website is accessible regardless of which sort of pointing device or assistive software the visitor is using. If the visitor cannot get to a page then all other accessibility issues are irrelevant.

Because we are going to look at every page on the website we will combine this test with other checks that can be done visually. This test can take some time, it gets faster as you get into a routine. You should allow at least one minute per page for a small/medium site (less than 100 pages), for larger sites you should get it down to an average of about 30 seconds per page. However, if you find any errors you will need to spend extra time thinking about how you might make the appropriate corrections. Whether you make corrections "as you go" or save them up until the end is a matter of personal choice, however functional errors such as keyboard traps are probably best dealt with as they arise.

Keyboard functionality, usability, page title, distractions, pop-up windows, and background audio

Open Internet Explorer, go to your home page and put your mouse out of reach.

Using the keyboard only navigate around the site using your site map or list of pages to make sure that you visit every page. When each page opens check the following before moving on.

  1. Is the style consistent
  2. Is the navigation system consistent
  3. As you tab through the page can you see where the focus is (i.e. which link is being selected)
  4. Can you tab into the main content area reasonably easily (e.g tabing through only a few navigation links, or by using a visible "skip links" option)
  5. Is the page main heading appropriate (heading level 1) and does it match the page title as shown in the top status bar
  6. Will the first few lines on the page tell a first time visitor what the page is about
  7. Are there any flashing images or distracting flickering issues with the page
  8. If the page contains a form
    • can you tab through the form entering data in a logical path ?
    • can you submit the form if important fields are left empty ?
    • do you get helpful feedback and can you make corrections easily ?
  9. If a page contains any pop-up windows, are you warned and can you close the pop-up window easily
  10. Are there any automatic background sounds

If you passed all the above you will be confident that visitors can actually access all your pages and you will have a clear idea of the website content and structure.

Structural and styling tests

For this set of tests you should only need to select your important pages and a representative sample of supporting pages. Errors found in the templates or stylesheets will be common to many other pages so only need to be checked a few times.

Code validation, Semantic structure, link text, Forms, Data tables, Frames, Styles, colour contrast

Accessibility Pull-down  MenuOpen Firefox and visit a representative sample of pages including all section home pages, forms, pages with data tables and the site map. On each page we shall use the accessibility tool bar (shown opposite) to perform the following tests

  1. Validate HTML
  2. Validate CSS ( needs to be done once only for each different style sheet)
  3. Check the semantics of the headings
  4. Check the semantics of navigation bars
  5. Check meaning of the link text
  6. If the page uses data tables, forms or frames check these
  7. View the page with authors CSS disabled
  8. View the page in high contrast
  9. Use the colour analysers to test for colour contrast
  10. Check that alternatives are available for scripts

Validate HTML

Selecting the validation tool

From the Validator menu select W3C HTML Validator. The tool bar will submit the current page to the validator and return a new page with the results. If the page contains any errors in the code these will be identified and suggestions made for correction. Sometimes you may see a long list of errors that are caused by the cascading effect of not closing one element correctly. If you do have a long report it is worth only correcting the first few errors and then revalidating the page. If you run a website where different authors are allowed to enter content into templates make sure that you check at least one page per author. If authors are inserting invalid code you may need to run some training programmes.

Validate CSS

From the Validator menu select W3C CSS Validator. The tool bar will submit the current page to the validator and return a new page with the results. Stylesheet errors do not normally cascade, so you should work through the sheet correcting each error as reported by the validator. Because the same stylesheet is used for many pages you need only check each sheet once.

Check that the page title and top level headings match

Comparing the page title to the page heading

From the Navigation menu select the Title option. A pop-up window will appear that tries to compare the page title in the <head> section with the first top level heading it finds. In the example opposite the response suggests that these do not match because we have used two different words that have similar meaning (Procedure and Method). This is not a fatal error so we have to make a value judgement about whether to accept or ignore this warning. In this case we shall accept the suggestion and, for the sake of consistency, change the H1 heading to use the word Procedure.

Check the semantic structure of headings

Structured list of headings

From the Navigation menu select Headings. A pop-up window will list the headings in the order that they are written in HTML. read through the headins as listed and check that they are in sequential order. In particular check that any headings at one level actually relate to the previous level of heading. Also check that you do not skip any levels (i.e jump straight from level 2 to level 4).

Read through the text of the headings as presented in the window and confirm that they do present a reasonable overview of the page content. A blind user relies on this list of headings to scan the page before delving into the main content. Assistive software allows them to click on any of the headings and be taken straight to the relevant section

Check the semantics of navigation bars

Details of any available navigation bars

From the Navigation menu select Menu and Navigation Bars. A pop-up window will try to identify and navigation bars and list their content. Check that this meets your expectation. In particular chack that each bar has a heading and that the text of each link actually tells the user what will happen if the link is selected.

Not that our example navigation bar, shown opposite, has used the title attribute for the links on the navigation bar to provide more meaningful text. Most screen readers will present the title attribute if it is available. However some older screen readers do not recognise the title attribute and will only read out the actual links text (Home, Solutions, Certification etc.). Therefore do not rely solely on the title attribute, make sure that the actual link text is at least relevant to the target of the link.

Check the link text

List of links on a page

From the navigation menu select Links. A pop-up window will open listing the links on the page together with the relevant Link Text. Read down through the list to make sure that each of these Link Texts makes sense as stand-alone items. For example, avoid phrases such as "click here" and "more info.." as these are meaningless when listed out of context. Make sure that any links to non-HTML pages warn the user by including the file type and size within the link text.

If you have more than 50 links on a page you should ask if these are all necessary.

Checking forms, data tables and frames

If the current page contains a forrm or a data table, or if it uses frames for layout, check these by selecting the appropriate option from the Navigation menu. Each option produces a pop-up window that tries to identify any accessibility errors. Remember that these are automated tools, not human beings, so you need to interpret the results with care. For example the tool for checking frames will list the frame titles for you, but you need to decide if these titles are relevant (i.e. accurate desriptions of the frame content)

Checking high contrast and large font

Using the style menu

From the style option select high contrast (B/W) . The current page will now be displayed using a high contrats colour scheme with large font. Check that the page is useable with this setting.

Note that the style option menu includes a colour contrast tool that provides a mathematical report on the contrast in luminosity between each foregound and background colour. In the current version of the toolbar (1.4.5) this is a very basic tool. The Colour Contrast Analyser provides more detailed responses.

Check that the page works without CSS

From the Accessibility menu select the style option and remove the tick from beside Author CSS. You may need to refresh the page to see the effect of this. Check that the page is still useable without using a style sheet.

Checking Colour Contrast

From the Tools menu select Colour Contrast Analyser . Select the "all tests" option. A new window will open with the results. Failing contrasts are highlighted in yellow .

 

Checking that the page works with javascript disabled

Turn off scripting

If you have used any scripts on your website you can check that the site still works without scripts by simply disabling scripting in the Scripting option menu of the Accessibility tool bar. If there are any interactive elements on a page check that these work.

 

 

User Panel Testing

Once you have done all the tests above it is time to ask some real users to test the site for you. Find some willing volunteers and ask them to give you an honest opinion of the overall look and feel of the site. Next ask them to perform some specific tasks such as finding information or completing a form. Try to find people who have a similar level of education and language as your target audience so that you get a genuine idea of how well your site will work in the real world.