Accessibility statement
What Ribn builds to, what has actually been tested, and what has not been done yet. Our users include children with additional needs, so this page is written to be accurate rather than reassuring.
The standard we build to
Web Content Accessibility Guidelines 2.2, level AA. Accessibility is treated as a product requirement rather than as an audit finding, which in practice means a keyboard route ships in the same change as the pointer route, or the component does not ship.
What is checked automatically, on every change
- An automated accessibility engine runs over every user interface component in every state it declares, and a violation fails the build rather than producing a report.
- The same engine runs over the rendered pages of this website in a real browser, in both the light and the dark theme, and a violation fails the build.
- Every colour pairing in the design system is checked against the contrast thresholds arithmetically, from the shipped stylesheet rather than from a design file.
- Keyboard behaviour that automation cannot see, such as focus returning to the control that opened a dialog, is asserted in a real browser.
Decisions taken for accessibility, not for looks
- Minimum target size is 44 by 44 pixels, well above the 24 pixel requirement.
- Colour never carries meaning on its own. A status has a word, a finding has a shape, and a wrong answer is never signalled by red.
- Text size, line spacing and letter spacing are user controllable at the token layer, so a change applies to the whole product rather than to one screen.
- Motion is only ever used to explain a state change, and reduced motion removes the travel without removing the feedback.
- The marking demonstration on the front page works from the keyboard alone, announces its result politely, and degrades to the questions, their answers and their reasoning as static text when scripting is unavailable.
What has not been done
- No independent audit. Nobody outside the team has assessed this product, and we hold no certification. We are not going to imply one.
- No completed screen reader test report. Components are built to be announced correctly and the automated checks agree, but a full manual pass with JAWS, NVDA and VoiceOver has not been published.
- Automated checks catch roughly a third of the problems. That is a known limit of every accessibility engine, not a limit of ours.
- The signed-in product is still being built. The claims above cover the design system and this website. They will cover each product screen as it ships, and this page will say when.
If something blocks you
An accessibility barrier is a defect, and it is treated as one. Tell us what you were trying to do, what happened, and what you were using, through the contact page.