Accessibility Statement

We want every support coordinator, support worker, administrator, and auditor who uses this platform to be able to do their job regardless of how they interact with a computer — by mouse, keyboard only, screen reader, screen magnifier, voice control, or with a reduced tolerance for motion. Accessibility is treated as a first-class engineering requirement, tested in our automated pipeline, not a post-launch afterthought.

We target WCAG 2.2 Level AA, the benchmark referenced by Australian procurement, which aligns with the Disability Discrimination Act 1992 (Cth).

The web application is partially conformant with WCAG 2.2 Level AA. “Partially conformant” means most of the platform meets the standard, but some content — noted under Known limitations — does not yet fully conform or has not yet been exhaustively assessed.

• The shared design system (the components every screen is built from — page headers, cards, status badges, metrics, forms, dialogs, empty states) is verified against automated structural and colour-contrast checks.
• The sign-in flow and the compliance registers (Restrictive Practices, Practice Standards, Notifiable Data Breaches, and Worker Screening) have been verified to zero Level A/AA contrast, name, role, and ARIA violations in a real browser, and are gated against regression in our build pipeline.
• The remaining authenticated screens are being assessed and remediated route by route on the same basis.

No formal third-party accessibility audit has been completed yet; one is planned.

The platform includes, among others:

• Full keyboard operability — every interactive control is reachable and operable with a keyboard alone, in a logical order.
• Visible focus — a clear focus indicator is shown on the element you’re on, including the navigation sidebar.
• “Skip to main content” — keyboard users can jump straight past the navigation to the page content.
• Landmarks and structure — pages expose proper banner, navigation, and main regions and a sensible heading order, so screen-reader users can navigate by structure.
• Accessible dialogs — pop-up dialogs move focus into the dialog, keep focus inside while open, return focus to the control that opened them on close, close on Esc, are announced by their title, and make the rest of the page inert to assistive technology.
• Status announcements — a live region announces asynchronous outcomes (for example, “assessment saved”) to screen readers without moving your focus.
• Reduced motion — if your system requests reduced motion, animations, transitions, and smooth-scrolling are neutralised.
• Colour contrast — text and meaningful non-text elements are being brought to the AA contrast thresholds across the product; the design system and the surfaces above already meet them.
• Resizable text and zoom — the interface uses relative units and reflows, so it stays usable when text is enlarged or the browser is zoomed.
• Names on controls — icon-only controls carry text alternatives for assistive technology.

We combine automated and manual evaluation:

• Automated, component level — every reusable design-system component is run through axe-core in our unit suite on every change (accessible names, form labels, roles, ARIA relationships, list semantics). A defect fails the build.
• Automated, page level — a browser-based axe pass runs against representative routes in continuous integration, evaluating the layout-dependent rules — notably colour contrast — that component tests cannot.
• Manual, in-browser — keyboard-only walkthroughs and live axe scans in a real browser.
• Manual, assistive technology (in progress) — screen-reader testing with NVDA (Windows) and VoiceOver (macOS) across the critical flows.

We are open about what is not yet fully accessible, and are actively working on each of these:

• Not every screen has been exhaustively audited yet. The high-traffic and compliance screens are verified; deeper detail screens are being swept route by route. Until a route is verified, it may contain individual contrast or focus issues.
• Generated PDF documents (payslips, signed service agreements, CSV-derived reports) are not yet guaranteed to be fully tagged for assistive technology. The underlying data is always available in the accessible web interface.
• Third-party / embedded content — screens that hand off to an external provider (for example the accounting consent screen) are governed by those providers’ own accessibility.
• No independent audit yet — a formal third-party WCAG 2.2 AA evaluation is planned; this statement reflects our own testing.
• Signature capture and address autocomplete rely on pointer interaction; keyboard/AT-friendly alternatives are on the remediation list.

If you rely on a feature listed here and it is blocking you, please contact us (below) — we will prioritise a workaround.

The platform is designed to work with current versions of:

• Browsers — Google Chrome, Microsoft Edge, Mozilla Firefox, and Apple Safari (desktop and mobile).
• Assistive technologies — keyboard-only operation; screen readers (NVDA, VoiceOver — testing in progress); browser zoom and OS text scaling; reduced-motion settings.

It is not tested against, and may not fully support, browsers no longer maintained by their vendor.

Accessibility relies on the following technologies working with your browser and any assistive technologies installed: HTML, WAI-ARIA, CSS, and JavaScript.

We welcome your feedback on the accessibility of this platform. If you encounter a barrier, or need information in a different format, please tell us:

• If you use this platform as a staff member of a provider organisation, you can also raise the issue with your organisation’s administrator, who can escalate it to us.

Please include the page or feature, what you were trying to do, the barrier you hit, and the browser / assistive technology you were using. We aim to acknowledge accessibility reports within 5 business days and will work with you on a resolution or interim workaround.

This platform is built for Australian NDIS providers. Accessibility obligations in Australia arise under the Disability Discrimination Act 1992 (Cth). If you have raised an accessibility concern with us and are not satisfied with our response, you can contact the Australian Human Rights Commission, which handles disability discrimination complaints.

This statement was prepared on 31 May 2026, based on our own automated (component + browser axe) and manual keyboard testing. A formal third-party audit is planned, and this statement will be updated to reflect it. We review it at least every 12 months, and whenever a significant feature ships.