Accessibility
What is in place today across the nOS platform and this website, how we verify it, and what is still outstanding.
What is in place today across the nOS platform and this website, how we verify it, and what is still outstanding.
nOS is built to be usable by everyone — on any device, with a keyboard, a screen reader, or a touchscreen. We target WCAG 2.1 Level AA.
A master schedule is administrative infrastructure. The person building it may be doing so with a screen reader, at 200% zoom, on a phone in a corridor, or with a trackpad that is hard to use precisely. None of that should make the job harder than it already is.
We treat accessibility as part of the interface rather than a remediation exercise, and we verify it on every surface rather than assuming it.
Every surface of the platform — the home command centre, guided mode, the schedule builder, Results, Schedule Studio, the Board, the runs library, the nOS AI panel and all dialogs — reflows cleanly at phone (390px), tablet (768px) and desktop (1440px) widths, in both light and dark themes.
No surface requires horizontal page scrolling. Wide data tables scroll inside their own container with a visible edge affordance, and menus and dialogs become bottom sheets on phones so nothing clips at the screen edge.
All interactive controls are reachable and operable with a keyboard alone. A Skip to content link is the first focusable element on every page and moves focus past the navigation to the page's main landmark.
Focus is always visible. A single high-contrast focus ring is drawn using a box-shadow rather than an outline, so it remains visible on controls inside clipped or transformed containers, and it is drawn inset where it would otherwise fall under a gradient.
Each page exposes one main landmark and a single level-one heading. Icon-only buttons carry text labels. Tab bars use the tablist, tab and aria-selected pattern. Dialogs use the dialog role with aria-modal. The nOS AI conversation and live status readouts use polite live regions so updates are announced without interrupting. Decorative graphics are hidden from assistive technology.
Interactive controls meet a 44 × 44 pixel minimum touch target, per WCAG 2.5.5. Where a control is deliberately small for visual reasons — the guided-mode progress dots, for example — it keeps its minimal appearance but carries an enlarged invisible hit area.
When the operating system requests reduced motion, all non-essential animation is removed and transitions collapse to near-instant. End states are preserved, so nothing disappears or becomes unreachable as a result. This site follows the same rule: its only motion is a short fade-in on scroll, and that is disabled entirely under a reduced-motion preference.
Text and essential interface elements meet the AA contrast ratio — 4.5:1 for body text — in both themes. Status is never conveyed by colour alone: fulfillment, "helped or harmed" indicators, and alert states all pair colour with text or iconography.
A forced-colors path preserves borders, focus rings and status meaning when Windows High Contrast mode overrides our palette.
The viewport allows pinch-zoom and reflows to 200% without loss of content or function. We never disable user scaling.
Automated. An axe-core pass covering WCAG 2 A/AA and best-practice rules runs against every surface at all three viewport sizes in both themes, alongside full-page screenshots that are reviewed by eye.
Manual. Keyboard tab-through of each surface, a visible-focus check, a screen-reader landmark and heading review, touch-target and reduced-motion spot checks, and a light and dark contrast review.
A WCAG conformance claim is only meaningful alongside its exceptions, so here are ours. All three are tracked.
nOS targets WCAG 2.1 Level AA and substantially conforms, with the exceptions listed above. If your procurement process requires a third-party audit or a VPAT, contact us and we will work through your requirements with you.
If any part of nOS or this website is difficult or impossible for you to use, we want to hear about it. We treat these reports as bugs, not feedback.
Get in touch through the contact page, or from inside the app using Contact support. Please tell us the page or screen, what you were trying to do, and the assistive technology, browser and operating system you were using — it makes the difference between us guessing and us fixing it.
We aim to acknowledge accessibility reports within two business days.