Remember those three layers for selling invisible work from yesterday, the third layer especially? Here's the quote I wanted to draw your attention to:
Over time this becomes evidence of what it costs to skip accessibility at the start. And you'll show the cost difference between catching it in design versus fixing it after launch.
That sounds a hell of a lot like shifting left, doesn't it?
Shifting left for accessibility means building accessibility in early, instead of fixing it at the end. In plain terms, you should design, write, code and test with users with disabilities in mind from the start. This way, you can prevent problems rather than fix them later when it's presumably more expensive.
Wow, that makes total sense, doesn't it?!
But think about it. What the hell does that mean and how do you do that?
Most arguments stop short at this blanket advice. Yes, integrate it earlier in the process because it saves money and time.
Most people understand that. They get why shifting left matters, but the advice stops at a vague "do it earlier" without explaining what that means in practice. It's more powerful though to go one step further.
Yes, move accessibility earlier in the process and here are three things that you can do right now.
1. Add accessibility annotations to your design files
Most teams send designs to developers and hope accessibility gets sorted in code. That's backward. Instead, document accessibility requirements directly in your design tool while you're designing. It's not extra work and it changes everything because developers now have a checklist. You've prevented miscommunication and rework.
2. Write accessibility into your user stories
Most user stories assume a single way of interacting with the product. So stories read something like "As a user, I want to filter products by category." Compare that to "As a user who uses only keyboard navigation, I want to filter products by category using the Tab key and keyboard shortcuts so that I can browse efficiently without a mouse."
After you've done that, add acceptance criteria that are concrete and testable.
3. Automate accessibility checks in development
If you wait for QA to catch accessibility issues, you'll lose. Instead, embed automated accessibility checks directly into the code review process. When developers write code, accessibility tools can automatically run and flag issues before the code is pushed.
Devs can run tools both in their development environment and during continuous integration.
With just these three things, you've moved accessibility from the end of the process to the beginning, through design annotations, the middle, through acceptance criteria, and throughout via automated checks.
I have some suggestions for how to do each. Things I find myself doing again and again and I know they work. I'll go in more details over the next emails.