Legal

Accessibility

Last updated 1 November 2026. This page describes how the site is built and what we are aiming for, rather than claiming a standard we have not had independently verified.

The short version

We aim to meet WCAG 2.1 Level AA. The site is designed so that the menu, the quote form and the main content work with JavaScript switched off, so that it can be operated from a keyboard, and so that it respects your reduced-motion preference. It uses semantic HTML with a single H1 per page. We have not commissioned a third-party audit, and we do not claim certified conformance.

How the site is built

Core features do not depend on JavaScript

The slide-out menu and the quote form overlay are built on native checkbox inputs and CSS rather than scripts. Sub-menus use the native <details> element. Forms post to a normal server endpoint. JavaScript, when present, adds conveniences such as Escape-to-close, focus handling, inline form feedback and scroll-reveal animation.

Keyboard operation

Interactive elements are designed to be real, focusable controls. The menu and quote toggles are focusable checkboxes with labels. Focus outlines are visible and we have not removed them.

Motion

Scroll reveals and other animation are designed to stop when your system requests reduced motion. Nothing on this site is meant to flash.

Colour and contrast

We aim for text and interactive elements to meet WCAG 2.1 AA contrast guidance, and we try not to convey information by colour alone — tables, status messages and form errors carry text as well.

Structure and semantics

One H1 per page, headings in order, landmark elements for header, navigation, main and footer, real table markup for the specification tables, and breadcrumbs marked up as a list.

Forms

Form fields have visible labels rather than placeholders standing in for them. Validation errors are given in text, not only by colour, and fields use autocomplete hints where they apply.

Tables

Some specification tables are wide. Each one is designed to scroll horizontally inside its own container so the page itself does not scroll sideways.

Known limitations

  • The interactive component diagram in the anatomy teardown needs JavaScript and conveys spatial relationships that a screen reader cannot usefully describe. We aim to publish the same information in text on that page.
  • We have not tested with every assistive technology. If something does not work with yours, we would genuinely like to know.

Reporting a barrier

Use the contact form and include the page address and what went wrong. If the form itself is the barrier, describe what you need in as much of the form as you can complete, and we will do our best to help.

Without JavaScript

What is designed to work without scripting.

The site is built HTML-first and scripting is additive. This is the intended behaviour.

FeatureWithout JavaScriptWhat scripting adds
Pages and linksWorkClient-side routing
Slide-out main menuNative checkbox and CSSEscape to close; closes on navigation
Sub-menus in the menuNative details elementsNothing
Quote form overlayNative checkbox and CSSFocus placement, Escape to close
Quote request formPosts to the serverInline validation and feedback
Specification tablesWorkNothing
FAQ disclosuresNative detailsNothing
PhotographsPlain imagesNothing
Scroll reveal animationContent simply visibleThe animation
Anatomy diagram hotspotsNot availableThe interaction

Contact

Reporting a barrier.

Detail
Where to writeThe contact form on this site
IncludeThe page address and what went wrong
Alternative formatsTell us through the form what format would help, and we will do our best
Requesting a quoteThe quote form is the only route; tell us in it if you need help completing it

Design decisions

Choices made for accessibility that also made the site better.

Much accessibility work is not a compromise. These are decisions where the accessible route was also the better engineering.

DecisionAccessibility reasonOther benefit
Native checkbox for the menu and quote overlayKeyboard operable without scriptWorks with JavaScript off; less code to break
Native details for sub-menus and FAQsBuilt-in semantics for assistive technologyNo custom state to drift
Form posts to a real server endpointWorks without scriptOne validation path
Visible labels, not placeholdersLabel persists while typingUsers can see what a field wants mid-entry
Errors in text, not only colourColour-blind usersErrors can say what to do
Width and height on imagesReduces disorienting reflowLess layout shift
Tables scroll in their own containerNo horizontal page scrollWide data works on a phone
Reduced-motion respectedVestibular sensitivityCheaper rendering on weak devices
Answer-first summary on many pagesScreen reader users reach the point fastEveryone reaches the point fast

Technical detail

How specific patterns are implemented.

For anybody evaluating the site technically, or building something similar.

PatternImplementationWhy not the usual approach
Slide-out menuHidden checkbox plus CSS :has()A script-only drawer breaks without script and needs manual focus management
Menu buttonA label bound to the checkbox; the checkbox itself is focusableKeeps native Space-to-toggle and native focus
Sub-menusNative details and summaryCustom accordions need aria-expanded plumbing that can drift
Quote overlayHidden checkbox plus CSS; dialog role on the containerSame reasoning
Form errorsPer-field text plus a summaryColour-only or tooltip errors are missed by several groups
Success messageA polite status regionAssertive would interrupt mid-sentence
Reveal animationDefault state is visible; scripting opts inContent is never hidden behind a script that might not run
TablesReal table markup with header cellsDivs styled as tables lose structure