Is Your Website Violating the ADA Act?

Published in

Isovera

5 min readJul 20, 2017

*Editor’s note: no actual axe’s were used in the creation of this article, nor are all that necessary for accessibility testing. Please read on.*

Are you aware how important accessibility is in modern web design? According to the CDC over 15% of American adults have hearing trouble (37.2 million) and almost 10% have trouble with vision (22.9 million). Now imagine that these 59 million individuals are trying to access products and services via your website and cannot because it’s not accessible. Is losing a substantial market share for subsequently no reason not enough of a selling point for you? Well, failure to make your website accessible could mean violating the Americans with Disabilities Act or The Equality Act 2010 and your business can potentially be prosecuted. Do I have your attention now? Great!

So now that we know that it’s not optional, it’s time to ask the obvious question: Do you have a good lawyer? Kidding aside, the real question is: Is your website accessible? If you have a hard time understanding what that means or are unable to answer the question, don’t feel too bad. Unless you are taking accessibility into account when you are designing and building your site, there are probably a number of gaps and mistakes you may be overlooking.

Ok! I care about accessibility now! How can I fix my accessibility mistakes?

The best way to fix accessibility mistakes is to try and not make them in the first place. Groundbreaking, I know, but the truth is it’s much more expensive and time consuming to implement accessibility after the fact. It is much simpler and cost effective to just do the work up front. With a bit of forward thought, adhering to best practices, and leveraging some awesome tools (foreshadowing) implementing accessibility does not have to be expensive. It is also important to understand that several different levels of accessibility compliance exist. The level of conformance you are targeting will determine what and how much you need to test. More information on levels of conformance can be found here.

Easy Accessibility Testing with aXe

So now that we know when and what we are testing, we can establish the “how”. Good accessibility testing will always begin and end with tests that are completely manual (meaning they can only be run and evaluated by a live human being). Outside the manual loop there are a number of different tools that exist for a more automated style of testing.

All of the tools I am going recommend leverage the powerful aXe accessibility engine distributed by the brilliant folks at Deque labs. These tools are equipped with over 15 years of accessibility experience and help you catch accessibility issues early cutting down on frustration and cost. These tools all run locally which makes execution and feedback extremely fast. There is no waiting for a slow network call to return your test results as you don’t even have to be connected to the internet for these tools to function properly! The aXe toolkit makes running accessibility tests alongside development super easy and fast!

The aXe Browser extension

The aXe browser extension gives you the power of aXe API right smack in your browser and is available on both Chrome and Firefox. It comes complete with a dashboard that will give you feedback on the issues, tell you how many times the issue has occurred, and the severity of the infraction. Clicking on an issue will give you a more detailed description of what the issue is as well as a link to additional information about that specific issue. It will show you a code snippet of where that issue is being caused as well as guidelines for fixing the issue. It also has an inspect button which is super useful for targeting the problem code directly in your browser’s page inspector! Oh and did I mention this tool is 100% free? Get the aXe browser extension here.

Accessibility testing from the command line!

Another great tool that I love is the axe-cli module. Using the command line you can point this tool at your desired page or pages and it will validate accessibility test without ever having to actually open a browser! You can also specify sets of rules to pass as parameters to your tests, for example `axe www.deque.com — tags wcag2a` which will run against all wcag2a rules. The results of these tests can then be saved to a JSON file using the ` — save` flag. While boasting similar features to the browser extension it also supports CI integration which can halt a build if any rule set fails to pass.

Automated testing with aXe-core

For a more advanced and customized accessibility testing experience, developers can take advantage of the aXe-core module. This module allows developers to programmatically create automated tests that can run along side code execution automatically. These accessibility tests can be configured to pass before the code is ever promoted to a production environment. If your environment already has integration tests, it’s easy to work in aXe since you’ve already got an infrastructure for loading URLs and scripting user scenarios. Further, if accessibility support regresses in your application, you’ll know right away because you’ve already benchmarked the current level of support directly through your integration.

Wrapping up

I want to point out that while aXe engine and the great tools that accompany it are A solution, they are not the ONLY solution. Accessibility is one of the easiest things to neglect when developing and there is no reason that has to continue to be the status quo. The important take away is that while accessibility testing is inherently a challenging problem there are many different solutions (many of them free!) that can be integrated into your team’s processes to help. I hope this article has shed some new light on the importance of accessibility testing and how it no longer has to be the burden of your development workflow.