Website accessibility testing

• What to test
• When to test
• How to test
• Tools for developers

Creating accessible websites and applications is a priority for ASU.  One of the most effective things you can do to improve the accessibility of your websites and applications is to introduce a mandatory QA stage in your and your team's development processes to catch—and fix!—problems before going live.

At ASU, all new and redesigned web-based applications and sites must comply with the Web Content Accessibility Guidelines (WCAG) 2.1, level AA. See the Guides for more on how to comply with specific WCAG requirements.

What to test

When auditing a website or application for accessibility, you don't need to test every page or screen. Usually, you will evaluate:

• the landing page
• one representative interior page
• any page that contains an unusual feature, functionality or layout
• the most popular pages (based on analytics)
• pages with known issues or lots of Javascript
   

When to test

Plan to test websites and apps once a year. In addition, test affected pages after redesigns and content or functionality changes.

Setting up your website or app to be continuously monitored by a scanning service like Siteimprove can offer a good indication of how accessible it is—and when it might be time to perform more stringent testing.

How to test

Evaluating websites and applications for accessibility involves multiple levels of testing. Follow the steps below. You may also find this online 1-hour web testing workshop helpful.

1. Automatic scanning with browser extensions

Automated testing tools such as the WAVE and Siteimprove browser extensions can give a rough idea of the overall accessibility of a site or application and are a valuable first step in accessibility evaluations. However, automated tools can identify only 20-30% of accessibility issues and shouldn't be relied upon alone.

In addition to the two listed above, many other accessibility browser extensions and tools exist.

2. Manual testing and checklists

The most accurate accessibility evaluations use a combination of automated and manual testing. The ASU Web Accessibility Audit walks you step-by-step through an accessibility audit and covers many of the basics, including keyboard-only access.

Many other good checklists are available on the web, such as WebAIM's WCAG 2 Checklist, The A11Y Project Checklist, and the W3C's WCAG-EM Report Tool.

3. Screen reader testing

Testing with assistive technologies such as screen readers is standard practice in full accessibility evaluations. Testing with assistive technology can identify barriers that other tests are incapable of finding. It is particularly useful when people with disabilities are included.

The desktop screen readers used most often in testing are JAWS or NVDA. VoiceOver also is frequently used, particularly with responsive sites and mobile applications.

• JAWS (Windows): used by 40.5% of desktop screen reader users. Free for ASU faculty and staff. (sign in with your @asu.edu email). Pairs best with Chrome, Edge and Firefox (in order of prevalence).
• NVDA (Windows): used by 37.7% of desktop screen reader users. Free. Pairs best with Chrome, Firefox, Chrome and Edge (in order of prevalence).
• VoiceOver (macOS, iOS): used by 9.7% of desktop screen reader users. Preinstalled on Mac and Apple devices. Pairs best with Safari and Chrome (in order of prevalence). Widely used in mobile iOS with Safari (70.6% of all mobile users).

(Screen reader data from the WebAIM Screen Reader User Survey #10 Results.)

4. Expert review

Some third-party suppliers can evaluate websites and applications for accessibility and even remediate issues. Contact the ASU IT Accessibility team for help finding reputable vendors.

The ET UX Research team offers user testing that includes people with disabilities. Their services help improve user experiences through the analysis of real users interacting with products.
 

Tools for developers

In addition to the tools described above, developers need special tools that they can rely on during development. Some of the best include:

• The accessibility features in Chrome DevTools
• WebAIM Color Contrast Checker
• Paul J. Adam's Bookmarklets for Accessibility Testing
• W3C Nu Markup Validation Service, especially with WCAG Parsing Bookmarklet