Accessibility
What works, what doesn’t, and how to tell us
A conformance claim is only worth reading if it includes the parts that fail. Ours does.
Our claim
Readeroom aims to meet WCAG 2.2 Level AA. Today we are partially conformant: most of the product meets that standard, and the specific places it does not are listed below rather than summarised away.
We will not publish a claim of full conformance until an audit covering keyboard operation, two screen-reader stacks, forced-colours mode and 400% zoom has actually been carried out. Saying “fully accessible” without that is a marketing claim wearing a standard’s name.
Scope: readeroom.com and everything behind sign-in. Last reviewed when this page last changed; the automated portion re-runs on every change to the product.
What already works
- Colour contrast is enforced automatically. A check runs on every change and fails the build if any text or control pairing drops below the required ratio, in both the light and dark themes. This is the one part of this page that is machine- verified rather than reviewed by a person.
- Reading text is held to a stricter ratio than the standard requires, in both themes, because it is read for long stretches.
- Every interactive control is at least 44 by 44 pixels, and every one shows a visible focus ring at the same weight and offset throughout.
- Reduced motion is respected. Every animated element ships its settled end state first — that frame is what the server renders and what you get if your system asks for reduced motion. Nothing in the product moves in order to be understood.
- Nothing navigates on a timer. There is no auto-redirect anywhere; you move on when you choose to.
- Meaning is never carried by colour alone. Pass and fail states, plan states and progress states all carry words as well.
- Form fields have real labels, not placeholder text, and errors are announced rather than only shown.
- The reading modes are controllable. Anything that plays has a visible pause control, always present regardless of your motion preference.
Barriers we know about
Each of these is a real thing that will make the product harder or impossible to use for someone. They are listed with the release that fixes them.
| Barrier | Who it affects | Status |
|---|---|---|
| The progress page is a scrolling illustration | It loads scrolled to the bottom and you climb by scrolling upwards, which is unusual and can be disorienting. The same information is available as a plain list below it, but that list is not the default. | A conventional list view becomes the default in the next release. |
| Error and not-found pages have never been audited | Everyone. These are currently the framework’s built-in pages rather than ours, so they do not follow any of the contracts on this page. | Being replaced with real pages. |
| Form errors are not associated consistently | Screen-reader users. Some forms announce an error correctly; others show it visually without linking it to the field it belongs to. | A single shared field component is being introduced so every form behaves the same way. |
| Two form layouts disagree with each other | The sign-in page uses an older stylesheet that overrides the shared field styles, so its spacing and error presentation differ from the rest of the product. | Being migrated to the shared components. |
| Some smaller controls rely on an invisible touch target | Touch users. A few 36-pixel controls reach the 44-pixel minimum through an invisible extended area rather than being drawn at full size. | Compliant, but listed because it is a weaker form of compliance than drawing the control correctly. |
| No screen-reader or forced-colours audit has been completed | Anyone using a screen reader, Windows high-contrast mode, or heavy zoom. We believe these work; we have not systematically verified them. | Part of the release checklist being introduced — until it runs, treat the claim above as partial for this reason too. |
| The product is English-only | Readers who need another language, and right-to-left scripts, which are not supported yet. | Later; it needs the reading measurements to work per-language first. |
Tell us about a barrier
If something here does not work for you, please write to help@readeroom.com. It helps to include the page, what you were trying to do, and what you use to browse — but a one-line message is welcome and far better than nothing.
What we commit to:
- A reply from a person within five working days.
- Either a fix, or a dated plan, within twenty working days.
- Adding it to the table above in the meantime, so the next person reading this page knows about it too.
If you need something from the product that you cannot get at because of a barrier — your data, your reading history, a cancellation — say so and we will do it for you rather than making you fight the interface for it.