Accessibility isn’t an afterthought – so stop treating it like one.
“Once again, things that could have been brought to my attention… YESTERDAY!” – Adam Sandler, The Wedding Singer
That’s accessibility when it’s added too late. Funny, yes. But also kind of devastating if you’ve ever been the one locked out.
If you’ve made it this far in the book, you’ve probably already had your “What has been seen cannot be unseen” moment. You’ve jabbed at the Tab key, you’ve gotten lost in a modal, and now you can’t stop noticing focus states, missing alt text, or buttons that disappear under sticky headers.
Welcome to the club. There’s no going back – and honestly, that’s a good thing.
What shifting left actually means
“Shift left” is one of those phrases that gets thrown around a lot, usually by people who want to sound agile without actually changing anything. And too often, it just means “do it a bit earlier.”
But that’s not enough. True shift-left thinking means baking accessibility in from the very beginning – and keeping it there at every stage. It’s not about squeezing in a checkbox during design. It’s about making accessibility part of how you think about the project.
Accessibility through the process
Let’s break it down. Here’s the standard digital project process:
- Analysis
- Wireframing & Design
- Development
- Testing
- Launch
- Beyond
In a lot of organizations, accessibility only shows up at step 4 – or worse, step 5. Maybe someone runs an automated checker right before launch. Maybe someone asks, “Wait, can screen readers use this?” That’s not shifting left. That’s shifting blame.
Instead, accessibility needs to be like that neon pink arrow in the diagram: stretching across every phase.
- During Analysis, you ask: who are we designing for? Who’s often excluded?
- In Wireframing & Design, you bake in contrast, color choices, labels, focus indicators, and text hierarchy.
- During Development, you use semantic HTML, make sure everything works without a mouse, and build with assistive tech in mind.
- In Testing, automation and manual checks work best together – you need both to build something that actually works for everyone..
- At Launch, accessibility isn’t a surprise guest. It’s already part of the party.
- And in Beyond, you plan for maintenance, continuous improvement, and future accessibility needs – because accessibility isn’t a one-time fix. It’s an ongoing commitment.
Do it right or do it twice.
The digital precarity problem
One of the most powerful explanations of this came from Quinn Keast:
“I think about ‘digital precarity’ a lot from the perspective of being deaf; for now, live captions on calls and through hacky workarounds work well enough to get by. But if they’re dropped, under-resourced, or under-prioritized, boom, I’m alone and on the outside.”
And that’s exactly what happened when Twitter became X. They let go of their entire accessibility team. Spaces lost auto-transcription without warning or explanation. One day, deaf users had access. The next, they didn’t.
That’s what happens when accessibility is treated as optional. That’s what happens when you don’t shift left. People disappear.
Accessibility isn’t just about doing things early. It’s about following through. Because stopgaps, patches, and bolt-ons are fragile. And people shouldn’t have to live in fear that the next update is going to lock them out.
Buy-in matters
If you want this to work, you need support from the top. Bottom-up change is noble, but painfully slow. If you can get leadership to commit – really commit – you can build accessibility into every template, process, and decision.
And don’t go it alone. Talk to the people in your organization who care about equity, diversity, and inclusion – whatever the acronym looks like where you are. Accessibility is part of inclusion, even if it’s not always recognized that way.
Digital accessibility isn’t just for websites. It’s in everything: presentations, documents, emails, and online meetings.
Expect resistance. And false starts.
You’ll run into pushback. People will tell you it’s too hard, too complicated, too expensive, too political. You’ll have to pick your battles. You’ll make mistakes.
But the earlier you care, the less it costs – emotionally, reputationally, and financially. And once you see the impact of doing it right, you’ll wonder how you ever let it slide.
Do it like you mean it
Shifting left isn’t just a clever trick. It’s a mindset. A responsibility. A quiet kind of revolution.
You do it not because it’s easy, but because it matters.
Because no one should disappear. And if you remove their way of telling you, how would you even know?
(Somewhere, a user found a broken link. But instead of reporting it, they opened a new tab and watched cat videos instead. We don’t blame them.)
What testing actually means
Real accessibility testing is layered.
Each method brings something different – and none of them cover everything.
- Automated testing is broad, but shallow. It can scan hundreds of pages in seconds, but it only catches what it’s been told to look for.
- Manual auditing is deep, but narrow. It uncovers the stuff automation misses, but it takes time and usually focuses on a small sample.
- Consultancy provides strategic guidance across the whole process, especially in early phases like design and wireframing.
- User testing is the gold standard – it comes after the fixes, when you want to know if your work actually holds up in the real world. It’s where lived experience turns into lasting insight.
Together, they give you the clearest picture.
Skip one, and you’re guessing at best.
You can’t fix what you’re not looking for.
Automated testing: Fast, scalable, essential
Automated tools are a great place to begin. They’re fast, cover a wide range of issues, and can be run often.
But they’re not created equal. Some tools just scrape the page. Others go further, rendering in real browsers, handling dynamic content, simulating modals, forms, and user journeys.
The point isn’t to bash automation – it’s to understand what it can and can’t do. A good tool helps you see patterns, highlight big issues, and fix things at scale. A great one helps you understand what those issues mean.
Use it. But don’t stop there.
Manual auditing and consultancy: Going deeper, earlier
Manual audits tend to happen toward the end of a project. They involve checking:
- Keyboard functionality
- Focus states and visibility
- Screen reader experience
- Voice commands and navigation via tools like Dragon
- Whether labels are meaningful and consistent
Manual audits are usually done by experts who understand what WCAG says – and what it means. But let’s be real: they’re often treated as the “final hurdle” instead of an ongoing check-in.
That’s where early involvement changes everything. When accessibility experts join during design and prototyping, they help prevent issues before they’re baked in.
It’s not about having a checklist. It’s about knowing which questions to ask, and when.
User testing: don’t assume, ask
If you want to know whether people can use your product, let them try. That means:
- Asking real people with lived experience
- Setting up tasks that reflect real life (paying rent, signing up, navigating a complex page)
- Observing, learning, adjusting
But this part is important: testing is a job. Your disabled coworkers aren’t automatically your test subjects. If someone uses assistive tech and works in your org, they already have a job. Don’t “volun-tell” them to do yours.
Pay people. Ask for consent. Respect their time.
Common traps
- Assuming automation alone is enough
- Forgetting about mobile and responsiveness
- Not testing dynamic content like modals, dropdowns, and form states
- Overlooking focus order or poor visibility
- Skipping re-testing after updates
- Ignoring templates, including emails and internal tools
Your template changed. Your accessibility probably did too.
Document what you find
If you don’t document what you test, how will you know what’s changed? You need to:
- Prioritize clearly: what blocks users, what’s just annoying?
- Be specific and actionable in your reporting
- Avoid jargon – real humans need to understand it
- Keep a log to track improvements over time
A good audit or report doesn’t just point out what’s wrong. It shows you how to do better next time.
And that’s the point.
Accessibility isn’t about perfection. It’s about paying attention.
A broken link isn’t just a bug – it’s a closed door. And if you never test it, how would you even know it’s locked?
Don’t guess. Test it. Build trust. And keep the door open for everyone.