This article is based on Jeremy Rivera’s talk at A11yNYC. He talked about how to leverage free accessibility tools to create more inclusive digital experiences. He explores a variety of powerful, no-cost resources that help developers, designers, and content creators identify and resolve accessibility issues efficiently.
Jeremy Rivera is a developer advocate at Deque. In this role, he’s a software developer who spends a lot of time with the community and gives them resources to help them code accessibly or make their jobs easier.
What’s in your accessibility toolbox?
Every profession has a different answer to what’s in their general toolbox. For other trades and professions, you can probably guess the tools they use. If you can think of a carpenter, they probably use a lathe, a saw, a mallet, a square, and different chisels.
A painter may need to sketch out their image on the canvas with a pencil before they come back with brushes and paint. Each trade has its tools and accessibility development is no different.
Developers, designers, and engineers use tools every day such as keyboards, screen readers, and Integrated Developer Environments (IDE), such as Visual Studio Code. These tradespeople are skilled professionals in a very specialized craft. Digital technology trades rely on different tools for different skill sets, with variations depending on the focus of the team.
Jeremy’s focus today is on tools regarding how to make accessible development easier. The tools are available for free to build an inclusive experience for all. Like any industry, specials come with high prices, but the tools don’t always have to. There are many teams that haven’t gotten the buy-in yet from their stakeholders, but that doesn’t mean you can’t get started or stop you from trying.
Accessibility issues can be and often do get introduced during each stage of the development. Each stage creates a unique and good opportunity to continuously check and test for accessibility issues.
Shift left with accessibility
That said, it’s important to incorporate accessibility best practices as early as possible even while you are writing the code. The later the phase you add accessibility, the more expensive it gets. Finding accessibility issues during the design phase only costs 1 x. Catching accessibility issues during development increases the cost by 5 x.
During quality assurance (QA), the cost of fixing found accessibility problems jumps by 15 x. Any accessibility problems caught in production will cost 30 x more than adding it during the design phase. These numbers are based on an IBM report. Thus, it’s important to shift left and build accessibility from the start during the design phase. Still, once the product is given to developers, it’s their responsibility to maintain it. Otherwise, the organization will pay a price for accessibility issues caught later.
Accessibility doesn’t have to be expensive when it’s done correctly and done early enough, but it often is because it’s typically later in the game that people start. Some teams don’t have an accessibility budget. This means they must be scrappy with the available tools on the market.
Linter
What is a linter? If you have ever grabbed a ball of dust from your pocket after drying it, you probably encountered lint before. Similarly, in a code repository, there are times in which the code rewrite might not be best practiced and might have a little dirt in it.
In terms of programming, a linter is a tool that analyzes your code as you watch it. It checks for errors, inconsistencies, and violations of something. Linter can help with format, syntax, and accessibility. Think of it as a spell checker for your code because it helps you figure out what happens as you write the code.
There are accessibility linters like the ESLint plug-in JSX-A11y. Here’s what its GitHub description says. “This plugin does a static evaluation of the JSX to spot accessibility issues in React apps. Because it only catches errors in static code, use it in combination with @axe-core/react to test the accessibility of the rendered DOM. Consider these tools just as one step of a larger a11y testing process and always test your apps with assistive technology.”
Some of the rules it enforces is alt text, the order of certain elements, keyboard traps that might come into play, and others.
Another alternative linter is the axe accessibility linter. This one is built with axe developer tools. This means the errors will show up on the browser. It also has pre-built support for other component libraries. If you create your own component library, you can map it to specific rules so it can also learn how to read that library.
The linter can work like spellcheck. For example, if an image is missing proper alternative text, there will be a squiggly red line under the image tag. This makes it easier to find problems. You can learn about the problem, how to fix the problem, what standard it breaks, and more information such as the disabilities that are affected by the error.
Testing in the browser
After writing the code and the application starts to take shape, you want to test the code locally in the browser. Many developers have their IDE on one monitor or half their screen, and then a browser on the other side of the screen. This lets them test the code and edit the code at the same time. Browser tools help you catch common accessibility issues.
Google Lighthouse
Google Lighthouse is a free open-source tool created by Google that analyzes web pages to help improve their overall quality. It can be run on any site whether it’s public or requires authentication.
You can run Lighthouse within Chrome DevTools. Lighthouse runs a series of audits and provides a score in four areas: performance, accessibility, best practices, and SEO (search engine optimization). For anything that fails, Lighthouse explains why that issue matters and how to fix it.
Lighthouse is good for a quick audit during early development before you commit. You might use it as quality assurance (QA) for code reviews.
WAVE browser extension
Most browsers have WAVE available as a browser extension. It’s a free tool that identifies accessibility issues. When running WAVE, it opens a console on the side of the browser based on the page tested. The side panel displays a summary of its findings. Icons matching WAVE’s panel information appear on the web page. It’s a way to get a visual indicator of where the problems are.
WAVE runs on a person’s machine’s browser, so it’s local and secure. It does not send any data to the server. The extension works with keyboard shortcuts.
Axe Developer Tools browser extension
Axe Developer Tools is free to use and works with a variety of browsers. Like WAVE, it runs automated accessibility scans on any web page. The interface shows the number of issues, a breakdown by issue type, and a recommendation on how to fix it. You can fix issues in real time. For example, the extension catches a color contrast issue. The developer can change the color and rerun the scan to verify the fix.
Important things to remember regarding tools
It’s important to use the tools as intended. Automated tools catch a lot, but not everything. False positives can happen with the best tools. Just because there are no errors does not mean it’s accessible. Someone posted an example of a very inaccessible webpage that got a perfect score on accessibility.
To build accessible experiences, developers need to pair tools with manual audits from accessibility experts and feedback from users with disabilities. Incorporate people with disabilities early in the development process. Accessibility is a people-first process. It’s more than a technical checklist.
Developers should learn how to use a screen reader. But unless they depend on a screen reader for their browsing experience, they don’t know truly how someone who uses a screen reader wants the web page to work.
Free vs. paid tools
To use an analogy, consider when you might use a screwdriver. You might use it for something like a watch, a dresser, and small things. A screwdriver is an indispensable tool and you probably have several of them in your house. Use your screwdrivers.
But you don’t just have screwdrivers. You might have a drill even though it does the same thing. What would you use a drill for instead of a screwdriver? Drills are more expensive, but they might speed up the task.
Sometimes you’ll use a screwdriver. Sometimes you’ll use the drill. It depends on the task. Would you build a house with a screwdriver? Could one person build a house with a screwdriver? Maybe. Will it take years versus months or weeks? Does the team need to use it? These are all considerations to think about when it comes to free and paid tools.
Free tools do not mean free of effort. When using free tools, it will still require some effort. Choose the right tools for your role. Master a few instead of trying to master each of the different browser extensions. There is a lot of overlap between extensions. Understand how the tools work, not just what they flag.
It’s still important to understand WCAG so you know what you’re fixing and why it matters. More importantly, tools can’t replace lived experiences. Hence, get feedback from people with disabilities. And lastly, incorporate accessibility into your workflow now.
Video Highlights
Watch the Presentation
Resources
- Google Lighthouse
- WAVE web accessibility evaluation tool
- Axe DevTools Pro free trials
- ESLint-jsx-a11y
- Axe Accessibility Linter
- Deque documentation
- Axe Chrome extension
- Agile Accessibility Handbook: A Practical Guide to Accessible Software Development at Scale by Dylan Barrell
- A11y Automation Tracker
Bio
Jeremy Rivera is a Developer Advocate for Deque Systems. He is a full-stack software engineer contributing to numerous open-source projects with a preference for JavaScript and Python-related technologies. He learned American Sign Language after high school and since then has been a friend to the Deaf community. Since then, he has participated in education work promoting literacy in the language. He joined Deque to continue to make the world an accessible place for people of all backgrounds.
