Accessibility Isn't a Checklist You Run at the End¶
Running an accessibility audit shortly before launch is genuinely useful - it catches real, concrete problems. It also guarantees that a meaningful share of what it finds will be expensive to fix, precisely because those issues were baked into decisions made months earlier: a color palette with insufficient contrast that's now used across dozens of components, an interaction pattern built around hover states with no keyboard equivalent, a content structure with no logical heading hierarchy running through every page. Catching these at a final audit means unwinding decisions that are now deeply embedded, instead of making a different decision in the first place.
Color and Contrast Decisions Happen at the Palette Stage, Not Per-Component¶
Contrast ratio problems usually don't originate in one specific screen - they originate in the brand or UI color palette itself, chosen for aesthetic reasons before anyone checked whether the lighter tones in that palette meet contrast requirements against the backgrounds they'll actually be used with. By the time an audit flags low-contrast text, that color is likely already used consistently across the entire product, which turns a palette-stage fix into a much larger, more disruptive one. Checking contrast ratios while the palette is still being chosen - not after it's been implemented everywhere - is a fundamentally cheaper place to catch the same problem.
Interaction Patterns Chosen for Visual Appeal Can Quietly Exclude Keyboard and Screen Reader Users¶
A hover-triggered menu, a custom dropdown built entirely with mouse-driven interactions, a modal with no defined focus order - these get chosen during interaction design for how they look and feel with a mouse, and the accessibility gap (no keyboard equivalent, no logical screen-reader flow) is usually invisible unless someone is specifically testing without a mouse. Considering keyboard and screen-reader behavior at the same time interaction patterns are being designed, rather than as a separate accessibility pass afterward, catches this while the pattern is still just a design decision, not yet built and shipped.
Content Structure and Heading Hierarchy Get Decided During Content and Layout Work¶
A page's heading structure - what's an H1, what's an H2, whether headings are used for genuine structure or just for whatever text happens to look bigger - gets effectively decided during content and visual layout work, long before a screen-reader test would catch a broken hierarchy. A visually-styled "big text" element used in place of a real heading tag looks correct to a sighted user and is functionally invisible as structure to a screen reader, and this kind of gap tends to repeat across every similar page once the pattern is established, rather than being a one-off.
The Cost of Catching an Issue Scales With How Long It's Been Live¶
An accessibility issue caught during design costs a design change. The same issue caught during development costs a code change. The same issue caught after launch, once it's been used as a pattern across dozens of pages or components, costs a much larger retrofit - and that's exactly the point at which a pre-launch-only accessibility process guarantees most issues will be found. Building accessibility consideration into each stage as it happens - palette, interaction design, content structure - doesn't eliminate the need for a final audit, but it changes what that audit is likely to find: smaller, later-stage issues instead of foundational ones.
FAQ¶
Is a pre-launch accessibility audit still worth doing if accessibility is considered earlier too?
Yes - it's still a valuable final check, but it should be finding a smaller, more manageable set of issues rather than being the first point anyone considered accessibility at all.
Who should be responsible for accessibility during early design stages, not just a specialist audit later?
Whoever is making the relevant decisions at each stage - the person choosing the color palette, the person designing the interaction pattern - rather than treating it as solely the responsibility of a dedicated accessibility reviewer who only sees the work once it's finished.
Does designing for accessibility from the start actually take significantly more time?
Less overall time than the alternative, in most cases - a decision made correctly the first time (a palette checked for contrast, an interaction pattern designed with a keyboard equivalent from the start) is faster than designing it once, then redesigning it after a late-stage audit flags the problem.