Accessibility statement
What we have done, what we have tested, and what we know is not perfect yet.
Last updated 2026-10-07.
Our target
WCAG 2.2 Level AA. Not as a badge - as the thing we actually build to and test against.
What is in place
- Keyboard: every interactive element is reachable and operable by keyboard, with a visible 2px focus outline. There is a skip link to the main content on every page. The chassis picker and goal selector are real radio groups, not divs with click handlers. - Contrast: the palette is checked at the sizes it is actually used. Body ink on the page background is around 14:1, and the accent colour on the background is around 7:1. The amber warning colour never carries small body text - it is used at 16px semibold or heavier, or as a border. - Structure: one `h1` per page, headings in order, landmarks (`header`, `main`, `footer`, `nav`), breadcrumbs marked up as navigation, and tables with real `th` cells and captions. - Motion: there is exactly one non-user-triggered animation on the site - the phase rail filling once on the home page. It is disabled entirely under `prefers-reduced-motion`. - Colour is never the only signal: compatibility confidence is shown as a word as well as a colour, and required versus optional rows are distinguished by border style and by text, not just by weight. - Without JavaScript: every marketing page, chassis page, plan page, guide and legal page renders and reads completely with JavaScript off. The interactive planner and the free tools need JavaScript, and they say so. - Zoom and reflow: the layout works to 400% zoom and at 320px width with no horizontal scrolling. Wide tables scroll inside their own container rather than pushing the page sideways. - Dark mode: a designed palette rather than an inversion, honouring both the system setting and an explicit choice.
What we have tested
Automated checks in the build pipeline, keyboard-only passes on the main flows, and rendering with webfonts blocked and with JavaScript disabled. Lighthouse accessibility scores are part of the release checks.
What is not perfect
- No screen reader testing with real users yet. We have tested with the browser accessibility tree and with semantic markup discipline, but that is not the same thing, and we are not going to claim it is. - The parts table is dense. On a long plan, a lot of information is laid out in rows. We believe the markup is correct, but we would like feedback from anyone navigating it with a screen reader. - Charts and diagrams: there are none right now, which is the easiest way to be accessible. When we add one it will have a text equivalent.
Tell us
If something on this site is hard or impossible to use, email support@buildsideways.com and say what you were trying to do, what happened, and what you are using. Accessibility reports go to the front of the queue - ahead of feature work, not behind it. We will reply and tell you what we are going to do.
If we cannot fix something quickly, we will tell you that too, and give you another way to get what you needed.
The other documents
All six are written to describe what this specific service does, rather than copied from a generator. None of them are legal advice.
- Privacy policyWritten to describe what this site actually does, not to cover every eventuality.
- Terms of serviceWhat you can expect from us, and what we need from you.
- Refund policyShort, because it should be.
- Cookie policyThere are three, and none of them follow you anywhere.
- Affiliate disclosureThe money, in plain terms, including the parts of it that are awkward.
- Help centre
- Ask us a direct question