The following procedure for testing a website for accessibility is suitable for most standard websites
Before you start make sure that you have the following available
- Notepad and paper to record location of any errors found
- List of all the pages on your site (this could be a print out of your site map)
- Accessibility issue checksheet (copy available to download)
- Internet Explorer (version 6 or better) with audio facilities (i.e speakers switched on)
- Firefox (version 3 or better) with the following additional toolbars
- Accessibility Extension 22.214.171.124 toolbar (https://addons.mozilla.org/en-US/firefox/addon/accessibility-evaluation-toolb/)
- Colour Contrast Analyser (http://www.checkmycolours.com/)
- A screen mask (piece of A4 card with a hole approximately 10 cm ( 4 inches) square.
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.
- Is the style consistent
- Is the navigation system consistent
- As you tab through the page can you see where the focus is (i.e. which link is being selected)
- 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)
- Is the page main heading appropriate (heading level 1) and does it match the page title as shown in the top status bar
- Will the first few lines on the page tell a first time visitor what the page is about
- Are there any flashing images or distracting flickering issues with the page
- 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 ?
- If a page contains any pop-up windows, are you warned and can you close the pop-up window easily
- 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
Open 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
- Validate HTML
- Validate CSS ( needs to be done once only for each different style sheet)
- Check the semantics of the headings
- Check the semantics of navigation bars
- Check meaning of the link text
- If the page uses data tables, forms or frames check these
- View the page with authors CSS disabled
- View the page in high contrast
- Use the colour analysers to test for colour contrast
- Check that alternatives are available for scripts
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.
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
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
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
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
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
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 .
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.