When was the last time you evaluated a new accessibility tool? When the Web Content Accessibility Guidelines update, how quickly does your team adapt? Are you keeping up to date with browser developments?
If these questions give you pause, you might have an accessibility technical agility problem.
Normally, usually, most of the time...accessibility isn't a technical problem.
Sometimes, a team's lack of technical skill is still part of the problem. And that's okay. Because that's a problem you can fix with training and education.
The bigger problem is when you treat accessibility like a static checklist. You implement solutions once and consider the job done. But accessibility is rapidly evolving. New assistive technologies emerge, user needs shift, browsers update and best practices evolve. Standing still means falling behind.
To be clear, technical agility isn't about chasing the newest trends. Heck, we'd all be outsourcing our jobs to AI if that were the case. Technical agility is about maintaining the flexibility to embrace better solutions when they appear.
It's about having systems that can adapt when your users point out barriers you hadn't considered. It's about building on open source contributions and sharing our own solutions back to the community.
The most resilient teams are teams that actively monitor emerging standards, experiment with new tools and aren't afraid to refactor existing solutions when better approaches emerge.
You could look at:
- how many accessibility-focused open source contributions you make
- how many polyfills you delete because browser do it natively now
- how often discussions around the WCAG happen in sprint planning
- how fast you fix newly discovered accessibility issues
- how many internal accessibility solutions are shared publicly
Legacy patterns sometimes hold us back from improvement. If we were humble enough to recognise that today's best practice might not be tomorrow's, we'd be that much better off.