Accessibility is a Culture Problem, Not a Code Problem
This post serves as a strategic follow-up to "Accessibility 101", moving from the technical how to the organizational why. It identifies the root cause of inaccessible web products not as a lack of skill, but as a failure of culture. By connecting the pressure of deadlines (the "Boss" mentality) with the rush to ship MVPs, The post illustrates how accessibility gets deprioritized. The conclusion is a call to action for leadership: advocacy isn't just about writing WAI-ARIA tags; it's about building a company culture that refuses to ship broken experiences.
In my last post, Accessibility 101, we talked about the "How" semantic HTML, ARIA labels, and the technical backbone of an inclusive web. But if I’m being honest, the code is actually the easy part.
We have the documentation. We have WCAG guidelines. We have automated testing tools like Lighthouse. Yet, the vast majority of the web remains hostile to users with disabilities.
Why? Because you cannot fix with code what is broken in culture.
The "MVP" Trap I’ve talked before about Minimum Viable Products (MVPs). In the rush to launch, we often ruthlessly cut features to hit a deadline. Too often, accessibility is categorized as a "Phase 2" feature.
Let’s be clear: Accessibility is not a "feature" you sprinkle on top of a finished cake; it is the flour. You cannot bake the cake and then decide to add the flour later. If your product is not accessible, it is not "Viable." It is incomplete.
The Developer vs. The Deadline I have seen many brilliant developers who want to write semantic code. They know that a <button> is better than a <div>. But they are working in environments where "shipped" is valued more than "sound."
When a Manager or a "Boss" (as opposed to a Leader) asks, "Why is this taking so long?", the developer is forced to choose between doing it right and doing it fast. In a culture that prioritizes speed over quality, accessibility is the first casualty.
Empathy at the Top This brings me back to Leadership. True inclusive design doesn't start in the text editor; it starts in the boardroom.
- Designers need to include color contrast checks before a pixel is finalized.
- Product Managers need to include accessibility acceptance criteria in user stories.
- QA Teams need to test with screen readers, not just check functionality.
- Stakeholders need to understand that excluding 15% of the population is bad business.
We need to stop treating accessibility as a checklist for compliance (avoiding lawsuits) and start treating it as a metric of quality. A bug that prevents a blind user from checking out is a "Critical Blocker," not a "Low Priority" ticket.
As advocates, our job isn't just to write better code. It's to build a better culture—one where we defend the user who isn't in the room.
- Flour, Not Frosting: Accessibility is often treated as a "Phase 2" add-on. I argue it is a fundamental ingredient (the flour), not a decoration. You cannot bake a cake and add the flour later; similarly, you cannot build an MVP and "add" accessibility later without breaking the foundation.
- Viable means Usable: Referencing the concept of the Minimum Viable Product (MVP), I argue that if a product excludes human beings due to disability, it fails the definition of "Viable."
- The Compliance Trap: "Bosses" view accessibility as a legal checkbox to avoid lawsuits. "Leaders" view it as a quality metric. Shifting this mindset is the only way to empower developers to take the time needed to write semantic code.
- The Chain of Responsibility: It is unfair to blame developers for bad accessibility if Designers, Product Managers, and QA teams aren't also held accountable. Inclusive design must be embedded in the user story before a line of code is written.
