Best Practices for Conducting an Accessibility Review

At the July 2017 joint meetup of the &UX Chicago and Chicago Digital Accessibility and Inclusive Design groups, Joe Welinske, accessibility specialist at Blink UX, presented a case study of their accessibility review of the new VeriCite product.

Welinske explained their review method, issues encountered during the review, and how they conveyed the results to their client.

Here are my notes:

• First step in conducting an accessibility review is to identify the Web Content Accessibility Guidelines (WCAG) 2.0 level of compliance: Level A, Level AA, or Level AAA.
• In their review of the new VeriCite product, their team created a script which listed all the use case scenarios. Those scenarios were tested with keyboard navigation and screen readers.
• Navigating a web page using only the keyboard (no mouse) can quickly reveal accessibility issues
• Two free screen readers to use for testing are NonVisual Desktop Access (NVDA) for Windows and VoiceOver for iOS
• In addition, they also used the free Web Accessibility Versatile Evaluator (WAVE) online tool, which identifies accessibility issues on a page
• WAVE is available online, as well as a Firefox add-on and Chrome extension
• To use WAVE, your page needs to be on a public-facing server, which can be an issue if you’re working on a site or product under development
• Color is a common cause of accessibility issues on sites, due to not considering color blindness, using color alone as an indicator, or lack of color contrast in designs.
  

  Not surprised to learn about color problem found during testing, common accessibility issue. #a11ychi

  — DeborahEdwards-Onoro (@redcrew) August 2, 2017

• The same accessibility issue may appear multiple times in your testing. Once you resolve the issue, do a global replace, and move forward with other issues in your report.
• Findings were reported in a Word document. Each finding had their own style, which could be searched.
• There’s nothing better than video recordings to show stakeholders the accessibility issues discovered during an accessibility review
• Build up your library of solutions for accessibility issues. Problems can crop up repeatedly in projects.
• Welinske explained that 10 percent of their review time was spent analyzing the system to see if tools were appropriate; 50 percent of time was spent on keyboard and screen reader testing

Photo credit: Dennis Deacon