Or: Building a culture where accessibility just happens
Here’s something nobody talks about: accessibility fails because we treat it like one person’s problem.
The designer assumes the developer will fix it.
The developer assumes QA will catch it.
QA assumes someone else already checked.
And the user? They’re the one who gets locked out.
This isn’t about pointing fingers. It’s about realizing that accessibility only works when everyone owns a piece of it. Not as an extra task. Not as a favor. But as part of how things get done.
The Questions That Change Everything
In Planning
Instead of: “What features do we need?”
Also ask: “Who might this exclude?”
That fancy gesture-based interface? What about people with motor impairments?
That auto-playing video? What about people in offices or with sensory sensitivities?
That complex multi-step process? What about people with cognitive disabilities?
You don’t need to know everything about accessibility to ask this question. You just need to remember that not everyone uses the web the way you do.
In Design
Instead of: “Does this look good?”
Also ask: “How would someone navigate this with a keyboard?”
Can you see the focus states?
Is the tab order logical?
Can you escape from that modal?
Are the click targets big enough for shaky hands or thick fingers?
This isn’t about making things ugly. It’s about making sure “beautiful” doesn’t mean “unusable.”
In Development
Instead of: “Does it work?”
Also ask: “Is this the simplest solution?”
Could this be a real button instead of a div?
Could this be a native select instead of a custom dropdown?
Could this work without JavaScript?
Could this use existing patterns instead of reinventing the wheel?
The simplest solution is usually the most accessible. Funny how that works.
In Testing
Instead of: “Did it pass the test cases?”
Also ask: “Let me try this with just my keyboard”
Unplug your mouse. Just for five minutes.
Can you complete the task?
Can you fill out that form?
Can you close that popup?
Can you tell where you are on the page?
This one test will catch more issues than any automated tool.
In Reviews
Instead of: “Does it meet requirements?”
Also ask: “Would this work with a screen reader?”
You don’t need to be a screen reader expert. Just turn one on and listen.
Do the buttons say what they do?
Do images have descriptions?
Do error messages get announced?
Does it sound like chaos or clarity?
Even using a screen reader badly for 2 minutes will teach you something.
The Design Handoff That Actually Helps
Developers aren’t mind readers. If accessibility isn’t in the design, it probably won’t be in the build.
What Developers Need From You
Focus states for everything interactive
Not just buttons. Links, form fields, tabs, toggles, everything.
“Use default focus” isn’t good enough. Design them.
Error states and messages
What happens when something goes wrong?
Where do errors appear?
What do they say?
How do they get announced?
Loading and empty states
What does “loading” look like?
What if there’s no data?
What if something fails to load?
These states need to be accessible too.
Touch targets and spacing
44×44px minimum for touch targets.
But also: what’s the spacing between them?
Misclicks are an accessibility issue.
Color and contrast documented
Not just “this is blue” but “this is #0066CC with 7:1 contrast on white”
Include both normal and hover/focus states.
Note when color is the only indicator (spoiler: it shouldn’t be).
Reading order and hierarchy
What should screen readers announce first?
What’s the logical flow through the content?
Which headings are which levels?
This isn’t always obvious from a visual design.
Stop Treating Accessibility Like a Feature
You know what’s weird? We never say “we’ll add security in phase 2” or “performance is a nice-to-have.” But accessibility? Always at the bottom of the list.
Here’s the shift: Accessibility isn’t a feature. It’s a quality.
Like performance. Like security. Like usability.
It’s not something you add. It’s something you are.
The Uncomfortable Truth About Responsibility
“But I’m not an accessibility expert!”
Good news: you don’t have to be.
You just have to:
- Care enough to ask questions
- Test your assumptions
- Learn from mistakes
- Share what you learn
Nobody expects perfection. They expect effort.
Making It Stick
Culture change is hard. Here’s what actually works:
Make it visible
- Add accessibility to your definition of “done”
- Include it in design reviews
- Make it part of your demo script
- Celebrate accessibility wins, not just feature launches
Make it normal
- Every PR includes keyboard testing
- Every design includes focus states
- Every story includes acceptance criteria for accessibility
- Every retro asks “what barriers did we create?”
Make it shared
- Designers learn basic screen reader testing
- Developers learn about cognitive load
- PMs learn about assistive technology
- Everyone learns something
The Ripple Effect
When one person starts asking “but can you tab to it?” something interesting happens.
Other people start noticing.
They start asking their own questions.
They start testing with their keyboard.
They start caring.
Not because they have to. But because it becomes part of how the team works.
That’s culture change. Not a mandate from above. Not a checklist to complete. Just people giving a damn, together.
Your Part in This
You don’t have to change your whole organization today. You just have to change what you do.
Ask one accessibility question in your next meeting.
Test one thing with your keyboard.
Add one focus state to your CSS.
Write one image description.
Fix one color contrast issue.
Small actions. Repeated. By everyone.
That’s how you build a culture that cares.