What 'Good Enough' Accessibility Actually Costs You Later

There's a version of accessibility work that feels like real progress and often isn't: a sprint where a few components get ARIA labels added, a handful of the worst contrast failures get fixed, one or two forms get proper error handling - real work, done by people who cared about it, that moves a product's accessibility score up and gets reported internally as meaningful progress. It usually is progress, measured against doing nothing. What it's less often measured against is the alternative that would have served the same users better: a smaller amount of work, applied evenly, everywhere.

Partial implementation has a recognizable shape once you've seen it a few times. Some interactive elements get a proper accessible name and some don't, depending on which sprint touched them last. Contrast gets corrected on the pages that happened to get audited and left alone everywhere the audit didn't reach. One team's forms announce validation errors to a screen reader properly, because that team built theirs after the pattern was documented, while an older form built before that documentation existed still relies on a generic error summary nobody can locate without hunting. None of these gaps are visible to a sighted user glancing at the product. Every one of them is a landmine for someone navigating with assistive technology.

The reasoning behind shipping this way is completely understandable from inside a normal roadmap. Nobody gets unlimited time to fix accessibility everywhere at once, priorities get set by whatever an audit flagged as most severe or whatever a team happens to be touching this quarter, and shipping the fixable 80% now feels obviously better than waiting for the resources to do all of it properly. In isolation, each individual fix is a genuine improvement. The mistake is assuming the sum of scattered improvements behaves the same way the improvements do individually.

It doesn't, because assistive technology users don't experience a product one component at a time - they build a working mental model of how the whole thing behaves and rely on that model to move quickly. A screen reader user who's learned that headings in this product reliably mark section boundaries, that buttons reliably announce what they do, that errors reliably get read aloud, moves through the interface with real confidence, checking less as they go because the pattern has proven itself reliable. That confidence is exactly what a partial rollout destroys, because the model that worked on one screen quietly stops applying on the next, with no warning that it's about to.

Picture an e-commerce site where the product browsing and listing pages were rebuilt last year with real accessibility care - every filter has a clear label, every product card announces its price and availability correctly, keyboard navigation moves in a sensible order. Checkout, added in a rush before a deadline nobody wanted to move, never got the same treatment. A screen reader user shops confidently through the entire browsing experience, having correctly learned to trust the interface, and then hits checkout, where every assumption that worked a minute ago stops holding: fields with no programmatic labels, an error state that changes a border color and nothing else, a submit button that doesn't announce what happens after it's pressed. The damage isn't contained to checkout. It retroactively makes every earlier interaction feel less trustworthy, because the user now has no way to know which parts of the site are safe to assume and which aren't.

This is the part that's counterintuitive: a product with no accessibility work done anywhere is, in a narrow but real sense, easier to navigate than one with accessibility work done inconsistently. A sophisticated assistive technology user develops working heuristics for generic, unlabeled markup - it's a known, if degraded, experience, and expectations calibrate to it quickly. What that same user can't build a reliable heuristic for is a product that behaves properly in some places and not others, unpredictably, with no visual signal marking the difference, because the entire value of a heuristic is that it holds consistently, and this specifically denies them that.

It's worth taking the obvious counterargument seriously: isn't partial accessibility still strictly better than none, just by definition, since real users are helped in the places it was actually implemented? In a narrow, component-by-component accounting, yes. But that accounting misses what inconsistency does to trust over the scope of an entire product. A user who gets burned by unpredictable behavior on one part of a site doesn't discount just that one part - they downgrade their trust in the whole thing, verify everything more slowly going forward, or in the worse case, disengage entirely and go elsewhere. That's a worse outcome than a user who correctly calibrated low expectations from the very first screen and navigated accordingly the whole way through.

The organizational root cause is usually the same one behind most patchwork accessibility work: it gets treated as a queue of tickets, prioritized and fixed under whatever pressure created the queue in the first place - an audit finding, a complaint, a compliance deadline - rather than as a standard that's supposed to apply evenly across the whole product regardless of which team or sprint happens to be looking at it. Tickets get closed in whatever order capacity allows, which has nothing to do with which parts of the product a real assistive technology user will actually encounter in sequence, and everything to do with which team had room in their sprint that quarter.

The realistic alternative isn't 'do everything, perfectly, immediately' - that's rarely available to any real team under real constraints. It's choosing a smaller set of standards and holding them everywhere, rather than a longer list held nowhere consistently. A team might commit to exactly three things across the entire surface of the product: every interactive element gets a real accessible name, every flow is fully operable by keyboard, and every error gets announced the same documented way regardless of which screen it appears on. That's a shorter list than most audits produce, and enforcing it everywhere produces a more trustworthy, more navigable product than a much longer list of fixes applied to less than half the surface.

The cost math makes the case even without appealing to user trust directly. Retrofitting inconsistent accessibility work later requires someone to first figure out what's actually implemented, correctly, versus what merely looks implemented at a glance - auditing not just for missing features but for silent inconsistency scattered unpredictably across a codebase built by different teams at different times under different pressures. That discovery work alone often costs more than either doing it consistently from the start would have, or committing early to a smaller, fully consistent scope. Fixing scattered gaps is expensive precisely because finding them all is expensive, in a way that fixing one known, bounded, evenly-applied standard never is.

None of this argues for doing less accessibility work. It argues for being honest about what 'progress' actually means when it's uneven. A product that's fully consistent about a modest set of commitments serves real users better, and costs less to maintain and eventually extend, than a product that's inconsistently thorough about a much longer list. The choice most teams under real deadline pressure are actually making isn't between doing accessibility well and doing it partially - it's between a smaller promise kept everywhere and a bigger promise kept nowhere reliably, and the second one, however much better it looks in a sprint retro, tends to cost more before it ever pays anything back.