Accessibility statement

What we have built in

The application is built with these practices, by design system rule:

• Every form control has a visible, programmatically associated label.
• A skip-to-content link is the first focusable element on every page.
• Tabular data uses real table semantics with captions for screen readers.
• Keyboard focus is visible on every interactive element.
• Animation is minimal and respects the operating system’s reduced-motion preference.
• Light and dark themes were designed against WCAG AA contrast targets for text colours.

What has actually been tested

An internal accessibility audit was carried out on 29 August 2026 covering every screen in both colour themes: colour contrast was computed for every text and surface pairing the interface renders, and keyboard behaviour, focus management, form labelling, error association and table semantics were reviewed against WCAG 2.2 and the ARIA Authoring Practices. Issues the audit found were fixed as part of it, including low-contrast state colours and 33 places where de-emphasised text fell below the contrast minimum.

On that basis we consider the application to conform to WCAG 2.2 level AA, with the known exceptions below.

• Form field borders sit below the 3:1 non-text contrast heuristic. Every field has a visible label and a high-contrast focus indicator, so identifying fields does not depend on the border alone.
• Placeholder text inside fields is deliberately low contrast; it is always supplementary to a visible label and never the only instruction.
• No testing with assistive-technology users (for example screen reader or voice control users) has been carried out yet. The interface is built to the relevant ARIA patterns, but we do not claim user-tested screen reader support until that testing has happened.

Feedback

If something here does not work for you, contact [CONTACT DETAILS] and we will address it.