Design 6 min read

Accessibility is not a checkbox

Accessible design helps everyone, not a minority. The decisions that matter most, why overlay widgets do not work, and how to test your own site free.

Written by Soumitra GhoshFounder & Lead Developer

A sign reading "Inclusive", with accessibility symbols beside it.
On this page
  1. It is not a minority concern
  2. The decisions that matter most
  3. The three mistakes we see most
  4. Removing the focus outline
  5. Placeholder text instead of labels
  6. Light grey body text
  7. Overlay widgets do not fix this
  8. Test your own site in ten minutes
  9. What this costs
  10. The business case, briefly

Accessibility usually arrives late in a project, as a list of things to fix. Treated that way it is expensive, miserable, and produces a site that technically passes and still feels awkward to use.

Treated as a design constraint from the first sketch, it costs almost nothing and makes the site better for everybody. The difference is entirely about when, not how much.

It is not a minority concern

The mental image is a blind person with a screen reader. That person matters, and they are a small part of what this is about.

Accessible design is also for somebody reading on a phone in bright sunshine. For somebody with a hand in a cast, or holding a child. For anyone whose eyes are tired at the end of a long day, anyone on a slow connection, anyone whose first language is not yours, and more or less everybody over forty trying to read small grey text.

Most people are temporarily impaired fairly often. Designing for the edges makes the middle more comfortable, which is why accessible sites tend to be the ones everyone finds easier.

The decisions that matter most

You do not need to memorise the standard. A handful of decisions cover the overwhelming majority of real problems.

DecisionThe ruleWho it helps
Text contrastAt least 4.5:1 against the background, or 3:1 for large textEveryone, especially on a phone outdoors
Tap targetsAt least 24 by 24 pixels, with space around themLarge fingers, unsteady hands, moving vehicles
Focus stylesA clearly visible outline on whatever is focusedKeyboard users, and anyone whose mouse has died
HeadingsOne h1, then h2s and h3s in order, describing structureScreen readers, and your search ranking
Alt textDescribe the meaning; leave decorative images emptyScreen readers, and anyone on a failed connection
LabelsEvery field has a real label, not just placeholder textEveryone, the moment they start typing
Colour aloneNever the only way information is conveyedColour-blind users, roughly one man in twelve
Link textSays where it goes, not “click here” or “read more”Anyone scanning, and anyone listening to a list of links

The three mistakes we see most

Removing the focus outline

Designers dislike the browser’s default ring and delete it with a single line of CSS. For anyone navigating by keyboard the site immediately becomes unusable — they are tabbing around with no idea where they are, like using a mouse with an invisible cursor.

If the default is ugly, design a better one. Do not remove it. This is probably the single most damaging line of CSS in common use.

Placeholder text instead of labels

It looks tidy in a mockup. Then the user starts typing, the placeholder disappears, and they can no longer see what the field was for. It is worse on a long form, worse again for anyone who gets interrupted mid-task, and worst of all on a form somebody is filling in for the first time.

Placeholders are for examples — “e.g. 07700 900000” — not for names.

Light grey body text

Pale grey on white looks refined on a calibrated monitor in a dim studio. On a phone in a car park it disappears entirely. Contrast is the most commonly failed requirement and the easiest to check, and it is one where designers’ working conditions are least like their readers’.

Overlay widgets do not fix this

You will be offered a script that promises to make any site accessible overnight for a monthly fee. They do not work, and they cannot — a script has no way of knowing what your photograph means, or what your unlabelled icon button does.

Disability advocacy groups have been vocal about this for years. Some of these products actively interfere with the screen readers their intended users have already configured to their own preferences, which makes the experience worse rather than better. Sites using them have still faced legal complaints.

There is no substitute for building it properly, and building it properly is cheaper than the subscription.

Test your own site in ten minutes

No tools, no expertise, no budget.

  • Put the mouse away. Tab through a page using only the keyboard. Can you reach everything? Can you always see where you are? Can you complete the contact form and submit it? This single test finds more real problems than any scanner.
  • Zoom to 200%. Does the layout cope, or does text start overlapping and buttons slide off the edge?
  • Go outside with your phone. Light grey on white vanishes in sunlight, and a surprising number of design decisions do not survive this test.
  • Turn the sound on and the screen off. Use the screen reader built into your phone for two minutes. It is uncomfortable and it is instructive.
  • Run an automated check. Lighthouse is built into Chrome; the axe browser extension is free.

Automated tools catch perhaps a third of real issues. They will find a missing alt attribute; they will not notice that the alt text says “image1.jpg”, or that your form’s error messages are announced but never associated with the field that caused them. The keyboard test finds what the scanners miss.

What this costs

Designed in from the start: close to nothing. Choosing a darker grey costs the same as choosing a lighter one. Writing a label takes as long as writing a placeholder.

Retrofitted onto a finished site: considerably more, because the problems are usually structural — a heading order that reflects visual size rather than meaning, a navigation that only works on hover, a form built out of unlabelled divs.

This is the whole argument for treating it as a constraint rather than a phase.

The business case, briefly

Accessible sites are better structured, which search engines reward. They work better on phones, because the same decisions help both. They are legally safer as requirements tighten in more countries. And they do not turn away paying customers for no reason.

But the real argument is simpler than any of that: somebody wanted to use your website and could not. Everything else is a footnote.

We build to these standards by default rather than as a line item — it is part of what designing a site properly means. If you are unsure where yours stands, send us the address and we will tell you.

Written by

Soumitra Ghosh Founder & Lead Developer

UitoCode is run by Soumitra Ghosh, a frontend developer and UI/UX designer with 5+ years of experience building websites for startups and growing businesses.

Keep reading

Let’s talk

Have a website project in mind?

Tell us what you’re building and what it has to achieve. You’ll get a straight answer on whether WordPress or Webflow fits, and what it would take to do it properly.

What happens next

  1. Send a short brief through the contact form
  2. Hear back personally within two working days
  3. Get a written proposal with scope, timeline and cost