Accessibility

What was decided, and the measurement behind it

Colour and contrast

The colour palette was not chosen and then checked — it was measured first. Every text-and-background pair in our design system clears 7.14:1 or better, which is AAA for body text rather than the AA minimum of 4.5:1. There is a specific rule inside it worth stating because it is the kind of thing that usually slips: our lightest text tone clears AAA only on the two lightest surfaces, so anything darker than those — panel fills, status tints — is required to use the next tone up.

Colour is never the only signal. Every status carries a word, and a glyph or a dot, as well as a tint. A goal that is overdue says so in text. This matters more than usual here: a product whose central screen sorts by urgency is exactly the product that gets built as a wall of red and amber dots.

Type

Two of the three typefaces were chosen for reading difficulty rather than for appearance. Lexend comes out of reading-proficiency research, and Atkinson Hyperlegible was commissioned by the Braille Institute and is designed so that characters which are commonly confused — I, l, 1, O, 0 — stay distinguishable at small sizes and for low-vision readers. Anything read in sentences is set in Atkinson; figures that have to align in a column are set in a monospace face with tabular figures, so a score of 11 and a score of 74 line up.

Body prose is 16px with a 1.6 line height. Continuous prose on these legal pages is held to a 68-character measure, under WCAG’s 80-character guidance. Text resizes and reflows: nothing is sized in a way that ignores a browser or OS text setting, and pinch-zoom is not disabled anywhere — the viewport tag sets no maximum scale, which is a failure we specifically avoided rather than one we happened not to make.

Keyboard and focus

Every interactive element is reachable and operable by keyboard. Focus is visible everywhere — a 2px outline at a 3:1 contrast against whatever is next to it, with an offset so it is not swallowed by a border. Scrollable regions, such as the subprocessor table on the security page, are focusable, because a region that scrolls but cannot be focused cannot be scrolled by a keyboard-only user at all.

On layouts that alternate left and right down the page: the visual order changes and the reading order does not. The content order stays heading, text, then picture every time, so a screen reader and a phone get one consistent sequence. Doing that by reversing the markup instead — which is the easy way — would silently reverse the content for half the sections.

Motion

Everything animated respects prefers-reduced-motion, and respects it properly: animation is removed rather than shortened. Loading placeholders are a solid tint with a highlight passing over it, never a pulse of the whole block, so that when the motion is switched off the tint is still there doing the actual job of holding the shape. Motion is never the only indication that something happened. Nothing on any screen flashes, and no animation loops as a decoration.

Touch targets

44px minimum for anything inside content — entering a score, logging a provision, opening a student, revoking a link. 34px is permitted only for top-bar chrome on a pointer device. That rule exists because two of our own documents disagreed and we resolved it in favour of the stricter one after measuring a real phone viewport and finding every row action at 34px. Data entry happens one-handed, mid-lesson, with a thumb.

Printed sheets

Worth including, since the printed probe sheet is the product’s main output and accessibility does not stop at the screen. Sheets print in one colour with no tint above 15%, so nothing depends on colour and nothing is lost to a worn drum or a photocopy of a photocopy. Scoring boxes are 4mm minimum and 5mm preferred — ticked with a pen, on a clipboard, standing up. Rules are 0.5pt minimum. Prose on the sheet is 10.5pt Atkinson.

Privacy controls that are real

One place where accessibility and privacy are the same requirement: when optional student names are masked, the name is not sent to the browser. It is not blurred, not coloured transparent, not hidden with an attribute. Every one of those leaves the value in the page source and therefore in a screen reader’s output — a control that looks identical in a screenshot, would be described to a district as privacy, and announces the name aloud to the one user who cannot see that it is supposed to be hidden.

Known gaps

These are open. They are listed because you would find them, and because a statement without them is not worth reading.

• No independent audit. Nothing here has been verified by a third-party accessibility auditor, and no VPAT or ACR exists. Everything on this page is our own testing. If your district requires a VPAT for procurement, we cannot supply one today — tell us and we will say honestly when we could.
• Limited assistive-technology testing. We test with keyboard navigation, browser zoom to 400%, forced-colours mode, reduced motion, and VoiceOver on macOS and iOS. We have not tested with JAWS, NVDA or Dragon. Those are the three most likely to surface something we have missed, and they are the gap we would most like to close.
• No automated accessibility check in our build. Our build gates on types, linting, tests and dependency advisories, but there is no axe or Lighthouse accessibility assertion in it yet. That means a regression is caught by a person noticing, which is not good enough.
• The sign-in screen is partly a third party’s. The authentication form is rendered by our auth provider, styled with our tokens and our 44px target heights but not otherwise under our control. We have not separately audited it.
• Generated PDFs are not tagged. The probe sheets are designed for printing and for being scored with a pen, and they are not a tagged, screen-reader navigable PDF. If you need the content of a sheet in an accessible digital form, write to us — this one has a real fix and we have not built it.
• No dyslexia-specific or high-contrast theme toggle. Dark mode and forced colours follow your operating system, and the type is already chosen for reading difficulty, but there is no in-product control beyond that.

Telling us something is wrong

Email support@omibrook.com. Say what you were trying to do, what happened, and what you were using — a browser and screen-reader version if you have it, though a sentence is enough.

We will acknowledge within three working days and tell you whether we can fix it and roughly when. If something blocks you from doing your job we will treat it as a fault rather than a feature request, because that is what it is.

We will also publish what you find. The gap list above is what this page is for, and it gets longer when someone shows us something, not shorter.