Phone: +61 (08) 9206 3987

Mobile: +61 0415 383 673

Search Website

Web Key IT’s 15 Steps

Manual and Automated testing each come with their own list of pros and cons. Ultimately, automated testing can be a useful tool but should always be complemented with manual testing. Performing review of a webpage with WCAG can be overwhelming for a novice. This 15-step method was created to provide an easy step by step guide using only a few open source tools including the screen reader, NVDA, the Web Accessibility Toolbar, WAVE extension and Color Contrast Analyzer.

l

The steps are:

Step 1: Keyboard Accessibility
Step 2: Video Content
Step 3: Movement and distractions on the page
Step 4: Navigating the page with a screen reader
Step 5: Form completion and errors
Step 6: Listening to the page with the screen reader
Step 7: Using the screen reader to listen to interactive elements
Step 8: Using the Web Accessibility Toolbar (WAT) with Internet Explorer
Step 9: Checking heading structure with WAT.
Step 10: Checking tables with WAT
Step 11: Checking Links with WAT
Step 12: Check page titles with WAT
Step 13: Validating code using WAT
Step 14: Using the WAVE Chrome Extension
Step 15: Using the Colour Contrast Analyzer (CCA)


In order to follow the process the following software is recommended. All the listed software in this section are open sources and free of charge.

Browsers

Add-on for Internet Explorer:

Add-on for Google Chrome:

NVDA

