Accessibility statement

What we are aiming for

Our target is the Web Content Accessibility Guidelines, version 2.2, level AA, across the public site and the signed-in app. We treat that as a floor rather than a certificate: a page can technically pass and still be unpleasant to use with a screen reader or a keyboard, and we care about the second thing.

There is a reason this matters more here than on an average marketing site. Between Us asks people to answer dozens of questions honestly and then read something emotionally significant. Anyone who has to fight the interface to do that will not be honest, and will not finish.

What is built

Structure and navigation

• Real landmarks on every page — a single main region, a banner header, a contentinfo footer, and navigation regions with accessible names.
• A skip link as the first focusable element, which jumps straight to the main content and becomes visible when focused.
• One h1 per page and a heading order that does not skip levels, so screen-reader users can navigate by heading and get an outline that matches the visual one.
• Long documents like this one carry an in-page table of contents with real anchor links, and every section heading has an id you can link to directly.

Keyboard

• Everything interactive is reachable and operable with a keyboard alone. There are no mouse-only controls.
• Visible focus on every interactive element — a two-pixel outline with an offset, from a global rule rather than per-component styling, so it cannot be forgotten on a new component.
• The mobile menu is a real button with a proper expanded state, the panel is marked as a modal dialog with an accessible name, it closes on Escape, and the background does not scroll behind it.
• Accordions are buttons inside headings, with the panel linked to the trigger by id in both directions, so a screen reader announces the state and can jump between the two.
• Focus order follows reading order. We do not use positive tabindex values anywhere.

Motion

The reveal animations, progress bars and count-ups all check prefers-reduced-motion and collapse to an instant, non-animated render when it is set — not a faster animation, no animation. There is also a global rule that reduces transition and animation durations and switches off smooth scrolling. Nothing on the site autoplays, flashes, or moves without being asked to.

Text and layout

• Body text is set around 16 to 17 pixels with line height near 1.65, and prose measures are capped at a comfortable reading width rather than running the full screen.
• Everything is set in relative units and respects browser text sizing, so zooming to 200 per cent reflows rather than clipping.
• Layouts are single-column on small screens with no horizontal scrolling, and no content is locked to landscape.
• Link text makes sense out of context; we avoid bare “click here”.

Forms

• Every input has a real label element associated with it. We do not use placeholder text as a label.
• Hints and error messages are tied to their input with aria-describedby, so they are read out when the field receives focus rather than being visual-only.
• Errors appear inline next to the field that caused them, in words rather than only in red, and are announced to screen readers through a live region.
• Invalid fields are marked with aria-invalid, and the border change is accompanied by text.
• Required fields are marked in the label, and the questionnaire can be completed and resumed without losing answers.

Charts, bars and results

• Progress indicators expose a real progressbar role with current, minimum and maximum values and an accessible name.
• Comparison bars carry a text alternative describing the value, so the number is available without reading the graphic.
• Every visual comparison is accompanied by the same information in a sentence. The graphic is a convenience, not the only route to the result.

Colour is never the only signal

The comparison views use lavender for Partner A and dusty rose for Partner B. That distinction would be useless to a lot of people on its own, so it is never carried by hue alone.

Each partner also has:

• a distinct glyph — a filled circle for Partner A, a diamond for Partner B — rendered alongside the label;
• a distinct fill pattern, solid for A and hatched for B, on every bar and block;
• a visible text label, so neither shape nor colour has to be decoded.

The same principle applies elsewhere. Agreement and difference are stated in words as well as shown in colour; form errors have text; status badges have text. Our colour palette is deliberately low-contrast as a surface treatment, but text and interactive elements are checked against AA contrast ratios rather than chosen by eye.

Known limitations

These are the places we know we fall short. We would rather list them than let you discover them.

• Complex comparison charts. The multi-category comparison views carry text alternatives, but a single sentence does not convey the shape of a forty-question comparison as well as the graphic does for a sighted user. A full data-table alternative for every chart is in progress and not finished.
• No third-party audit. We have tested with keyboard navigation, browser zoom, forced-colours mode and screen readers during development. We have not commissioned an independent accessibility audit, so nothing on this page should be read as certified. When we do commission one, we will publish what it finds, including the failures.
• No formal conformance claim. For the same reason, we say “we target WCAG 2.2 AA” rather than “we conform to WCAG 2.2 AA”. The difference is deliberate.
• Downloadable PDF reports. The PDF export of a paid report is not yet fully tagged for accessibility. The same content is available as a web page in your account, which is the accessible route in the meantime.
• Third-party advertising. Where advertising appears on public pages for people who have opted in, we do not control the markup inside the ad frame and cannot guarantee its accessibility. Declining advertising cookies removes it, and it never appears on private pages at all.
• Focus management in the mobile menu. The panel closes on Escape and is announced as a dialog, but it does not yet trap focus inside itself or return focus to the menu button when it closes. Both are on the list.
• Screen-reader coverage. Our testing has not covered every combination of screen reader, browser and operating system. If your combination behaves badly, we may not know yet.

Telling us about a problem

If any part of Between Us is difficult or impossible for you to use, please tell us. Email hello@betweenus.app with “Accessibility” in the subject line.

It helps if you can include the page address, what you were trying to do, what happened, and the browser, operating system and assistive technology you are using. If that is more effort than you have available, send us one sentence — we would rather have a vague report than none.

We will acknowledge your message within 5 working days and tell you what we are going to do and roughly when. If it is a blocking problem — something that stops you completing the questionnaire or reading your results — we will prioritise it over feature work and we will keep you updated rather than going quiet.

If we cannot fix something quickly, we will say so plainly and, where possible, offer another way to get the same thing. If you need your data or your results in a different format, ask and we will provide it.

Accessibility feedback is also a good channel for anything that was merely confusing. A questionnaire that is hard to understand is an accessibility problem even when it passes every automated check.