Accessibility statement

• Semantic HTML. Real headings, landmarks and lists. Exactly one h1 per page, checked automatically on every page at both widths.
• A skip link to the main content as the first focusable element on every page.
• Text alternatives. Every image carries an alt attribute; the test suite fails the build if one does not. Decorative drawings are marked as decorative so a screen reader passes over them.
• Reduced motion is honoured. Every animation on this site — the rising sun, the count-ups, the drawn illustrations, the highlighter swipes, the product recordings — is disabled under prefers-reduced-motion, and the test suite asserts that nothing has moved and that no video is playing or still carrying an autoplay attribute.
• Nothing depends on JavaScript. With scripts blocked, the drawings are already drawn and the figures are already at their final value. There is no state in which a reader is left looking at an empty box.
• No horizontal scrolling at any width down to 390 px, asserted on every page. Text reflows; wide tables scroll inside their own box rather than moving the page.
• Visible focus. A keyboard focus ring in the site’s own teal, on everything focusable, never removed.
• Contrast. Body text is near-black on white. Where the register asked for a lighter grey, it was rejected for text and kept for rules and marks that carry no meaning.
• Language is declared on every page, and each translation states its own; the language switcher marks the current one.
• No autoplaying sound. The product recordings are silent, do not start until deliberately in view, and never start at all under reduced motion.

• Keyboard-first grids. The pivot and list grids are driven from the keyboard — arrows, Enter, Tab, copy, paste, fill down — because that is how planners work, and it happens also to be what assistive technology needs.
• Refusals are read out, not coloured in. When a write is refused, the reason is a sentence naming the cell and the rule. The colour is a second signal, never the only one.
• Accessibility linting in the build. The application’s own linter includes JSX accessibility rules, and the build fails on a lint error.
• Builders take the frame, never a modal, which means focus is somewhere a keyboard user went rather than somewhere they were thrown.

Known gaps in the product. A large virtualised grid is difficult to make read well in a screen reader, and we have not solved it. Charts have no data-table equivalent yet. The application has not been tested end to end with a screen reader, and there is no VPAT. If you use assistive technology and want to plan with Superiora, write to us — that is a conversation we want, and it will change the roadmap.