← Back to blog

Accessibility is a design decision, not a checklist

Close-up of code on a dark screen

Ask a developer what “accessible” means and you’ll get a checklist: contrast ratios, alt text, focus states. All true, all necessary — and none of it sufficient. Accessibility is a design decision that starts long before the code, and it makes the work better for everyone, not just the people who need it.

Accessible design is better design

Nearly every accessibility requirement improves the experience for every user. A text size that’s comfortable for someone with low vision is comfortable for someone reading on a train. A label on a form field helps a screen-reader user and anyone using autocomplete. Strong contrast survives a sunny day and a cheap projector.

When we design accessibly from the start, we’re rarely compromising. We’re usually just designing properly.

Where we begin

We start with semantics — the structure that lets assistive technology make sense of a page. That means:

  • One h1 per page, with a sensible heading hierarchy.
  • Real buttons and links, not divs wearing a costume.
  • Labels on every form field, in a position that survives any layout.
  • Keyboard support for anything interactive.

None of this shows up in a screenshot, which is exactly why it’s so often skipped. It’s also the cheapest work to do correctly and the most expensive to retrofit.

Contrast and colour are both

The usual focus is contrast ratios, and rightly so — but colour-blindness means contrast alone isn’t enough. We never rely on colour to carry meaning on its own. A “delete” button that’s red and labelled “delete” is fine; a red row that’s the only way to signal an error is not.

Reduced motion is a preference, not a mode

The same respect applies to motion. Our prefers-reduced-motion handling isn’t a light switch that turns off animations — we design so that meaning never depends on motion in the first place. If a transition disappears, the information still lands.

Test with people, not just tools

Automated checkers catch maybe forty percent of issues. The rest need humans: a keyboard-only pass, a screen-reader pass, and ideally a session with real users who rely on assistive technology. We build that into every project’s timeline, and we recommend our clients watch one of those sessions. It changes how they brief forever.

The honest cost

Doing this properly takes a little longer and costs a little more. What it saves is bigger: legal risk, reputational damage, and the quiet decision by real people to just not use your site because it was too difficult.

And it’s the right thing to do — which, we’ve found, turns out to be good business too. Every client we’ve built for in an accessible way has come back with the same comment: the work feels better for everyone.

If you’d like to audit a site you’re running, get in touch — we’re happy to point you at the highest-impact fixes first.