Goodo Accessibility Statement

Draft for legal review — not yet legal advice

Goodo is built for people with disability and the people who support them. If our app is not accessible, it has failed at its main job. This statement explains what we commit to, what we have built, what is not finished, and how to tell us when we get it wrong.

An Easy Read version of this statement is available in the app.

1. Our commitment

• We aim to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA across the Goodo mobile app (iOS and Android), the website and public provider pages, and the staff console.
• Accessibility is a release gate. A feature that fails our accessibility checks does not ship.
• We design and test with people with disability, through our paid co-design group, and we pay them for their time.
• We take our obligations under the Disability Discrimination Act 1992 (Cth) seriously, and we use the Australian Government's Digital Service Standard and accessibility guidance as a reference.

Current status. Goodo is in development. As at the date above, the app has not yet had an independent accessibility audit. We will commission one before public launch and publish a summary. Until then, treat the statements below as our targets and design rules. Please tell us about problems you find.

2. What we have designed in

[Engineering to confirm each item in this section against the shipped build before this statement is published. Items that are design intentions only, such as muted-by-default playback, switch control and voice control support, and the in-app reduce-motion setting, must be tested or removed.]

Captions and video

• Every video has captions. A video cannot be published without them.
• We generate captions automatically. The person who posts can check and edit them, and can upload their own. Captions are on by default and cannot be hidden by the poster.
• Captions are in Australian English (en-AU).
• Each video has a place for an audio description: a written description of what is happening on screen, for people who are blind or have low vision.
• Thumbnails have alt text that the poster writes.
• Videos do not autoplay with sound.

Screen readers and assistive technology

• Every button, link and control has a label and a role that a screen reader can read. Controls with only an icon have a text label for assistive technology.
• We test with VoiceOver on iOS and TalkBack on Android.
• Staff console pages use proper headings, landmarks and form labels, can be used with a keyboard alone, and show a visible focus.
• Content is announced in a sensible reading order.

Seeing, reading and understanding

• Text colour contrast meets AA, in light and dark modes.
• Text grows with your device's text-size setting (Dynamic Type on iOS, font scale on Android), and layouts do not clip or overlap at large sizes.
• Information is never given by colour alone.
• We write in plain Australian English. Key policies have Easy Read versions.
• Error messages say what went wrong and how to fix it.
• Important actions can be undone or confirmed.

Moving and touching

• Touch targets are at least 44 by 44 points.
• Controls can be reached with one hand.
• No action needs a complicated gesture (like pinching or multi-finger swipes) without a simple alternative.
• The app works with switch control and voice control on your device.

Motion, sound and sensory comfort

• Reduce motion. We respect your device's reduce-motion setting and also provide a setting in the app. When on, animations are removed or replaced by fades, and video previews do not move until you start them.
• Flashing content is not allowed in our design, and we ask posters to avoid it.
• You control sound. Videos start muted.
• Time. Nothing times out quickly. Where a timeout is needed (for example, a sign-in code), we tell you and give you time to ask for more.

Events

• Events can be tagged with accessibility information: step-free access, accessible toilet, accessible parking, Auslan interpreter, hearing loop, captions (online), quiet space, sensory-friendly, Easy Read information, assistance animals welcome, and free or low cost.
• Hosts can say whether support workers are welcome, and attendees can say they are bringing one.

Verification and sign-in

• You can sign in with an email or mobile code. We do not use puzzles for sign-in.
• If you cannot upload a document or complete an identity check because of a disability, contact us. We will find another way to verify you where we can. [Assisted verification process to be confirmed.]

3. Known gaps and limits

We want to be honest about what is not yet right. [Founder to confirm these against the build before publishing.]

1. Audio description is written text, not a narrated audio track. People who prefer audio will rely on their screen reader.
2. Automatic captions are not perfect. They can make mistakes with names, accents, speech impairments, background noise and technical terms. Posters are asked to check them. If a caption is wrong, you can report it.
3. No live captions for online events yet. Hosts should arrange their own captioning, and event listings should say whether they have it.
4. No Auslan versions of videos or policies yet. We plan to add key Auslan content with our co-design group.
5. English only. The app, captions and policies are in English. Translations and community-language Easy Read are planned.
6. Easy Read coverage is partial. At launch the Community Guidelines, Privacy Policy, Terms and this statement have Easy Read summaries, not full Easy Read editions.
7. Third-party tools. The identity check is run by a vendor, and we do not control its accessibility. We will pick a vendor that meets WCAG 2.2 AA and tell you if there is a problem.
8. Uploads. Choosing a video or document uses your phone's file or camera picker, which depends on your device.
9. User content. Posters may forget captions are for everyone, or post fast-moving visuals. We cannot check every video for accessibility, but we remove content that causes harm and educate posters.
10. Web. The public website is lower priority than the mobile app in the first release.

We will list new gaps and fixes in this statement, with dates.

4. How we check

• Automated checks in our build pipeline.
• Manual checks against WCAG 2.2 AA for each new screen.
• Testing with VoiceOver and TalkBack, at large text sizes, with reduce-motion on, with keyboard only (console), and in light and dark modes.
• Regular sessions with our co-design group, including people who use screen readers, switch access, voice control, and those with cognitive, sensory and psychosocial disability.
• An independent audit before public launch, then each year.

5. Feedback and complaints

If you can't use something, or something is hard, tell us. You don't need to explain why you need it.

• In the app: Settings, then Accessibility, then Send feedback.
• Email: [accessibility email TBC]
• Phone or text: [accessibility phone TBC]. You can call us through the National Relay Service on 133 677.
• By post: [postal address TBC]
• You can send feedback in a format that suits you, such as a voice message or video.

What we do. We reply within 2 business days. We tell you whether we can fix it, how long it will take, and what you can do in the meantime. For serious barriers, we aim to give you another way to do what you need within 5 business days. We log all accessibility feedback and review it each month.

If you are not satisfied you can make a complaint to the Australian Human Rights Commission, which handles complaints under the Disability Discrimination Act 1992 (www.humanrights.gov.au).

6. Changes

We review this statement every 6 months and after each major release.