I have watched the same pattern unfold dozens of times over the past sixteen years. An organisation discovers it has accessibility problems — usually because a legal complaint lands on someone's desk, or a major client starts asking uncomfortable questions. They bring me in. I audit their digital products, deliver a report thick with findings, and their team gets to work fixing things. For a few weeks, accessibility is the priority.
Then the fixes ship. The report goes into a folder. And within six months, the same organisation is building the same inaccessible patterns all over again.
This is not an occasional outcome. It is the default. And it happens because these organisations never treated accessibility as something they are. They treated it as something they do — briefly, reluctantly, and only when forced.
The Compliance Trap
Somewhere along the way, the industry convinced itself that accessibility is a technical problem with a technical solution. Meet WCAG 2.1 Level AA. Check the boxes. Ship the report. Move on.
I understand the appeal. WCAG gives you measurable criteria. You can point to a success criterion, test against it, and say "pass" or "fail." It feels clean. It feels manageable. And for people who have never navigated a website without being able to see the screen, it probably feels sufficient.
It is not.
I have tested products that technically met every WCAG success criterion I could measure — and were still profoundly difficult to use with a screen reader. The heading structure was technically correct but the information architecture made no sense. The form labels existed but the error handling was so confusing that I abandoned the task after three attempts. The colour contrast ratios passed, but the visual design relied so heavily on spatial relationships that the content was meaningless when linearised.
Compliance asks: "Does this meet the standard?" Culture asks: "Can people actually use this?"
Those are very different questions. And only one of them matters to the person sitting in front of the screen trying to pay a bill, book an appointment, or apply for a job.
What "Accessibility Culture" Actually Means
When I say accessibility needs to be a culture, I am not talking about posters on the wall or an annual awareness day. I am talking about accessibility being woven so deeply into how an organisation designs, builds, and tests its products that it stops being a separate conversation entirely.
Here is what that looks like in practice:
Designers Think About It from Day One
In an accessibility culture, designers don't finish a mockup and then ask someone to "check if it's accessible." They consider focus order when they lay out a page. They annotate their designs with heading levels and landmark roles. They think about what a component sounds like, not just what it looks like. They ask, "How will someone who can't see this layout understand the relationship between these elements?"
I have worked with design teams where this was second nature, and the difference in the final product was staggering. Fewer retrofits. Fewer arguments in code review. And fundamentally better experiences for everyone, not just people with disabilities.
Developers Write Semantic HTML by Default
In an accessibility culture, developers reach for a <button> before they reach for a <div onclick>. They use native form elements. They understand that a <nav> is not just a styling hook — it is how my screen reader lets me jump directly to the navigation. They don't override the browser's built-in accessibility because they've learned, often the hard way, that reimplementing something the browser already does well is where most accessibility failures begin.
This is not advanced knowledge. It is foundational. But in organisations that treat accessibility as a checklist, developers never learn it because no one teaches it until the audit findings arrive.
QA Includes Assistive Technology in Their Test Plans
In an accessibility culture, quality assurance does not mean "it works in Chrome on a MacBook." Test plans include keyboard-only navigation. They include screen reader testing with NVDA or JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android. They include zoom at 200% and 400%. They include high contrast mode.
These are not exotic test configurations. They represent how millions of people actually use the web. If your QA team has never opened a screen reader, your product has never been properly tested.
Leadership Measures and Tracks It
In an accessibility culture, leadership does not treat accessibility as a feel-good initiative buried in the corporate social responsibility report. They track it the same way they track performance, security, and uptime. There are metrics. There are dashboards. There are targets. And when those targets are missed, there are consequences — just as there would be if the site went down or a security vulnerability went unpatched.
I have seen organisations transform their accessibility posture within a single year, and in every case, the turning point was the same: someone with real authority decided it mattered and started asking for numbers.
Signs Your Organisation Treats Accessibility as a Checklist
After sixteen years of walking into organisations at every stage of their accessibility journey, I can usually tell within the first meeting whether accessibility is cultural or cosmetic. Here are the red flags:
- Accessibility is only discussed before audits or launches. If the word "accessibility" only enters the conversation when an audit is scheduled or a major release is approaching, it is not embedded in the process. It is an afterthought being dressed up as due diligence.
- There is no accessibility champion, team, or clear owner. When I ask "Who is responsible for accessibility here?" and the answer involves a long pause and several people looking at each other, I know exactly where things stand. Accessibility without ownership is accessibility without accountability.
- Remediation is always "next sprint." I have heard this phrase more than any other in my career. Critical accessibility issues get logged, prioritised as important, and then perpetually deferred because there is always something more urgent. There is always a feature that someone with decision-making power cares about more.
- The accessibility budget is zero until a legal threat arrives. Nothing reveals an organisation's actual priorities like its budget. If accessibility only gets funded in response to a legal notice or a regulatory deadline, the organisation is not investing in accessibility. It is paying to make a problem go away.
- Accessibility knowledge lives in one person. If your entire accessibility capability depends on a single individual — and when that person is on leave, nothing gets reviewed — you do not have an accessibility practice. You have a single point of failure.
How to Shift from Checklist to Culture
The good news is that the shift is possible. I have seen it happen. It is not fast, it is not easy, and it requires sustained commitment. But the organisations that make this shift don't just produce more accessible products — they produce better products overall.
Start with Awareness, Not Training
Most organisations jump straight to training: "Let's teach our developers WCAG." This almost always fails, because training without context creates compliance-focused thinking, which is exactly the problem we are trying to solve.
Start with awareness instead. Let people experience what inaccessibility feels like. Have them try to complete a task on their own product using only a keyboard. Let them hear what a screen reader actually says when it encounters their checkout flow. Show them videos of real users struggling with interfaces that "passed" an automated audit.
When people understand why accessibility matters — not as a legal obligation, but as a fundamental quality of good design — the training that follows lands completely differently.
Embed Accessibility into Design Systems
If your organisation uses a design system or component library, that is the single most leveraged place to invest in accessibility. When the base components are accessible — when the buttons, form fields, modals, and navigation patterns all have correct semantics, keyboard support, and ARIA built in — every team that uses those components inherits that accessibility by default.
I have seen organisations reduce their audit findings by more than half simply by investing in their design system's accessibility. The maths is straightforward: fix it once at the component level, and every product that uses that component benefits.
Include People with Disabilities in Testing
I cannot overstate this. No amount of expert review fully replaces the insight that comes from watching someone who uses assistive technology every day interact with your product. Their workarounds, their frustrations, their expectations — these are things you cannot learn from a guideline or a checklist.
This does not need to be expensive or complicated. Even a small, regular cadre of testers with different disabilities and assistive technology setups will surface issues that your internal team simply cannot see. Pay them fairly. Include them early. Listen to what they tell you, especially when it is uncomfortable.
Make Accessibility a Shared Responsibility
Accessibility is not one person's job. It is not the "accessibility team's" job. It is everyone's job, the same way security is everyone's job and performance is everyone's job. Designers own it in the design phase. Developers own it in the build phase. QA owns it in the testing phase. Product managers own it in the requirements phase. Leadership owns it in the prioritisation phase.
When accessibility is distributed this way, it stops being a bottleneck. It stops being the thing that one overwhelmed specialist reviews at the end, when it is too late to make meaningful changes. It becomes part of the fabric of how work gets done.
The Human Cost of Checkbox Accessibility
I want to be direct about what is at stake when organisations treat accessibility as a checkbox exercise, because the consequences are not abstract. They are felt by real people trying to do real things.
I have tested an online job application portal where the submit button was completely invisible to my screen reader. The application form itself was technically accessible — every field had a label, every required field was marked. But the button to actually submit my application was a custom component built with <div> elements and JavaScript click handlers. It had no role, no accessible name, nothing. The automated audit flagged zero issues on the form page. A compliance report would have called it conformant. And a blind person trying to apply for a job simply could not.
I have tested a healthcare appointment booking system where the calendar date picker worked perfectly with a mouse. With a keyboard, it was impossible to navigate. I could not select a date. I could not book an appointment. The system met colour contrast requirements and had proper heading structure. By the numbers, it was largely compliant. In reality, it locked me out of scheduling my own medical care.
I have tested e-learning platforms where the course content was technically marked up with proper headings and lists, but the video player had no keyboard controls and no captions. The quizzes used drag-and-drop interactions with no keyboard alternative. A student with a disability could enrol, log in, and see the course catalogue — all "accessible." But they could not actually learn.
Accessibility Is Not About Perfection
I want to close with something I tell every organisation I work with, because I think it is the most important thing I can say on this topic.
Accessibility is not about building a perfect product. No product is perfectly accessible, just as no product is perfectly secure or perfectly performant. There will always be edge cases. There will always be something you missed. There will always be a user whose setup or needs you did not anticipate.
That is not the point.
The point is intent. The point is that when your team sits down to build something, accessibility is in the room from the start — not as a constraint, but as a value. The point is that when an issue is found, it gets fixed promptly, not because a legal notice forced it, but because your team genuinely does not want anyone to be excluded from using what they built.
The point is continuous improvement. Ship, learn, listen, improve. Test with real people. Measure your progress. Celebrate your gains. Acknowledge your gaps honestly and work to close them.
The organisations I have seen do this well are not the ones with the biggest budgets or the most sophisticated tools. They are the ones where someone — often just one person at first — refused to accept that a passing audit score meant the job was done. They pushed for more. They asked harder questions. They brought in people who could tell them what the experience was really like.
That is the shift from checklist to culture. It does not happen in a sprint. It happens over months and years of consistent, deliberate effort. But when it takes hold, it changes everything — not just for people with disabilities, but for everyone who uses what you build.
If your organisation is ready to make that shift, or if you are the one person trying to push for it from the inside, I would welcome that conversation.