Leading up to our talk at the Bristol Tech Festival, CookiesHQ is celebrating accessibility in a series of articles that addresses (and educates) accessibility in tech products.

Find more information about our event and how to attend here. 

You’ve planned to build your app accessibly, the designers have paid attention to details that matter, the developers have implemented them using accessible techniques… But how can you ensure that the work done is actually accessible to users? Read on to learn about the different methods to validate the accessibility of your product.

Recruit disabled users

The best way to check that your app or the latest feature you’re building is accessible… is to check with people that actually use assistive technologies in their day to day lives. Maybe there’s already someone in your company, or maybe you’ll need to recruit external people. But they’re in the best position to check that things are working OK with the way they use assistive tech . The earlier in the process the better (even better if you can involve them at the design stage), and of course compensate them for their time and work 😉

Tools for automated testing

Even if you’re not able to do testing with people using assistive technologies, there are still ways to check that your implementation meets a standard of accessibility. WCAG provides a set of rules to ensure a baseline level of accessibility. While some of those need to be manually reviewed, others can be tested automatically. This makes it quicker and less of a burden to detect issues.

Chrome brings an accessibility report in its Lighthouse developer tools. Deque also offers the aXe extension (Chrome, Firefox, but also Android) to automate the detection of accessibility defects on your website. This said, a perfect score doesn’t mean that your product is perfect, just like your app/site doesn’t have any errors that they can detect:

• Not all issues can be detected automatically. These tools will catch only maybe 30% of issues, leaving a few things to review manually.
• They work on the state of the page as they’re run. Click on a button, the page changes, and they will be needed to run again if you want to be completely thorough.

This said, these tools are still a very good first step. 20-30% of issues fixed is definitely better than none!

Manual testing

Because automated testing can’t catch everything, but also because it’s about human interactions, some amount of manual testing remains necessary. Two main tools that could help you are:

• Your keyboard, which will be the main input for some of your users, and is also a good way to get a similar input as assistive technology. Look to see if the focus gets given to appropriate elements or doesn’t go to places that are not visible on the screen. This allows you to get to places otherwise hidden behind hover interactions (even if it needs an intermediate action to “open” something). Also check for enter/escape/arrow keys working the way you’d expect. All in all, it’s a good habit to grow whilst developing the app. And doesn’t cost much too!
• Tab/enter/escape as you code makes things easier to fix while you’re in the feature.
• A screenreader to verify what assistive technologies will announce to users as you browse through the page or use the app’s features. If you’re on Mac you already have VoiceOver installed and ready to go. For Windows you can look at getting NVDA, which is free, and if you’re on Linux, Orca.  Android and iOS also have screenreaders, respectively TalkBack and VoiceOver. With these, you can review whether form fields are labelled appropriately, images have proper alternative text, landmarks and headings are properly accessible to assistive technologies and that links are appropriately named and don’t end up causing a 20 item long list of “Read more” in the screen reader shortcuts.

Browser developer tools and extensions can also be of help to review accessibility manually:

• Both Chrome and Firefox will show colour contrast information in their inspector.
• Firefox’s accessibility panel lets you have a look at the accessibility tree to check labelling (amongst other properties).
• Extensions like Landmarks for Firefox or Landmarks for Chrome help review which landmarks are available.
• headingsMap, for Firefox and headingsMap for Chrome, will let you check that your headings are coherent.

These are plenty of ways to review the accessibility of your site, from small steps like simply tabbing through your site to involving disabled people in the testing of your app. Hopefully, they’ll help you test your website or app and improve its accessibility little by little.