Accessibility statement.
Last updated 20 May 2026
roc.up is a tool built for the disability sector. Making it usable by everyone — including support workers and administrators with disability — is not optional, it's the brief. This page sets out our commitment, our current state, and how to tell us when we fall short.
1. Our commitment
roc.up aims to conform with Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA. We review the product against these guidelines and treat accessibility issues as defects, not feature requests.
2. What's in place
- Keyboard navigation — every interactive element in the application is reachable and operable via keyboard. Logical tab order across screens.
- Visible focus indicators on form fields and interactive elements (we use a 3px ring around focused inputs).
- Colour contrast — body text and primary actions are designed to meet WCAG AA contrast ratios (4.5:1 for normal text, 3:1 for large text and UI components) against their backgrounds.
- Semantic HTML — headings (h1–h5) follow document order; landmarks (
nav,main,aside,footer) are used; form fields are paired with labels. - Resizable text — the application uses relative units, so browser zoom up to 200% does not break layouts.
- Mobile-first worker app — the support-worker interface is designed first for phones, with large touch targets (44×44 px minimum).
- Plain English — copy in the application is reviewed for plain-language readability, particularly in forms and confirmations.
3. Known gaps we're working on
We are honest about what isn't fully there yet:
- Screen-reader support across complex grid views (the roster, the timesheet table) is being refined. Basic operations are accessible; advanced operations like drag-and-drop are being given keyboard-equivalent alternatives.
- Skip-to-content links are not yet present on every page. Coming.
- High-contrast mode is not a separate theme — we rely on browser/OS-level high-contrast settings. A dedicated high-contrast mode is on the roadmap.
- Form errors are surfaced visually but not always announced to assistive technologies. We are adding ARIA live regions.
- Auto-generated PDFs (Service Agreements, incident reports) are not yet tagged for accessibility. PDF accessibility is on the roadmap.
4. Standards we reference
- WCAG 2.1 Level AA — the global baseline for web accessibility.
- Disability Discrimination Act 1992 (Cth) — Australian law making it unlawful to discriminate against people with disability in goods, services, and facilities.
- Australian Government Digital Service Standard — section 9 (Make it accessible) — used as a working reference even though it does not directly apply to private SaaS.
5. Tell us when we fall short
If you hit a barrier while using roc.up — anything that prevents you from doing your work, or that doesn't work as you'd expect with assistive technology — please tell us. We treat accessibility issues with the priority of bug reports, not as wishlist items.
- Email accessibility@caringabode.com.au.
- Tell us what happened, what page or feature, what assistive technology (if any) you were using, and how we can reproduce it.
- We will acknowledge receipt within 5 business days and aim to resolve high-impact issues within 30 days.
6. How we test
- Automated checks (axe-core, Lighthouse) run on key pages during development.
- Manual keyboard-only navigation testing on new flows.
- Screen-reader spot-checks with VoiceOver (macOS, iOS) and NVDA (Windows).
- External accessibility audits are planned annually [REVIEW: confirm cadence once external auditor engaged].
7. Contact
Accessibility feedback — accessibility@caringabode.com.au