Web Key IT’s 16 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.

Image of the 15 steps

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: Checking alternative text with WAT
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)
Step 16: Mobile Considerations


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:

  • Web Accessibility Toolbar (WAT) download from http://paciellogroup.com/resources/wat/ie
    • Ensure the toolbar is enabled: If necessary, enable the toolbar: Settings>Manage Add ons>Web Accessibility Toolbar>Enable

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?

Screenshot of NVDA's Elements list

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: Checking alternative text with WAT

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

Screenshot of the WAT toolbar with Show Images highlighted

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

  • 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.
  • Tables should be used for data only, and not for layout or display purposes

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

Screenshot of the WAT toolbar with List Links highlighted

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 | Example Company

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

Screenshot of process for validating code

Step 14: Using the WAVE Chrome Extension

  • The WAVE Chrome extension provides a mechanism for running WAVE reports directly within Google Chrome. 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.
  • WAVE gives a summary of errors, warnings, features, structural elements and ARIA. The second tab provides details of each of the items in the summary. The Reference tab, explains what each item is, why it matters and how to fix it. An annotated version of the code is also provided.
  • 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.

Screenshot of the WAVE tool

 

Step 15: Using the Colour Contrast Analyzer (CCA)

  • With the page of the website to be checked open, open CCA Select the foreground colour picker and position it over the foreground colour. Then select the background colour picker and position it over the background colour.
  • 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
      • Large text is considered to be 24 px and over or 19 px bold and over. This definition of normal and large are defined within WCAG and are fixed requirements.
  • Use of colour can also be tested with the CCA
    • If colour alone is used to portray information, a contrast of at least 3:1 is required.
  • Informative icons, user interface components, borders for input fields, graphical objects all require a contrast of at least 3:1 with the background

Screenshot of Colour Contrast Analyzer with arrows point to grading areas and colour picker

 

Step 16: Mobile Considerations

Open the website/app on a mobile device

  • Check both Portrait and Landscape view to ensure the websites content is still available and usable regardless of which way the device is being held
  • Check that the website is mobile responsive, reflowing into a single column so the user is not required to pinch to zoom and swipe horizontally to see all the content
  • If the website or app is using motion detection, check these types of enhancements have an alternative to the action (such as a button) and the ability to turn the enhancement off.

 

 

 

 

 

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