5 Ideas on How to Incorporate Web Accessibility into your Dev Workflow
Thoughts and philosophies for how to set up your team’s workflow to tackle accessibility
If we’re working at smaller companies without specialized accessibility teams, how can we incorporate accessibility into our development workflow to create a more consistent environment in which we can tackle accessibility?
As a developer myself, I see automated accessibility measurements as a test coverage metric. In both cases, we can define a relatively quantifiable end goal and make concrete steps to get us closer to that goal. Furthermore, both accessibility and testing work is invisible to the user, but results in a more seamless product that provides a better overall user experience.
The ideal test coverage situation is one in which we set up our testing infrastructure and defined our coverage goals from the very beginning, developing a muscle to write and change tests in tandem with development. Likewise, the ideal accessibility situation is one in which we defined our desired WCAG compliance level from the beginning, and set up our infrastructure (both technical and non-technical) just right to support our continued work to reach and maintain that compliance level.
As developers, we’re very familiar with this concept of test-driven development (TDD), so much so we even have a name and acronym for it. Accessibility should be part of our testing stack and philosophy, and therefore part of TDD. As we learned last week, there are many ways we can add accessibility as a quantifiable metric.
Including accessibility into your TDD methodology comes with a simple philosophy: Accessibility issues are bugs.
Looking to add accessibility into your team’s workflow but don’t know how to introduce it? Here’s a few steps and ideas that have helped my teams throughout my career. I hope they can inspire you and your teams to come up with your own specific solutions:
1. Add quantifiable accessibility goals into your roadmap
If you are truly starting from ground zero with an existing product, it could be a good idea to create a roadmap for your accessibility goals.
Your end goal could be a specific WCAG compliance, or a Lighthouse accessibility score, with intermediary goals like getting your design system completely compliant:
After a previous employer received an ADA lawsuit, we banded together to create a roadmap toward compliancy to present to the case attorneys. Despite the experience being stressful and mildly rushed, it was a great exercise that helped us clarify all that had to be done to make compliancy possible.
Obviously, you don’t have to create an entirely new accessibility-only roadmap. In fact, it’s probably best if you weave it into your current technical roadmap, and have it be a sibling citizen to all your other engineering priorities.
I highly recommend creating milestones or goals for your accessibility journey in a similar way as you might for testing or performance goals. Putting pen to paper helps prioritize and crystalize your accessibility journey. Hopefully, it doesn’t take an ADA lawsuit to force you to!
Don’t forget: WCAG compliance is like HIPAA compliance, it’s never finished! Don’t stop caring about accessibility once you reach your desired level of compliancy, continue to incorporate and consider it in your workflow.
2. Add a11y linters to your codebase
Linters only catches 20–25% of all accessibility issues, but they’re a start. Any type of automation you can do will greatly help you in the beginning of your accessibility journey. This is what we specifically did with ours:
- We added
eslint-plugin-jsx-a11yto our React codebase and wrote a small node script that ran it on every file, generating a JIRA ticket for every issue. We assigned each ticket a priority depending on lint rule type, and delegated them in chunks in the same way we triage other product bugs. - Using husky, we had eslint run as part of our pre-commit git hook. We made it such that the a11y plugin would only run on newly added files, since the rest were documented in JIRA from step 1. In this fashion, we could ensure that new code would at least minimally meet the accessibility linter’s standards.
- We had our continuous integration framework run it on every branch, only allowing merges if it was passed. That way, if someone bypassed the pre-commit hook, we would still ensure our main branch wouldn’t get fresh inaccessible code.
Scrum masters were then told to prioritize at least a few accessibility bugs every sprint, just as they would a normal bug. It sounds pretty aggressive, but we found that this aggressive approach accelerated our accessibility squashing by many times over.
Beyond linting, you can also add automated tests into many end-to-end frameworks and create a whole ecosystem of unit tests as well. I invite you to be creative with fitting the many accessibility tools available into your stack and workflows.
3. Share resources widely to foster education
It can be a scary thing to suddenly have 200 JIRA bugs assigned to your team without any knowledge of how to fix them. So we prioritized accessibility education, accessible to everyone in the company (har har).
We made a “What is Web Accessibility?” presentation that was given at our All Hands and our engineering monthly meeting. We also created a series of living documents describing our new workflows, with links to our favorite resources. Every few days, we’d post a new accessibility tip in our frontend engineering Slack channel. We’d encourage people to discuss their accessibility work openly on Slack and in our weekly frontend meetings, and further encouraged people to help each other instead of relying on the same experts over and over.
If you can foster a no-judgment learning environment, people will be more willing to learn and adopt. Even though there was pressure to squash bugs from the linting step, knowing that you can reach out to anyone and that you’re all working toward a higher goal together is empowering.
4. Create an accessibility working group
When you’re making big changes to your workflow, it’s important that people not only get the support they need, but also are encouraged to give back and support the ecosystem. It’s also important to hold open discussions and give people a chance to give their input. So, we started a working group.
Our company was split into feature areas, with a few engineers and designers in each feature team. We asked each team to nominate one frontend engineer to be the “accessibility advocate” of their team and join our Digital Accessibility Working Group (DAWG).
This group met every other Monday for 1.5 hours. In it, we’d spend half an hour teaching a new accessibility concept or introduce a new addition to our workflow, and in the following hour we’d answer questions, hold office hours, and discuss and research difficult accessibility problems together. Everything was done very democratically, to reinforce the idea that we were all learning together and that no feature team was any more important than any other.
The advocate would then return to their team, hopefully with some new knowledge and answered questions to help spread the knowledge. After all, there’s no better way to learn than to teach yourself!
5. Change your development mindset to include a11y
While working on the frontend, you’ll often be checking your browser console for errors while developing. Errors should make your heart jump a little while you’re developing; what? I forgot a React key somewhere? God damnit, not again!
Yes, I know that lots of websites are so far gone that the console is basically white noise. However, we should always strive for a clean console. Similarly, we should always strive for a a clean looking WAVE or ANDI output. Ideally, we should add accessibility tools to our development tool belt, alongside our regular development and testing tools. It shouldn’t feel like an extra chore, it should just feel like a normal step in the development cycle.
I’ve found the best way to tackle accessibility is to see it as a natural part of testing and QA. Just remember that accessibility issues are bugs, just like a broken link or image is. Once we start thinking of them and treating them that way, we’ll see fewer accessibility issues across the web.
I hope these tips are useful to you, and I’m curious to hear any others that have worked for you and your teams. Good luck on your accessibility journey, and thank you for embarking on it in the first place!
