In short
Treating accessibility as a discrete feature to be added later, rather than a baseline requirement built into every design decision from the start, produces worse outcomes and more expensive retrofits than building it in from the beginning as part of what "done" means for any interface.
The framing problem
When accessibility appears on a roadmap as its own line item — "add accessibility" — the framing itself implies it's an optional enhancement layered on top of an otherwise-complete product, competing for priority against other features. This framing is the root of most accessibility failures, because it treats something that should be a baseline requirement as a nice-to-have that can be deprioritized under deadline pressure.
What treating it as a baseline actually means
Accessible color contrast, keyboard navigability, and screen reader support aren't separate features from the interface itself — they're properties the interface either has or doesn't have, built in through the same decisions that determine its color, layout, and interaction design. A button either has sufficient contrast and keyboard access or it doesn't; there's no separate "accessible version" of it to build later.
Why retrofitting is expensive
Adding accessibility after a product is built, rather than designing it in from the start, usually means revisiting decisions across the entire interface — color choices, focus order, component behavior — that were made without accessibility as a constraint. This retrofit is dramatically more expensive than building the same decisions correctly the first time, in the same way retrofitting performance or security after the fact is more costly than building them in from the start.
The business case beyond compliance
Accessibility work benefits far more users than the narrowest interpretation of "users with disabilities" suggests — clear contrast helps anyone using a device outdoors in bright light, keyboard navigation helps power users and anyone with a temporarily limited ability to use a mouse, clear error messages help everyone regardless of ability. Framing accessibility purely as compliance or as service to a narrow user segment undersells how broadly it improves the product for everyone.
What this looks like in practice
Accessibility checks belong in the same review process as any other design or code review — not a separate audit scheduled occasionally, but a standard part of what "done" means for any component or screen, checked the same way you'd check that a layout doesn't break on mobile.
The cultural shift required
The actual change needed isn't more accessibility-specific tooling or a bigger accessibility team — it's removing the framing that treats accessibility as separable from good design in the first place. Once a team internalizes that an inaccessible interface is simply an incomplete or broken one, not a functioning one missing an optional feature, the practical steps to build accessibly follow naturally from the same care applied to every other design decision.
Reference: the authoritative guidance lives at the W3C Web Accessibility Initiative.
Common questions
Why is treating accessibility as a feature a problem?
It implies accessibility is optional and can be deprioritized, when in practice it's a baseline property of whether an interface actually works, built into the same decisions that determine layout and interaction design.
Is retrofitting accessibility really more expensive than building it in from the start?
Yes — retrofitting usually requires revisiting decisions across the whole interface that weren't made with accessibility as a constraint, which is far more costly than building those same decisions correctly the first time.
Does accessibility only benefit users with disabilities?
No — many accessibility improvements, like clear contrast and keyboard navigation, benefit a much broader range of users and situations, including temporary or situational limitations everyone experiences at some point.
