Accessibility is cheapest in the design file

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's 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 like that. Most 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 could have made a different call at no cost.

Designers don't need to become accessibility specialists for this. About six decisions account for most of the findings. All of them are design decisions, and all of them are nearly free at the point they're made.

Contrast is a palette decision, not a CSS one

A brand palette either has enough contrast or it doesn't, and that's settled long before anyone writes 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 occur in practice (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, and it fixes the problem for good.

It's rarely the primary colour that fails. Primaries tend to be strong. The failures are in 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 darkening your brand colour without saying. Some studios adjust the palette. Others decide a particular pairing will only ever be used at large sizes, where the threshold is lower, and we go with that. Either is fine. Changing your colours without telling you is not.

Focus order is layout

Keyboard focus and screen readers both 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), 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 arrange the components in an order that works both ways. The cases where visual and reading order need to differ are rare, and when they come up they're solvable, cheaply at the design stage and expensively afterwards.

Related: 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 one undifferentiated stack of divs doesn't. 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 easy to forget, because with a desktop mouse they feel fine.

Almost nothing in an accessibility audit is a coding problem. It's a list of design decisions, found late, by someone expensive.

Forms are where it matters most

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 where a user is trying to do something rather than read something.

The design decisions there: 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 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 worse to use for everyone, and it fails outright for anyone using assistive technology.

Headings are structure, not sizes

A heading level communicates hierarchy and a heading size communicates emphasis. They're related but they aren't 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. In practice that means: contrast checked against your palette and reported back before we build; designed focus states on everything interactive; 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 instead of repeating the filename.

None of that is exotic, and all of it is much cheaper than the alternative, which is doing it in week nine while somebody asks whether it's really necessary.

In the UK this is law, not best practice

For a large group of clients this stops being a quality argument and becomes a legal one, and it's worth knowing the specifics before a procurement document lands.

The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 require WCAG 2.2 AA. They apply to central government, local government and some publicly funded charities, and websites have been in scope since September 2018.1

Two obligations get overlooked. First, an accessibility statement has to be published and kept current, and if you're claiming something is a disproportionate burden, that claim has to be documented with an assessment behind it. Second, it is enforced: by the Equality and Human Rights Commission in England, Scotland and Wales, and the Equality Commission for Northern Ireland, through investigations, unlawful act notices and court action.1

WCAG 2.2 itself added nine success criteria over 2.1, weighted towards users with cognitive disabilities and people navigating by keyboard or touch.2 Several are, again, design decisions: visible focus appearance, target size, and not making somebody remember information from a previous step.

The commercial argument, since there always is one

Even outside the public sector, large enterprises increasingly ask for a statement of conformance during procurement, sometimes as a tick-box and sometimes as a requirement with a named contact. A studio that can answer that 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 lot of people can't use badly built websites and that's reason enough. But in our experience the procurement argument is the one that moves budgets, so it's worth having both.

Accessibility is a set of small decisions made in the right order, most of them by the designer and most of them free. It isn't a phase at the end.