It is easy to point at the developer who shipped the contrast failure. It is much harder, and much more useful, to ask why the design system allowed that color pair to exist in the first place, why no review gate caught it before launch, and why the roadmap never had room scheduled for the fix. None of those three questions have a developer sitting at the other end of the answer.
Walk into almost any post-incident conversation after an accessibility complaint lands, and it tends to start in the same place: which engineer touched that file last. It is the easiest question to ask and the least useful one to answer. By the time a broken component reaches production, the developer who wrote the code made the smallest decision in a long chain of decisions that got it there. Someone chose the color tokens. Someone approved the design. Someone decided the ticket didn't need an accessibility review. Someone set the sprint deadline that made "we'll fix it later" the only realistic option. None of those someones were the person typing the code.
The Stat: The US DOJ's 2024 Title II rule sets ADA compliance deadlines for state and local government websites at the organizational level, not the individual task list: April 24, 2026 for entities serving 50,000 or more residents, and April 24, 2027 for smaller entities. (Source: US Department of Justice)
The question that gets asked, and the one that should
"Who broke this" is a debugging question. It has a satisfying, specific answer, and it lets everyone else in the room feel like the problem has been contained to one desk. But accessibility failures are almost never the output of a single bad decision made by a single person. They're the output of a system that never made room for the right decision to be made at all.
Consider the contrast failure from the opening. The realistic chain of events looks something like this: a designer picked a brand color that looked good in a mockup but was never checked against WCAG's contrast ratio guidance. That color got added to the design system as a token with a friendly name like "brand-secondary." A developer pulled that token into a component because that's what the design system told them to use. No one on the review side flagged it, because the pull request template didn't ask about contrast and the QA checklist didn't test for it. The ticket shipped, on schedule, exactly as designed.
At every single one of those steps, someone made a reasonable decision given the information and incentives they had. The developer did not fail. The system around the developer never asked the question.
Three places responsibility actually lives
Priorities: the roadmap decides what gets fixed
A developer can flag an accessibility issue in a code review comment. They cannot unilaterally decide it's worth a sprint's worth of time to fix instead of the next feature on the roadmap. That call belongs to whoever owns the roadmap, and if accessibility remediation never gets prioritized against feature work, it will always lose, regardless of how many individual developers care about getting it right.
Process: review gates decide what ships
If the definition of done doesn't include an accessibility check, nothing gets caught before release no matter how skilled the engineering team is. Review gates, QA checklists, and design handoff criteria are process artifacts. They're written and owned by whoever runs the development process, not by the person implementing an individual ticket.
Legal exposure: it sits with the organization, not the contributor
This is the part that tends to get missed until it's expensive. The EAA (Directive (EU) 2019/882), in application since 28 June 2025, places its obligations on the EAA's official EU implementation page squarely on the businesses placing covered products and services on the EU market. That is a governance-level responsibility by design. No regulator sends a compliance notice to a specific engineer. It goes to the organization, because the organization is what made the market-facing decision to ship.
The same logic runs through the W3C's own guidance. The W3C's own WCAG conformance requirements frame conformance as a property of a whole page or process, not something an individual contributor can claim or fail to claim on their own. Conformance is evaluated at the level of what the organization actually shipped, aggregated across every decision that fed into it.
What a developer controls, and what they don't
| Decision | Who actually owns it | What happens without ownership |
|---|---|---|
| Color tokens and component states in the design system | Design and leadership | Developers inherit inaccessible defaults with no way to flag them upstream |
| Definition of done and QA gates | Process/engineering leadership | Accessibility becomes optional, caught only if someone happens to notice |
| Roadmap time allocated to remediation | Product leadership | Known issues stay known and unfixed indefinitely |
| Legal risk acceptance under ADA Title II or the EAA | Executive/legal | The organization discovers its exposure only after a complaint or audit |
| Code that implements the approved design and spec | Developer | This is the one line item a developer can actually be held to |
Look at that table again. Four of the five rows sit above the individual contributor. The fifth is the only one a developer genuinely controls, and it's also the one everyone defaults to blaming.
If you want a broader vocabulary for spotting where these gaps hide before they turn into incidents, read the 11 concepts every product leader should recognize is a useful next stop. It's written for the person setting priorities, not the person implementing them.
What leadership needs to own directly
- Accessibility criteria written into the definition of done, not treated as a stretch goal
- Design system tokens and component states audited for contrast and keyboard behavior before developers ever touch them
- Roadmap capacity reserved for remediation work, not squeezed in only "if there's time"
- A named owner for accessibility above the individual contributor level, with actual authority over priorities
- Legal and compliance briefed on which ADA Title II and EAA deadlines apply to the organization, and when
- A review gate that checks for accessibility before code ships, not after a complaint arrives
None of these are engineering tasks. Every one of them is a leadership decision about how work gets planned, reviewed, and resourced.
Getting the room to agree
The hardest part usually isn't identifying which of these gaps exist. It's getting the room full of stakeholders who don't write code to agree that the fix belongs on their plate, not the engineering team's. If that's the wall you're hitting, get executive buy-in for the process changes this actually requires walks through how to frame that conversation so it lands as a business decision instead of a technical request.
Fixing one contrast ratio takes a developer an afternoon. Fixing the roadmap, the review gates, and the legal risk posture that let it ship broken takes a leader deciding it matters enough to change how the team works. If you'd rather build that into your process than keep patching one ticket at a time, we'd like to help you build accessibility into the process, not just the code. You can reach out through our SaaS accessibility solutions page, or email the team directly at experts@wcag.world if you'd rather just talk it through first.