In the tech industry, tests have become a universal standard to gauge code quality and stability. Yet, one thing rarely makes the list: accessibility.
Accessibility is essential for ensuring that our software is usable by everyone, including users with disabilities or those navigating on different devices or in various environments. But because accessibility can seem complex and full of rules, many developers feel put off by it.
This guide is here to change that. By taking a few practical steps, you can start incorporating accessibility into your work naturally and easily, making it a default part of your workflow—no deep expertise required. Let’s dive into a few essential tools and practices that will help you get started.
1. Unit testing with testing-library
One of the most straightforward ways to start making accessible applications is to use testing-library for unit testing. This library not only enables you to test the usability and internal logic of components, but it also makes it easier to account for accessibility.
In particular, testing-library encourages using the *byRole queries (e.g., getByRole) to select elements by their role. This practice mirrors how screen readers interact with content, helping ensure that your app is accessible to users relying on assistive technologies.
Here are some resources for diving deeper:
Bonus tip: Install the testing-library ESLint plugin
To help enforce best practices while writing tests, install the Testing Library ESLint Plugin. This plugin will prompt you to follow accessibility guidelines, helping you anticipate common mistakes when writing tests with testing-library. It’s a handy way to ensure you’re following best practices for the library and, by extension, for accessibility.
3. Automate accessibility testing with cypress-axe
If you’re looking to test accessibility on a page level, try using cypress-axe. This tool integrates with Cypress to provide end-to-end accessibility testing, flagging issues like contrast ratio problems or missing ARIA attributes in real-time.
Its just one line of code:
beforeEach(() => {
cy.visit('http://localhost:9000')
cy.injectAxe()
})cypress-axe helps automate accessibility tests across your app’s entire workflow, making it easy to catch potential issues at every stage.
4. Be an ally alongside designers
As developers, we’re often not the ones creating the initial UI designs, but we play an important role in maintaining and advocating for accessible choices. It’s common to encounter design specifications that don't meet contrast requirements or other accessibility standards.
Engage with designers early in the development process. Share accessibility concerns with them, and suggest tools like Radix UI for design systems with accessible color palettes. These conversations can lead to better overall design, helping make sure accessibility standards are met from the start.
5. Accessibility Tools
If you’re interested in going deeper into accessibility testing, there are several tools that can support you:
- Silktide: An easy-to-use browser extension for manual, but effective accessibility checks.
- Lighthouse: A free tool built into Chrome’s DevTools that provides a high-level overview of your app’s accessibility strengths and weaknesses.
For a comprehensive list of accessibility tools, check out the W3C’s accessibility tools hub, where you can find tools to help you at every stage of accessibility testing.
These resources provide insight into the areas where your application may fall short, helping you prioritize fixes in a practical way.
Conclusion
This is not an exhaustive list but rather a few tools I’ve adopted as a frontend engineer. They make it easier to “shift left” on accessibility, incorporating it earlier in development without requiring expert-level knowledge.
Accessibility is about inclusion—it’s a means of creating software that’s usable by as many people as possible. By implementing these practices, you can make accessibility a natural part of your workflow without needing deep expertise or complex tools. With every accessible component, test, and page, you’re contributing to a more inclusive digital world.
Let’s aim for accessibility as the default, so that we’re not only building software but building it for everyone.