Accessibility

This site targets the Web Content Accessibility Guidelines 2.2 at Level AA. We build to that standard as a baseline during development rather than as a remediation pass afterwards, because retrofitting accessibility is both worse and more expensive.

This page is a statement of what has actually been done and what has not. It is not a claim of certification — see the limitations section, which is the honest part.

These are implemented decisions in the site’s code, not intentions:

• Colour contrast was measured, not eyeballed. Body and heading colours clear the 4.5:1 requirement against their backgrounds, and the one blue permitted as text sits at 6.41:1. A darker blue in the palette is restricted to fills and is never used as a foreground colour.
• Every interactive element takes a visible focus ring — a 2px outline with offset — so keyboard navigation is legible at all times. The focus style is defined once and applies site-wide.
• A skip-to-content link is the first focusable element on every page.
• The site is navigable by keyboard alone. The mobile menu traps focus while open, returns focus to its trigger on close, and closes on Escape.
• All motion respects prefers-reduced-motion. Scroll reveals, the mobile menu transition, and every animated element resolve to a static, already-visible state when that setting is on — content is never hidden behind an animation that does not run.
• Reveal animations fail safe: the hidden state is applied only by JavaScript, so if scripts fail or are blocked, content is simply visible rather than permanently invisible.
• Markup is semantic: real headings in order, real lists, real landmarks, and a single h1 per page.
• Form fields have real, associated labels. Errors are announced with aria-invalid and linked to the field with aria-describedby, and are described in text rather than by colour alone.
• Images carry descriptive alternative text; purely decorative graphics are hidden from assistive technology.
• Text uses relative units and reflows without loss of content or horizontal scrolling down to a 320px viewport.

This site has not been through an independent third-party accessibility audit. Its conformance has been assessed by the team that built it, which is not the same thing, and we are not going to describe it as certified.

It has not been tested end-to-end with every combination of screen reader and browser. Testing has covered keyboard navigation, reduced-motion emulation, and automated checks. If you use an assistive technology we have not covered and something does not work, we want to hear about it — that is a real gap, not a hypothetical one.

Where the site uses motion or visual composition to communicate, we have provided a static equivalent. If you find a case where meaning is carried by motion alone, that is a defect and we will fix it.

If any part of this site prevents you from doing something you came here to do, send us a message through the contact page. Describe the page and what happened; you do not need to know the technical cause.

We aim to acknowledge accessibility reports within five working days and to tell you what we are going to do about it and when. If the fix is quick, we would rather just ship it than schedule it.

If the contact form itself is the barrier, say so in whatever way reaches us and we will find another route.

The same standard applies to client work. Accessibility is treated as a baseline requirement in our Digital Experience and Web Systems engagements, verified during build rather than checked at the end.

Where a client’s own compliance regime requires a formal audit or a VPAT, that is arranged as part of the engagement with an independent assessor. We do not self-certify our own work and present it as an audit.