Accessibility as a design constraint

Accessibility is almost always presented as an obligation: a standard to satisfy, a list to tick, a legal risk to cover. That framing is accurate and it is demoralising. It puts the subject on the side of compliance, therefore of inspection, therefore of the end of the project. We handle it at the other end, while the work is being drawn, and for a fairly selfish reason: accessibility constraints produce better interfaces.

A constraint, in the sense that a format is one

A designer handed a square poster format does not complain about an attack on their freedom. The format steers decisions, removes options and speeds the work up. Accessibility rules behave the same way, provided they arrive early.

A minimum contrast of 4.5 to 1 on body text immediately rules out light grey on white, the shortcut everyone has used at some point to make a mockup feel airy without dealing with its hierarchy. You then have to build hierarchy some other way: by size, by weight, by space. Those three levers produce sturdier layouts than a gradient of greys.

In the same way, having to signal a state by something other than colour alone forces you to draw real states. A field in error no longer just turns red: it gets an icon, a written message and a stable position on the page. The interface improves for everyone, including the visitor in a hurry who is not reading the nuances.

What we decide while drawing

• Reading order. We fix it on the mockup, before build. A side column placed on the right visually but read second in the document has to be a choice, not an implementation accident.

• Touch targets. 44 pixels a side minimum, measured on the mockup. That rule has a direct effect on density: it rules out eleven-icon toolbars and forces a decision about what is genuinely frequent.

• Focus. We draw the focus indicator as part of the design system, exactly like a button. Without that, it ends up deleted for being ugly, which makes the site unusable from a keyboard.

• Labels. A button called "Learn more" repeated twelve times on a page is unreadable for anyone moving from link to link. Naming actions by their destination is a writing discipline, not a technical correction.

• Motion. Every animation is drawn together with its reduced variant. That has made us drop several effects we liked but which had no acceptable motionless version, which was already the sign that they carried information available nowhere else.

The real cost, and where it sits

Picked up late, accessibility is expensive: states have to be redrawn, colours already approved by the client revisited, delivered components rewritten. We have seen that rework account for up to a third of a build budget.

Handled during design, it costs almost nothing extra, because it does not add to the work: it constrains it. The genuine extra cost sits in two places, and it is honest to name them. Testing with assistive technology takes time and a skill that cannot be improvised. And some rich components, a date picker or a filterable table, demand an implementation effort that nothing replaces.

What we refuse to do

We do not install automatic overlays. Those tools promise compliance through one line of script; they move the problem and often degrade the experience of the very people they claim to serve.

Nor do we aim at a score. An automated audit covers a limited share of the criteria, and a site with a perfect rating can still be impossible to use from a keyboard. We prefer to hand over a list of journeys we actually tested, with what works and what is still to be fixed.

Accessibility is not a layer applied to a finished drawing. It is one of the rules of the drawing, and the projects where we treated it that way are also the ones whose interfaces have aged best.