We build software for the disability sector, so accessibility is not an afterthought for us. This statement covers our marketing website, the OneForce Care web platform, and the OneForce Care Worker App. It is written by Wondertree Studios Pty Ltd (ACN 699 886 498, ABN 82 699 886 498), of Level 10, 387 George Street, Sydney NSW 2000, Australia.
We describe our current state honestly below, including what is not yet done. We have not commissioned an independent accessibility audit, and we do not yet run automated accessibility scanning across the product in our build pipeline, although our test suite does enforce some structural accessibility rules on the shared components everything is built from. Accessibility is an ongoing program of work, not a one-off project, and we prioritise fixes as we become aware of them.
Our obligations, and why we take them seriously
The Disability Discrimination Act 1992 (Cth) makes it unlawful to discriminate against a person on the basis of disability in the provision of goods, services and facilities. That extends to online services, and the Australian Human Rights Commission’s World Wide Web Access: Disability Discrimination Act Advisory Notes explain how it applies to websites and web applications, including its guidance that conformance with the Web Content Accessibility Guidelines is the practical measure of compliance.
We also build for a sector where the obligation is felt more directly than most. Our users include support workers with disability, coordinators using assistive technology, and providers whose own NDIS Practice Standards obligations include making their services accessible to the people they support. Inaccessible software makes their compliance harder, not just their day.
So we treat accessibility as a legal obligation and a product requirement at the same time, and we would rather publish an honest gap list than a conformance claim we have not earned.
Our target
We aim to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA as our standard across the website, the web platform, and the Worker App. This is a goal we are working towards, not a claim of current, verified conformance. We have not been independently audited against it, and we do not describe ourselves as conformant.
What’s in place today
Keyboard access and focus. Interactive controls across the web platform, including buttons, links, and form fields, are built to be reachable and operable by keyboard, with a visible focus outline shown when navigating with a keyboard (:focus-visible) rather than only on mouse click. We use semantic HTML elements (buttons, form labels, headings in order) as the default building blocks rather than generic clickable elements wherever practical.
Dialogs and drawers. Drawers, dialogs and menus close on the Escape key, and the content behind them is prevented from scrolling while they are open, so a keyboard or screen reader user is not silently moved somewhere else on the page.
Colour and contrast. The web platform and website use a single, token-based colour system, applied consistently in both light and dark modes, so text, borders, and interactive states are drawn from a small, deliberate palette rather than ad hoc colours. The palette is designed with readable contrast in mind, though we have not run a systematic contrast audit against every text and background combination in the product, and some lower-emphasis text (for example, tertiary labels) may not always meet AA contrast at small sizes. We treat contrast issues reported to us as bugs.
Not by colour alone. Statuses in the product carry a text label as well as a colour, so a shift status, a compliance warning or a claim state can be read without relying on hue.
Text sizing. The interface is built in relative units and scales with the browser or device text-size setting, rather than pinning text to fixed pixel sizes.
Reduced motion. Both the web platform and the Worker App respect your operating system’s “reduce motion” preference. On the web platform, a prefers-reduced-motion: reduce media query minimises animation and transition durations across the interface. In the Worker App, list entrances, staggered item animations, and layout transitions check the device’s reduced-motion setting and skip straight to their end state when it is on, rather than animating.
Responsive layout. The website and web platform use responsive, flexible layouts intended to remain usable and readable as the viewport shrinks, rather than a fixed desktop-only layout. Data-dense tables scroll within their own container so the page itself never scrolls sideways.
Assistive technology labelling. Icon-only buttons and non-text controls across the web platform and Worker App are labelled for screen readers (using aria-label on the web, and accessibility labels and roles in the Worker App) where we have identified the need, though this coverage is not yet complete across every screen.
Announcements without a page change. Loading states, validation errors and alert messages are built to announce themselves to screen readers through live regions, and decorative loading placeholders are hidden from them. Our automated test suite enforces this on the shared components that produce those states, so a new screen inherits the behaviour rather than having to remember it.
Plain language. We write interface text, error messages and help content in plain English, and we prefer a sentence that explains what to do next over terminology that only makes sense once you already know the answer. Our alerts reference explains what each message in the product means and how to resolve it.
The Worker App
The Worker App is used one-handed, outdoors, often in a hurry, and sometimes by workers who use assistive technology themselves. It supports the device’s own text-size and reduced-motion settings, labels its controls for screen readers, and uses large touch targets for the actions that matter most, such as clocking in and out.
Two areas need naming honestly. Slide-to-confirm controls, used for clocking in and out, are a gesture, and while an accessible alternative path exists we have not verified it end to end with every screen reader on both platforms. And the app’s offline mode means some state changes happen without a network round trip, which can make status announcements less predictable than we would like.
Known limitations
Some areas do not yet fully meet our WCAG 2.2 AA target, including:
- data-dense screens such as rosters, scheduling grids, the week board and large tables, which can be harder to navigate with a screen reader than simpler content pages;
- some lower-emphasis text and status indicators that may not meet AA contrast ratios at small sizes;
- the maps and route displays used when reviewing travel, which convey information visually and have limited non-visual equivalents;
- the signing pages where a document sent for signature is completed, which use a different interface to the rest of the product and have not been separately reviewed against WCAG 2.2;
- third-party and embedded content we do not control, such as an accounting provider’s authorisation screens, which are subject to that provider’s own accessibility practices;
- the slide-to-confirm gestures in the Worker App, as described above;
- focus behaviour after a dialog or drawer closes, which we have not verified screen by screen; and
- areas of the product we have not yet reviewed against WCAG 2.2 specifically, since we have not completed a full audit.
We treat accessibility issues as bugs, not feature requests, and prioritise fixing barriers that stop someone from completing a task over cosmetic issues.
How we work on accessibility
Accessibility is built into how the product is made rather than reviewed at the end: shared components carry their own keyboard, labelling and announcement behaviour, so a new screen inherits them instead of reinventing them. Our automated test suite enforces structural rules on those shared components, including live-region announcements for loading, validation and alert states, and rules that keep dropdowns and pickers usable while a drawer is open.
What we do not yet have is automated accessibility scanning across every screen in the build pipeline, a completed manual audit against WCAG 2.2 AA, or an independent review. Those are the next steps, and we will update this page as each one lands rather than announcing them in advance.
If you need information another way
If you cannot use part of the website, the platform or the Worker App, or you need information from us in a different format, tell us and we will provide it another way, at no cost. That includes talking a task through with you, sending you the information by email, or completing something on your behalf where the alternative is you being unable to do it at all.
Feedback and complaints
If you encounter a barrier using our website, the web platform, or the Worker App, please tell us. Email hello@oneforce.com.au with the page or task, the assistive technology or browser you were using if relevant, and what went wrong. We will acknowledge your message within 5 Business Days, tell you what we can do immediately as a workaround, and tell you what we intend to do about the underlying issue and roughly when.
If you are not satisfied with our response, you can make a complaint about disability discrimination to the Australian Human Rights Commission:
- Website: humanrights.gov.au/complaints
- Phone: 1300 656 419
- National Relay Service: 1800 555 677, then ask for 1300 656 419
Complaining to the Commission does not cost anything, and it does not require you to have raised it with us first, though we would like the chance to fix it.