Legal

Accessibility

The X-Grid website accessibility approach, current conformance work and contact route for reporting access barriers.

Status: launch draft — legal approval required.

The standard we build to

WCAG 2.2 AA, treated as a build requirement

The site is being built against WCAG 2.2 AA expectations for keyboard navigation, focus, contrast, form labels, error handling and reduced motion. That is a build requirement rather than an aspiration: each of those areas is tested before a page is considered finished, and the testing includes real keyboard use rather than automated checks alone. Automated tools catch perhaps a third of the barriers that matter; the rest are found by tabbing through a page, zooming the text, and reading it with a screen reader.

The same standard applies to the parts of the site that are easy to overlook: the navigation menus, the configurator’s form controls, and the legal pages you are reading now. A page is not finished because it looks correct — it is finished when it can be operated without a mouse and understood without the visual layout.

Keyboard navigation — every control reachable and operable
Visible focus — a clear indicator on every interactive element
Contrast — text and controls meet AA ratios
Form labels and error handling — inputs named, errors explained
Reduced motion — animation respects the operating-system preference

What that means in practice

Choices made for keyboard and assistive-technology users

A few decisions on this site exist specifically for keyboard users. The header menus open on keyboard focus as well as on hover, so a visitor who cannot use a mouse can reach every navigation item by tabbing, and a visible focus outline marks where they are. Form controls carry real labels rather than placeholder text, and validation messages explain what went wrong instead of only turning a field red. Motion is limited, and where it exists it is disabled for visitors who have asked their operating system to reduce it.

These are not extras bolted on at the end; they are part of how the components were specified. Where a component could not meet the standard as designed, it was changed rather than excused — a dropdown that only worked on hover, for example, would fail a keyboard user entirely, so the menus were rebuilt to open on focus as well. Accessibility that depends on JavaScript loading correctly is fragile; where possible the site works without it.

Ongoing work

Known gaps and how to report a barrier

This is an honest draft, so it should say where work remains. A final audited statement will be published at launch, following a review of the built site rather than of design intent. Until that review is complete the position is: the standard above is the target, the listed behaviours are implemented and tested, and any barrier that is found will be treated as a defect rather than an acceptable limitation. Automated and manual checks run against every page as the site is built, and the results are reported rather than adjusted to flatter the outcome.

If something on this site blocks you — a control you cannot reach, a label that does not make sense with a screen reader, or text you cannot read at the zoom level you need — please report it. Describe what you were trying to do and what happened; a screenshot or the page address helps but is not required. Accessibility reports reach the same team as technical questions and are answered by a person, with a commitment to say what will change and when. A statement that never admits a barrier is a marketing document, not an accessibility statement, and this page is meant to be the latter.