Testing for Web Accessibility

Testing for Web Accessibility

Testing is an important and integral part of web development. With everything that we add to our websites, testing is essential during and after development. The Web and the technological devices that access it have evolved over the last 25 years, so has methods and criteria for testing.

Evolution of Testing Web Content

  • (1997) Browsers - Initially, web developers only needed to worry about how web pages presented in different web browsers.
     
  • (2009) Mobile - When mobile webpages came on the scene (thanks to the iphone), most companies ended up with two websites: a desktop (computer) website and a mobile site. Along with testing different browsers, web developers were required to also test both desktop and mobile version of websites.  
     
  • (2013) Responsive design - A few years later, responsive design was born. Responsive design allows a website to automatically conform to different devices (e.g., desktop, mobile, tablet). At the same time, browser technology began to converge (e.g., Microsoft Edge is now using Google Chrome technology). Web developers expanded their testing to include responsiveness while still testing different browsers and devices. 
     
  • (2020) Web accessibility - Now, web accessibility (and required testing) is becoming a key component in web development. Testing to ensure that user interfaces, content pages, widgets, PDFs, and videos adhere to web accessibility standards and guidelines will become standard practice.

Where To Start

Start where we are. The goal isn’t perfection, but ongoing improvement. Implementing everything at once doesn’t have to be the goal. Rather, it’s about starting with one or two specific areas and then gradually adding more as our team gets better at accessibility testing. 

  • Find the right champions to lead this initiative, people or groups in the organization that care about people and doing the right thing. 
     
  • Make sure we have meaningful accessibility statements which reflect our organization’s commitment to remove barriers to people with disabilities.
     
  • Build the champions network that allows a community of practice to grow and learn from each other.
     
  • Key publishers and developers to learn ARIA.
     
  • Educate the whole office on accessibility. Staff that work with videos, must learn about accessible videos. Staff that work with images, must learn about accessible images. Staff that work with PDFs must learn about accessible PDFs.
     

Ways to Test

  1. Test every page with a keyboard. Tab through each page. Do items/sections show up in the proper order? Can you tell where we are on the page? Do form controls work?


 

 

  1. Test with a screen reader. (Note: Usually, if a keyboard works with a website, a screen reader should work as well.) Watch this video to learn more. 

When using a screen reader, you quickly welcome governing principle, Operable guideline 2.4.1: Skip Links. 

Skip links offer a “Skip to content” button that allows users to skip all the navigation items and jump straight to the main content. 

  1. Use third-party testing tools like WAVE, aXe, and JAWS (screen reader) as well as web disability simulators.

  1. Test with real people. Enlist people with disabilities to test our site.

​Note: In large corporate environments with a dedicated budget for accessibility, assistive technology users can be hired to test functionality on the staging environment before launch.

What to Test

We recently conducted a preliminary web accessibility test on our corporate site and scored 73.6%. E-Cubed will perform another, more comprehensive accessibility test (using Siteimprove) on our site in the next few months.  

In conjunction with this comprehensive test, other features will need to be tested. Most tests will involve manual testing and can be done in-house. Other tests will require the use of third-party tools such as aXe or Wave.

Automated Accessibility Checking  (Performed by CPABC's Web Team)

We will use third-party tools such as aXe and Wave to scan our site to help find items that do not pass WCAG 2.1 AA accessibility. This type of testing is fast, but only 20-50% of barriers can be identified by this method.

Manual Overview (Performed by CPABC's Web Team)

  • Manual testing will review:
    • Images - correct alt tagging
    • Color contrast between background and text
    • Color contrast between image and text on images
    • 200% Zoom test
    • Mobile - Vertical/Horizontal test
    • HTML Symantec (h1, h2, h3, h4)
    • Responsiveness
    • Navigation links
    • Forms
    • Widgets (sliders, drop-down navigations, show/hide content toggle accordions) 
    • Tables

Assistive Technology (AT) Test

  • Keyboard testing (Performed by CPABC's Web Team)
    • Does the page follow proper headings structure?
    • Is the programmatic code structured properly so that the reading/navigation order is correct?
    • Do we get trapped anywhere on screen?
    • Can all content be accessed with the keyboard alone?
    • How do all our widgets perform?
    • Can banners and moving carousels be stopped or slowed down?
       
  • Screen reader testing (Performed by CPABC's Web Team)
    • Can the page be perceived and operated correctly using a screen reader or braille display?
    • Can the page be explored using only the arrow keys?
    • Can all interactive elements be explored using the TAB button?
       
  • Site Infrastructure testing (Performed by E-Cubed)
    • ​Skip links*
    • Widget accessibility
    • Banner motion

*A skip link provides a way for users of assistive technology (screen reader or keyboard) to skip what can often be many navigation links. For example, think about having to tab through the entire Amazon dropdown navigation, that has links nested in links, before you even reached the search bar or any relevant content—that is the problem that a skip link solves for keyboard or screen reader users.

More Testing and Development Tips

  • Encourage developers, designers, and content authors to include accessibility checks as part of their process instead of adding extra people to do QA testing.
     
  • Stop using the mouse during your regular testing. You’ll catch accessibility bugs along with other functional bugs using your keyboard. 
     
  • Browse your site with magnification set to 200% or greater using the built-in magnification tools in your browser (Ctrl + +).
     
  • Flip your browser or OS to dark mode to see if your site works well for people with light sensitivity.