Accessibility

Our commitment

We want this site usable by everyone. Accessibility is part of the build, not a pass done at the end.

What is in place

Structure

• Every page has one <h1> and headings that nest without skipping levels
• Landmarks (main, nav, footer) so screen readers can jump between regions
• A skip link is the first focusable element on every page

Keyboard

• Every interactive element is reachable and operable by keyboard
• Focus is always visible, with a high-contrast ring rather than the browser default

Vision

• Body text meets WCAG 2.1 AA contrast (4.5:1 or better), including placeholder text
• Text can be enlarged to 200% without loss of content or function
• No information is conveyed by colour alone

Motion

• Animations honour prefers-reduced-motion
• There are no auto-playing videos and no animation loops

Screen readers

• Form fields have real <label> elements, not placeholder-only labelling
• Status messages (like the waitlist result) are announced via a live region

How it is verified

Accessibility is checked automatically on every commit: every route is scanned with axe-core against WCAG 2.1 A and AA, and the build fails on any critical or serious violation. Contrast for text that automated tools miss — such as input placeholders — is asserted separately by test.

Known limitations

Automated testing catches a minority of real accessibility problems. We have not yet completed a full manual audit with screen readers, and we have not yet tested with assistive technology users. That is planned before launch.

Tell us

If something does not work for you, email [email protected]. Describe what you were trying to do and what happened. We will treat it as a bug.