Accessibility

This site is built to WCAG 2.1 Level AA, and so is every site I build for a client. Below is exactly what that means in practice, what I measured, and what is not finished yet.

Last reviewed: August 20, 2026  ·  Written by the person who built the site, not copied from a template.

The standard

I aim to meet Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA, published by the World Wide Web Consortium. That is the level most public bodies and most accessibility law point at, and it is the level I hold my own site to before I ask anyone to trust me with theirs.

Accessible design is not a feature I sell you separately. It is how the site gets built, and it costs you nothing extra, because doing it properly the first time is faster than retrofitting it later.

What’s built in

Every page on this site does the following, and every client site does too.

  • Real HTML structure. One h1 per page, headings that descend in order with no skipped levels, and proper landmarks, so a screen reader can list the page and jump around it.
  • A skip link. First thing in the tab order on every page, so keyboard users are not forced through the whole menu to reach the content.
  • Visible keyboard focus. A 3px ring with a gap around it, on every link, button and field. The gap is deliberate, not decoration — it is what keeps the ring readable against a coloured button.
  • Every form field has a real label. Visible, permanent, and properly associated. No labels that vanish when you start typing, and no instructions hidden in placeholder text.
  • Errors that say what happened. The message sits next to the field, names the actual problem, and focus moves to the first field that needs fixing. When a form sends successfully, focus moves into the confirmation, so a keyboard or screen reader user is told it worked rather than left guessing.
  • Keyboard-operable menu. The mobile menu opens and closes from the keyboard, reports its own state, and closes on Escape.
  • Drawn icons, not emoji. Emoji render as a different picture on every device and are announced unpredictably. Every mark on this site is drawn, at one consistent weight, and decorative ones are hidden from screen readers.
  • Motion you can turn off. If your system asks for reduced motion, the animation stops. Nothing on this site depends on movement to be understood.
  • Tap targets sized for thumbs, and numbers set in tabular figures so prices line up on the digit instead of drifting.
  • It works without JavaScript. Every page reads, and every phone number and link works, with scripting switched off entirely.

What I measured

Contrast is the accessibility rule most often claimed and least often checked, so here are real numbers. Every text and background pair in this site’s palette was computed before the colours were chosen, not adjusted afterwards until it looked about right.

  • Body text on paper: 14.6:1 — the AA minimum is 4.5:1.
  • Secondary and caption text: 6.4:1 at its lightest.
  • White text on the blue buttons: 10.6:1.
  • The keyboard focus ring against the paper it sits on: 14.6:1.

There are rules written into the stylesheet itself recording which colour is legible on which background and, more usefully, which combinations are forbidden — so a future change cannot quietly undo it. Two colours in this palette are barred from being used as text at all, because measurement said so.

You can check all of this yourself. Every claim on this page is visible in your browser’s developer tools or in any free contrast checker, and the whole site is four files with no third-party scripts to wade through.

Your site, too

Accessibility is standard on every build, not an upgrade. Your site gets the same heading structure, the same visible focus states, the same labelled forms, the same measured contrast, and the same drawn icons.

Where a site needs photographs, I will ask you for real alt text describing what is in the picture, because I cannot write that for you honestly. Where a site embeds something I do not control — a booking widget, a map, a payment page — I will tell you plainly that its accessibility is that company’s, not mine, and I will pick the most accessible option available.

Not finished yet

A statement with no known limitations is a statement nobody has tested. Here is what I know is imperfect on this site today.

  • No dark mode. The site does not yet respond to a system dark-mode preference. It is legible in either setting, but it does not adapt.
  • No formal screen reader audit. The structure is built correctly and checked in code, but I have not yet sat down with NVDA or VoiceOver and worked through every page start to finish. Until I have, I am not going to claim I have.
  • The miniature example layouts are decorative. The small mock websites shown as design examples are hidden from screen readers on purpose — they are pictures of layouts, not content — and the text describing them carries the meaning instead.
  • Wide tables scroll. Where a table is too wide for a phone, it scrolls sideways inside its own box rather than reflowing.

This list gets shorter over time. If you find something not on it, that is worth knowing and I would rather hear it than not.

Report a barrier

If any part of this site is hard or impossible to use, tell me and I will fix it. You do not need to know the technical words for it — “I couldn’t get to the phone number with my keyboard” is a perfectly good bug report.

If you need anything on this site in a different format — large print, plain text, or read to you over the phone — ask and I will send it.

I answer these myself, usually the same day. There is no ticket system and no form to fill out first.