Accessibility is a design decision, not a checklist

Accessibility is usually treated as a task for the very end of a project — a scan run the week before launch, a list of contrast warnings, a scramble to add some alt text. That approach technically produces a report, but it rarely produces an accessible product. By the time the design is finished and the code is written, the decisions that actually determine whether someone can use the site have already been made — and unmaking them is expensive.

Real accessibility is not a layer you apply at the end. It is a set of choices you make at the beginning, in the design, in the content, and in the structure of the page.

Why the checklist arrives too late

Most accessibility failures are not missing attributes. They are structural. A colour palette chosen for its looks that cannot meet a 4.5:1 contrast ratio. A layout that only makes sense with a mouse. A form that communicates errors purely by turning a field red. A carousel that traps a keyboard user. None of these are fixed by a last-minute pass — they are baked into decisions made weeks earlier, and by launch they are load-bearing.

That is why we treat the relevant WCAG criteria as design constraints, in the same breath as brand and layout, rather than as a quality-assurance step. A constraint you design within costs almost nothing. A constraint you discover afterwards costs a redesign.

What designing for it actually looks like

Building accessibility in from the start is less dramatic than it sounds. In practice it is a handful of habits applied consistently:

• Colour with contrast in mind — every text and interface colour is checked against its background before it enters the palette, not after. If a brand colour fails, we find an accessible variant of it rather than shipping the failing one.
• Semantic structure — real headings, lists, buttons, and landmarks, so the page has meaning a screen reader can convey, not just an appearance a sighted user can see.
• Keyboard-first interaction — every control reachable and operable without a mouse, with a visible focus state, because plenty of people never touch one.
• Errors that explain themselves — messages in text, tied to the field, not a colour change a colour-blind user will miss.
• Content that reads plainly — clear language, descriptive links, and images described for people who cannot see them.

None of this is exotic. It is ordinary craft, applied from the first sketch instead of bolted on at the end.

It is better for everyone, not a minority

The quiet truth of accessibility is that it almost never helps only the people it is nominally “for.” Good contrast helps anyone reading on a phone in bright sunlight. Keyboard support helps power users who never lift their hands from the keys. Clear structure and plain language help everyone skim faster and helps search engines understand the page. Captions help people in a quiet office as much as people who cannot hear.

Designing for the edges reliably improves the middle. An interface that works for someone using a screen reader is, almost without exception, a clearer, calmer, more robust interface for everyone else too.

The legal and commercial floor

There is a hard-nosed case as well. Accessibility is increasingly a legal expectation rather than a nicety, and an inaccessible site quietly turns away a meaningful share of potential customers who simply cannot complete what they came to do. You rarely hear from those users — they just leave. Building for them from the start is far cheaper than the remediation, or the complaint, that eventually forces the issue.

If you are commissioning new work, the useful question is not “will it pass an audit?” but “was it designed to be usable by everyone from the beginning?” The first can be gamed at the end. The second is what actually makes the difference — and it only happens if you decide it at the start.