When coders discuss terms like “web accessibility,” they’re referring to the W3C WCAG guidelines. After glancing at that link, you likely feel that reaching a compliance level is an impossible task. This is one of the reasons why we recommend using this guideline as you go.
Not all of us are so lucky, and unless you want to avoid accessibility audits for the rest of your life, you’ll need some way to test your website accessibility, either manually or automatically.
Automated Auditing
Start with an accessibility checker to see if your website is at risk of an accessibility lawsuit. For the checker we linked, a score of under 95% is enough to put you in serious legal trouble.
But, there’s no need to worry. Accessibility checker will set you up with software solutions that can help you become compliant under United States law. Deque created and maintained axe-core, an open-source JavaScript Engine, can also help you find WCAG code violations.
Component Plugins
Component plugins are helpful for sandboxing and customizing your testing experience. For example, React can use Storybook to build UI components and pages in isolation. This streamlines UI documentation, development, and testing thanks to its simplified screen reader.
While there are other ways to use component plugins for other systems, most web accessibility testing options are still limited. Hopefully, one day, manual auditing will become obsolete.
Browser Plugins
Browser plugins are the easiest to integrate for developers and non-programmers alike. There are over 42 browser extensions that perform practical accessibility tests. Any one of them is effective at pointing out issues on your websites by overlaying troublesome DOM elements.
Even the US government uses website accessibility plugins like ANDI to ensure their sites are accessible to everyone. Still, it’s essential only to use plugins that integrate with your workflow.
Accessibility Linters
When working within the JavaScript framework, you’ve likely set up limiting rules to organize your code. Thankfully, there are now ESLint plugins that automatically look for accessibility issues and provide feedback. Vue, React, and Angular all use the eslint-plugin-jsx-a11y code.
There are so many minor issues that tend to be overlooked during an audit, but linters can focus on these problems. Since linters provide a lot of detail, test slowly to not feel overwhelmed.
End-to-End Tests
At some point, most developers have used end-to-end testing to simulate real user scenarios from start to finish. Typically, developers will use manual testing protocol for an end-to-end simulation, but axe plugins can run accessibility tests to find difficult to locate problems.
For example, two buttons with the same id is a violation, but that can be almost impossible to find with a linter. Unless you’re meticulous, even a manual test won’t locate this issue.
Manual Auditing
Even with all the great and powerful automated auditing tools available for you to use, they’re not perfect. Most tools only catch 20-50% of all accessibility issues that are easily detectable in HTML files. Automation tools won’t catch high-level user experience problems.
For example, manual audits can locate poor page navigation and keyboard integration because only a real person can ensure all features are accessible to all of your customers.
When creating a manual testing process, add the following extra requirements:
- Does my website break under 120% zoom? Can I operate the website at 200% zoom?
- Is every user interface component operable with the keyboard alone?
- Are money features, like payouts or cancel subscription options, easy to find?
- Can a screen reader read my screen correctly? Does the textual hierarchy make sense?
- Do I need a colorblind version of my site? Do my colors pass the contrast checker?
Developers can’t fix every accessibility problem, but we can fix most of them. Do your best to focus on higher-level issues first, so your website isn’t a lawsuit waiting to happen.