Screen reader – free but will ask if you want to donate.  There is no obligation. (https://www.nvaccess.org/download/)

Colour Contrast Analyzer

http://www.paciellogroup.com/resources/contrastAnalyser (While this can be launched from the WAT in IE, it is most useful downloaded as a standalone application from Paciello (see above)

 

Step 1: Keyboard Accessibility

  • Disconnect the mouse – it is not available for use.
  • Tab through the entire page using the ‘Tab’ key.
    • Does the tab order make sense?
    • Is every item that receives focus visible?
    • When an item receives focus, is that item styled in such a way that the focus is obvious?
    • Are there any keyboard traps? A “keyboard trap” occurs when a person using a keyboard cannot move away from an interactive element/control using just the keyboard.

Step 2: Video Content

  • Are there any videos on the page?
  • Are the videos captioned?
    • Do the captions make sense?
    • Is there a transcript available?
    • Is there extended audio coverage? Extended audio describes what is happening when no words are being spoken, for example, “Bill enters the room, appearing anxious.”

Step 3: Movement and distractions on the page

  • Is there any movement which starts automatically when the page is loaded?
  • What accessibility issues do you see?
  • Would an epileptic user be able to use this site?
  • Would a dyslexic user be able to concentrate and read all the information on this site?

Step 4: Navigating the page with a screen reader

  • Open NVDA
  • Use NVDA+F7 and try navigating via the Elements List
  • Write down any issues or anomalies you find
    • Could you hear everything on the page?
    • Did it all make sense?
    • If you were a blind user would you have missed any important information?

Step 5: Form completion and errors

  • Are there any forms to complete?
  • Are the form fields properly labelled?
  • If you make a mistake (try to make at least one), do the error messages display appropriately?
  • Do the error messages rely on colour alone for you to locate them?

Step 6: Listening to the page with the screen reader

  • Go to the website page, turn on NVDA
  • Use the ‘read all’ mode (NVDA+down arrow)
    • Did you hear everything?
    • Does it make sense?

Step 7: Using the screen reader to listen to interactive elements

  • Listening to NVDA - use the ‘tab’ key to move around to all the links, buttons, input fields etc.
    • Did you hear all the interactive elements?
    • Are they labelled appropriately?
    • Was the focus order logical?

Step 8: Using the Web Accessibility Toolbar (WAT) with Internet Explorer

  • Ensure the toolbar is enabled: If necessary, enable the toolbar:
    • Settings>Manage Add ons>Web Accessibility Toolbar>Enable
  • Select – Images>Show images
    • Do all the images have alternative text?
    • Do decorative images have a null alternative text? (“alt=””)
    • Is the alternative text descriptive and correct?

Step 9: Checking heading structure with WAT

  • Select – Structure>Heading Structure
    • Shows all headings (including hidden headings) listed in a new window/tab
  • Select – Structure>Headings
    • Shows all headings in situ
  • It is best practice to have only one H1 element on a page and that all other headings are arranged hierarchically following that H1 element.
  • It is a failure to have empty heading elements, or to have what appear to be headings by appearance but which do not have semantic (HTML) markup as a heading.

Step 10: Checking tables with WAT

  • Tables should be used for data only, and not for layout or display purposes
  • Select – Tables>Show Data Tables
  • All data tables should have Table header (TH) and Table Data (TD) elements.  There should be no empty cells, rows or columns.
  • If tables have been used for layout (while not best practice), they should not have TH or TD elements.

Step 11: Checking Links with WAT

  • Doc Info>List Links○      
    • Links must clearly state the destination and use unique link names
    • Do not use generic link text (e.g. ‘Click here, ’Read More’) and make sure there are no empty links

Step 12: Check page titles with WAT

  • Doc info>metadata information
    • titles need to be unique
    • inform the user where they are in relation to other pages, not requiring the user to read the page to get this information
    • best practice note – it is recommended to place the purpose of the page in front of the organisation’s name because of how browsers truncate the title when more than one window is open e.g. use: Contact Us | Ministry of the Interior Kuwait, not Ministry of the Interior Kuwait | Contact us

Step 13: Validating code using WAT

  • Valid code for specific WCAG requirements is a Level A requirement, and does not require developer skills to check
  • Check>W3C Nu Validation Service (checks the full code validation)
  • Check>Filter Nu Validation Results (filters out the non-WCAG validation errors)
  • If there are errors remaining, the code is not valid, and this constitutes a WCAG 2.0 Level A accessibility error, and this should be referred to the developer to fix

Step 14: Using the WAVE Chrome Extension

  • The WAVE Chrome extension provides a mechanism for running WAVE reports directly within Google Chrome.
  • Because the extension report runs entirely within your web browser, no information is sent to the WAVE server. This ensures 100% private and secure accessibility reporting.
  • The toolbar can check intranet, password-protected, dynamically generated, or sensitive web pages.
  • Since the WAVE extension evaluates the rendered version of your page, locally displayed styles and dynamically-generated content from scripts or AJAX can be evaluated.
  • The figures below demonstrate the PADA home page assessed in Chrome with the WAVE toolbar check.  The figures highlight the missing form label, which means that when a screen reader user listens to that element, they would hear ‘edit blank.’ This tells the user there is a form field, but they are not told what to enter into the form field.
  • One of the best uses for the WAVE extension is reporting issues to the person responsible for making corrections.  They can see where the issue is and have a clear indication of how this affects the user.

Step 15: Using the Colour Contrast Analyzer (CCA)

  • With the page of the website to be checked open, open CCA (it should be pinned to the taskbar)
  • Select the foreground colour eyedropper and position it over the foreground colour (text)
  • Select the background colour eyedropper and position it over the background colour behind the text
  • The CCA will show the colour contrast level and the pass/fail for Level AA and AAA.
  • Results will depend on whether the text is large or normal size.
    • Normal size text requires a contrast ratio of 4.5:1 for Level AA
    • Large size text requires a contrast ratio of 3:1 for level AA
    • The definition of normal and large are defined within WCAG 2.0 and are fixed requirements
  • Use of colour can also be tested with the CCA
    • If colour is used to indicate functionality (the border of a search box, the presence of a link – if not underlined etc.), a contrast of at least 3:1 with the surrounding text or background is required.

 

 

 

 

 

This work is copyright. Apart from any use permitted under the Copyright Act 1968, no part may be reproduced by any process, nor may any other exclusive right be exercised, without the permission of Web Key IT Pty Ltd