How to Cut Service Delivery Costs with Accessibility Testing

If you work on a digital team, accessibility probably isn’t a new concept to you. But, as accessibility legislation rolls out across Canada, you may feel pressure to meet digital accessibility requirements. 

Maybe you’re part of a team that has conducted an accessibility audit in response to these mandates and now has a lengthy, unprioritized backlog of issues to resolve. By taking the time to learn how to ‘shift left’ and incorporate accessibility checks into your design and development work earlier, you could unlock major savings.

IBM reports that building accessibility into design stages can create a 30x cost reduction, compared with making accessibility fixes in post-production. That’s because finding and fixing accessibility barriers early in the process can save hours of expensive developer time. 

So, how can you build accessibility testing into your work sooner? Read on to find out.

Why accessibility testing reduces your risk 

Including accessibility testing as early as possible lowers your legal, ethical and financial risks. You can make decisions at every stage of a digital product or service lifecycle, including planning, design and development. Here’s what it could look like:

• In planning, budget time and funds for accessibility testing. Doing this early helps projects stay on track when testing and solving for accessibility issues.
• In design, include accessibility in your content strategy, style guidelines and user experience. This helps reduce accessibility issues that could show up across your website, like poor contrast, inconsistent heading structure and hard-to-read language.
• In development, include accessibility in definitions of done (e.g. WCAG, pass automated tests, etc.). Fixing HTML and markup issues before release helps keep your backlog of accessibility issues smaller. 

So, how do you catch accessibility bugs earlier in the development cycle? The good news is that there are lots of automated tools that can help you check accessibility, and many of them are free! Of course, these only catch about half of all accessibility issues, but even that can save a lot of time and money.

Here are some tools that can help catch some common accessibility issues. 

7 free automated accessibility tools

1. WebAim WAVE accessibility checker

• What it’s for: A private and secure tool that lets you check web content for accessibility issues directly in your browser.
• Who should use it: Front-end, full-stack and mobile developers, UX/UI and graphic designers, content strategists, QA testers, product owners and business analysts. 
• Pros: It can be used as a browser plugin in Chrome, Firefox, and Edge, or you can visit the website directly.
• Cons: It only gets you part of the way there. For example, it identifies missing alt text but can’t determine whether the alt text is meaningful or appropriate for an image.

2. WebAim contrast checker

• What it’s for: It tests the colour contrast of normal text, large text, graphical objects and user interface components.
• Who should use it: Designers, front-end developers and content creators. 
• Pros: You don’t need to make an account, and the eyedropper tool is handy.
• Cons: It doesn’t give recommendations for alternate contrast combinations. 

3. Stark contrast and accessibility checker

• What it’s for: A freemium tool that checks and makes recommendations for contrast, focus order, typography, touch targets and more. 
• Who should use it: UX/UI, product and graphic designers, front-end developers and QA testers.
• Pros: It integrates with design tools like Figma, Sketch and Adobe XD.
• Cons: Several of its features are only for paying subscribers.

4. Lighthouse plugin

• What it’s for: An open-source browser plugin that generates an accessibility report and scorecard. It identifies WCAG issues and provides links to Deque for more context on the accessibility barrier.
• Who should use it: Front-end developers, QA testers, product managers and Progressive Web App developers.
• Pros: It can be used on live or staging websites, web applications or progressive web apps (PWAs). 
• Cons: The plugin is only available on Google Chrome and Mozilla Firefox.

5. Axe DevTools extension

• What it’s for: It identifies and addresses web accessibility issues directly within browsers.
• Who should use it: Front-end developers, QA testers, UX/UI designers and product managers.
• Pros: It’s compatible with CI/CD pipelines and tools like GitHub, Jenkins and Jira.
• Cons: The free version does not include dynamic state testing.

6. Landmark bookmarklet 

• What it’s for: A code snippet that lives in your bookmark toolbar that highlights or inspects landmark regions (like <header>, <nav>, <main>, <footer>, ARIA landmark roles) on a webpage. There are bookmarklets for lots of things, but this is one example.
• Who should use it: Front-end developers, UX/UI designers and QA testers. 
• Pros: It verifies correct and meaningful landmark roles code properly and implements semantic HTML5 landmarks and ARIA roles.
• Cons: It doesn’t offer recommendations for best practices and is limited in scope. 

7. Hemingway editor

• What it’s for: A freemium writing tool that focuses on readability and scores content on a readability grade scale based on the Flesch-Kincaid readability formula and the Automated Readability Index (ARI).
• Who should use it: Content writers, content strategists and UX writers.
• Pros: It’s free and open source. 
• Cons: It doesn't take into account the audience or context. 

Think your service is accessible? Test it with real people.

Automated testing is a great first step, but it only catches  50% of accessibility issues.

To find the other 50%, Code for Canada’s Inclusive User Research service can connect you to people with disabilities and other hard-to-reach users, to help you take your digital service to the next level. 

Contact us to engage with users with disabilities and find out whether you’re meeting user needs.