Ever feel like accessibility is a constant battle in your dev team? You preach the importance, you evangelize, you showcase bug fixes in weekly meetings, but integrating it into the daily workflow can feel overwhelming. Well, fret no more, fellow accessibility champion! Here’s a story about a super easy solution that transformed our team’s approach to accessibility.
Organizations when they encounter accessibility often feel like fighting an hydra. It’s the project that they have to do and when they get to the end of the project they realize not only are they not done but there is even more work left to do.
Agile Accessibility for Good – Dylan Barrell & Deque Systems
We all know lectures and endless documentation rarely stick. So, I decided to embed accessibility right into the developers’ routine. My weapon of choice? A simple GitHub PR template.
Yes, a simple .github/pull_request_template.md file in our repository is my success story! Very simple, but just as effective. It’s a todo-list really, with only 3 items to check :
- Auto a11y tests pass: We’re using Accessibility Insights for Web, one click in the browser plugin scans the whole page and reports issues
- All actions can be performed in keyboard nav: This part required the most training, but really not that much, but helped clearly explain why losing focus or not seeing it was a problem
- All content uses semantic markup: With examples for lists, headings and paragraphs, this finalises the todo list.
Now, the results? Quite good actually! Legacy pages scored an average of 30% conformance during our last audit, but this scored jumped to an average of 65% for recent pages and features since adding the checklist.
A design system must make the right thing to do the simple thing to do.
Design Systems Communication – Nathan Curtis
This quote above is so simple but also very powerful and applicable to accessibility as well. Building a culture of accessibility is key, once it becomes ingrained in our process, it’s seamless. Integrating basic accessibility testing and fixes into our development workflow has significantly improved our ability to deliver features that are usable by everyone, without feeling like an additional burden.
But the real win wasn’t the numbers. It was the positive shift in our team’s mindset:
- Devs as A11Y Buddies: They started understanding the importance of clear semantics for users who rely on assistive technologies.
- Small Fixes, Big Impact: Devs felt empowered to identify and fix minor accessibility issues themselves.
- Focus on Strategy: Complex accessibility problems landed on my desk, allowing me to focus on more strategic improvements for the entire product.
It’s important to remember that this approach won’t magically create a fully accessible app overnight. There will still be complex issues that require a deeper dive but according to Deque automated tests identify up to 57% of accessibility issues. But this simple PR template did two crucial things: it significantly improved accessibility across the board, and more importantly, it empowered our developers to become active participants in the A11Y journey. This newfound awareness and ability to tackle smaller issues themselves freed up valuable time for me to focus on the intricate accessibility challenges that demand a more specialized touch.
The key takeaway? This 15-minute training disguised as a PR template made a huge difference. It showed me that sometimes, the simplest solutions can have the most impact. So, if you’re looking for a way to make accessibility a natural part of your team’s workflow, consider giving this a shot! You might be surprised by the positive results.
Accessibility is not one box checked by one person, and a design system is central way to model and amplify that tone through its’ tools and communications.
Accessible DS don’t guarantee accessible products – Nathan Curtis