Accessibility statement

Our commitment

We build digital products for a living, so an inaccessible website of our own would be a fairly direct statement about how seriously we take the standard we sell. This site is designed and built to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA (opens in a new tab) .

We state that as a target we test against, not as a certification. No independent auditor has reviewed this site. We would rather describe our testing honestly than display a badge that implies more assurance than exists.

What we have done

• Colour and contrast. Every text-and-background pairing in the design system was contrast-checked before it was used. Body text meets or exceeds 4.5:1 and large text and interface boundaries meet or exceed 3:1. The palette was chosen around those thresholds rather than adjusted afterwards.
• Keyboard operation. Every interactive element is reachable and operable by keyboard alone, in a logical order. The navigation and FAQ accordions are built on native HTML elements, which means they behave correctly for assistive technology without relying on custom scripting.
• Focus visibility (2.4.7, 2.4.11). A single high-contrast focus indicator is defined once for the whole site and never removed. Because the header is sticky, anchor targets carry scroll offsets so a focused element is never hidden behind it.
• Target size (2.5.8). Interactive controls, including small footer and legal links, are given a minimum 24×24 CSS pixel target through padding rather than by enlarging the type.
• Structure. One h1 per page, no skipped heading levels, proper landmark regions, labelled navigation, and a skip link as the first focusable element.
• Motion (2.3.3). Nothing on this site moves automatically. Every transition is decorative and is disabled entirely under prefers-reduced-motion: reduce, including smooth scrolling.
• Forms (3.3.2, 1.3.5, 3.3.8). Every field has a persistently visible label — never placeholder-only — with autocomplete tokens where they apply. There is no CAPTCHA: puzzle CAPTCHAs are a cognitive function test, so spam is handled with a honeypot and a timing check instead.
• Zoom and reflow. The layout reflows to a single column at 320 CSS pixels and at 400% zoom without loss of content or horizontal scrolling.
• Text alternatives. Decorative graphics are hidden from assistive technology rather than given invented descriptions. Icons inside links take their accessible name from the link text. Links that open a new tab announce that they do.

How we tested

Automated checks with axe DevTools and Lighthouse, manual keyboard traversal of every template, manual screen reader passes, colour contrast calculated numerically for every token pair rather than eyeballed, and layout verified at 320 pixels and at 400% zoom.

Automated tooling reliably catches only a minority of accessibility problems, which is why the manual passes matter more than the score. A site can pass every automated check and still be unusable.

Known limitations

We would rather list these than let you find them:

• No independent audit. Our conformance claim is self-assessed. We would commission an external audit before making any stronger claim.
• Screen reader coverage is not exhaustive. We test with the combinations we have access to. Behaviour in every reader-and-browser pairing is not guaranteed.
• Long-form technical articles. Some content is inherently complex. We work on clarity, but we do not claim plain-language conformance beyond AA.
• Third-party form processing. If the enquiry form is connected to an external provider, the confirmation flow after submission is partly outside our control. The form itself is ours and meets the standard.

Report a barrier

If any part of this site is difficult or impossible for you to use, please tell us. It is useful but not necessary to include the page, what you were trying to do, and your browser and assistive technology.

Use the contact page and mention accessibility in your message.

We aim to acknowledge accessibility reports within two working days and to fix confirmed barriers in the next deployment. If a fix will take longer, we will tell you why and when. If you are not satisfied with our response, say so — we would rather hear it directly than not hear it at all.

Applying this to client work

Accessibility is a build constraint on every project we take, agreed before design starts rather than audited at the end. That ordering is not idealism; retrofitting accessibility after a build costs several times what designing to it costs, and we would rather clients spent that money on something else.