Accessibility is cheapest in the design file
Contrast, focus order and target size are design decisions. Made in Figma they cost nothing. Made after a client's audit they cost a fortnight.
Accessibility usually enters a project as a PDF from the client's procurement team, four weeks before launch, written against a standard nobody on the project has read. At that point it is remedial work against a deadline, it feels like an imposition, and somebody has to be told their budget has moved.
Almost none of it needed to be that. The overwhelming majority of what an audit finds on a marketing site was decided in the design file, months earlier, by someone who wasn't thinking about it — and who could have made a different decision at no cost whatsoever.
This isn't an argument that designers should become accessibility specialists. It's an argument that about six decisions account for most of the findings, all six are design decisions, and all six are nearly free at the point they're made.
Contrast is a palette decision, not a CSS one
A brand palette either has sufficient contrast or it doesn't, and that is settled long before anyone writes a line of CSS. The expensive version of this conversation happens after launch, when an audit reports that the accent colour fails against the background it was always going to sit on, and the only remedies left are changing the brand or changing every button.
The cheap version happens while the palette is still moving. Check the pairs that will actually occur — accent on background, body text on background, text on the accent, everything on the dark section — and adjust by a few percent of lightness where they fail. Nobody notices the adjustment. It fixes the problem permanently, for every page that will ever exist.
The thing worth knowing is that it's rarely the primary colour that fails. Primaries tend to be strong. It's the secondary tints, the muted greys used for captions and metadata, and the accent-on-dark pairing that nobody checked because the dark section arrived late.
We check every pairing in a palette before we build, and we tell you which ones fail rather than quietly darkening your brand colour and hoping you don't notice. Some studios adjust the palette. Some decide a particular pairing will only ever be used at large sizes, where the threshold is lower, and we honour that. Both are fine. Silently changing your colours is not.
Focus order is layout
Keyboard focus follows source order. Screen readers follow source order. If a design places something visually first that has to come later in the markup — a sidebar that sits left but reads as supplementary, a card whose title appears below its image but should be announced first — then the visual order and the reading order disagree, and reconciling them means changing structure that has already been built and signed off.
Designed with it in mind, it costs nothing, because you simply arrange the components in an order that works both ways. The cases where visual and reading order genuinely need to differ are rare, and when they occur they're solvable — but they're solvable cheaply at the design stage and expensively afterwards.
The related one is skip links and landmarks. A page with a clear header, main, and footer structure gives keyboard users a way to move around. A page built as a single undifferentiated stack of divs does not. That's a decision about how the design is structured, and it's invisible in the comp.
Target size is spacing, which you already have opinions about
Small tap targets set close together are a spacing decision, and spacing is something the design has already decided. Raising a row of links to a usable size after the fact means reflowing components that were approved, which means another review round, which means the deadline.
The usual offenders are footer link lists, social icon rows, pagination, and anything in a compact table. None of them are hard to design properly. They're just easy to forget, because on a desktop mouse they feel fine.
Almost nothing in an accessibility audit is a coding problem. It's design decisions, discovered late, by someone expensive.
Forms are where it actually matters
Everything above is about a marketing site. The moment a form appears — a contact form, a booking flow, an application — the stakes change, because a form is the point at which a user is trying to accomplish something rather than read something.
The design decisions there are: does every field have a visible label, or does it rely on placeholder text that vanishes when you start typing? Are errors described in words next to the field, or communicated only with a red border? Is the required-field convention explained anywhere? Is there a state for "this has been submitted and something is happening"?
Placeholder-as-label is the single most common accessibility failure we inherit, and it's purely a design decision. It looks cleaner in a comp. It's substantially worse to use, for everyone, and it fails outright for anyone using assistive technology.
Headings are structure, not sizes
A heading level communicates hierarchy. A heading size communicates emphasis. They're related but they are not the same thing, and designs routinely conflate them — a section that is structurally a sub-heading gets set large because it needs weight on the page, and the build either matches the design and breaks the document outline, or matches the outline and doesn't look like the comp.
The fix is to decide these separately: what level is this in the document, and how big should it look? Once those are separate questions, both answers can be right. We'll ask this on any design with more than two heading sizes, because guessing has a fifty per cent success rate and the wrong guess is invisible until someone audits it.
What we do on every build
WCAG 2.2 AA as standard, not as an upgrade line on the estimate. Practically that means: contrast checked against your palette and reported back before we build; real focus states on everything interactive, designed rather than defaulted; a sensible heading outline; keyboard paths that work end to end, including any menu or modal; form errors described in text; motion that respects a reduced-motion preference; and images with alt text that says something useful rather than repeating the filename.
None of that is exotic. All of it is substantially cheaper than the alternative, which is doing it in week nine while somebody asks whether it's really necessary.
The commercial argument, since there always is one
Public sector clients in the UK have accessibility obligations, and large enterprises increasingly ask for a statement of conformance during procurement — sometimes as a tick-box, sometimes as a genuine requirement with a named contact. A studio that can answer that question calmly, at pitch stage, without a panicked remediation phase, wins work from studios that can't.
There's a better argument, which is that a meaningful number of people can't use badly built websites and that this is reason enough. But in our experience the procurement argument is the one that moves budgets, so it's worth having both.
The point of all of this is that it isn't a phase. It's a set of small decisions made in the right order, most of them by the designer, most of them free.