Topics: Website design & costs, Mobile apps
Want this done for your business? Get a fixed quote or book a free 30-minute call.
Quick answer: Yes, the Disability Discrimination Act applies to apps, because it covers goods and services however they are delivered, and the Australian Human Rights Commission's guidelines point businesses to WCAG. Build and test to WCAG 2.2 Level AA, check every key flow with VoiceOver and TalkBack, and write that standard into your contract and acceptance criteria.
Australia has no statute that says "apps must meet WCAG". What it has is broader. The Disability Discrimination Act 1992 makes it unlawful to discriminate against people with disability when providing goods and services, and for many businesses an app is now how those services are provided. For an app owner, that turns accessibility from a nice-to-have into a risk you can manage with a clear standard and a checklist.
Does the Disability Discrimination Act apply to mobile apps?
Yes. The DDA covers the provision of goods, services and facilities, and a booking, banking or ordering app is a way of providing a service. The Australian Human Rights Commission's Guidelines on equal access to digital goods and services, issued under the Act, explicitly include mobile apps alongside websites, kiosks and other digital channels. They replaced the Commission's older advisory note, which focused on the web.
The Act allows a defence of unjustifiable hardship, but it is narrow and hard to argue for a new app that could have been built accessibly from the start. Apps in government, banking, health, telecommunications and transport tend to attract the closest scrutiny, but any business can receive a complaint. This is general information, not legal advice.
Which standard should an Australian app meet?
WCAG 2.2 Level AA. The Web Content Accessibility Guidelines are published by the W3C, and version 2.2 became the current recommendation in October 2023. The AHRC's guidance points to WCAG, with Level AA as the practical benchmark.
WCAG was written with the web in mind, but its principles and most of its success criteria apply directly to native apps. The W3C's WCAG2ICT guidance explains how to apply them to non-web software. Pair WCAG with the platform guidance from Apple and Google, which sets minimum touch target sizes of 44 by 44 points on iOS and 48 by 48 density-independent pixels on Android.
What are the most common accessibility failures in apps?
Most failures are small, repeated decisions rather than one big flaw. These are the most common:
| Failure | Who it affects | Fix |
|---|---|---|
| Icon buttons with no label, read out as "button" | Screen reader users | Add accessibility labels to every interactive element |
| Low-contrast text and controls | Low vision, bright sunlight | Check contrast in the design system: 4.5:1 for normal text, 3:1 for large text |
| Fixed text sizes that ignore system settings | Low vision, older users | Support Dynamic Type on iOS and font scaling on Android, with layouts that reflow |
| Tiny or crowded touch targets | Motor impairments, everyone on the move | Use platform minimum sizes and spacing |
| Custom controls without roles or states | Screen reader and switch users | Prefer native components or add proper semantics |
| Colour as the only signal | Colour-blind users | Add text or icons to errors and statuses |
| Swipe-only actions | Motor impairments | Provide a visible button alternative |
| Puzzle or memory-based login | Cognitive disabilities | Allow paste, password managers, passkeys and biometrics |
| Video without captions | Deaf and hard-of-hearing users | Caption all video, provide transcripts for audio |
How do you test with VoiceOver and TalkBack?
Turn the screen reader on and complete your key flows without looking at the screen. Automated scanners help, but they catch only some issues; manual testing finds the rest.
On iPhone (VoiceOver): go to Settings, then Accessibility, then VoiceOver, and set the side-button triple-click shortcut so you can toggle it quickly. Swipe right and left to move between elements and double-tap to activate.
On Android (TalkBack): go to Settings, then Accessibility, then TalkBack. The same swipe and double-tap gestures apply. Google's Accessibility Scanner app gives quick automated suggestions alongside.
For each key flow, such as sign-up, login, search, booking, checkout, payment and account settings, check that:
- [ ] Every element is announced with a sensible name, its role (button, link, heading) and its state (selected, expanded)
- [ ] Focus moves in a logical order and never gets trapped
- [ ] Pop-ups and error messages are announced when they appear
- [ ] The flow can be completed from start to finish
Then repeat the flows with the largest text size, with Switch Control on iOS or Switch Access on Android, with voice control, and with reduced motion turned on. Xcode's Accessibility Inspector and Android's automated accessibility checks belong in your developers' workflow; our guide to QA testing explains where they fit. Include testers with disability in your beta, as described in our guide to TestFlight and Google Play beta testing.
What did WCAG 2.2 change for touch targets and logins?
WCAG 2.2 added criteria that matter more on phones than they ever did on desktops. The Level A and AA additions most relevant to apps:
- Target Size (Minimum), 2.5.8, AA. Targets must be at least 24 by 24 CSS pixels, or spaced so that size is available around them. The Apple and Google minimums above are larger, so meeting the platform guidance usually covers this.
- Dragging Movements, 2.5.7, AA. Anything done by dragging, such as sliders, reordering lists or moving a map pin, needs a single-tap alternative.
- Accessible Authentication (Minimum), 3.3.8, AA. Login must not depend on remembering, transcribing or solving something unless an alternative exists. Allow pasting into password and code fields, support password managers and passkeys, and offer biometrics or one-time code autofill.
- Focus Not Obscured (Minimum), 2.4.11, AA. A focused element must not be hidden behind sticky headers, banners or the on-screen keyboard.
- Redundant Entry, 3.3.7, A, and Consistent Help, 3.2.6, A. Do not make people re-enter information they have already given, and keep help in the same place on every screen.
How do you build accessibility into the brief and acceptance criteria?
Write it into the contract and every user story, because retrofitting after launch is slower and costlier than building it in.
- [ ] Contract clause: the app will conform to WCAG 2.2 Level AA as applied to native apps, on the iOS and Android versions you support, verified by manual screen reader testing of named key flows.
- [ ] Design system: contrast-checked colours, text styles that scale, minimum target sizes and visible focus states, all defined before screens are designed.
- [ ] Development: native components first, labels on every interactive element and automated accessibility checks in the build pipeline.
- [ ] Acceptance criteria: each story includes "can be completed with VoiceOver and TalkBack" and "works at the largest text size".
- [ ] Content: captions, transcripts and descriptions for meaningful images.
- [ ] Release testing: a manual audit before launch, recorded alongside your app store submission checklist.
- [ ] Feedback: an accessibility statement and a way to report problems from inside the app.
- [ ] Maintenance: re-test after major releases and operating-system updates.
None of this is only about compliance. More people can use the app, and clearer labels, larger targets and simpler logins help every user, which is exactly why accessibility is good business.
Frequently asked questions
Is accessibility a legal requirement for apps in Australia?
There is no app-specific law, but the Disability Discrimination Act makes it unlawful to discriminate against people with disability in providing services, and that includes services delivered through an app. The AHRC's digital guidelines point to WCAG as the way to meet that obligation.
Which WCAG level should my app meet?
WCAG 2.2 Level AA. It is the benchmark the AHRC's guidance points to, and the level most Australian organisations and government agencies work to. Level AAA is worth applying selectively, but is not expected across a whole app.
How do I test my app with a screen reader?
Turn on VoiceOver on iPhone or TalkBack on Android in the accessibility settings, then complete each key task using swipes and double-taps without relying on sight. Check that every element is announced clearly, focus moves logically, and errors and pop-ups are read out.
Does WCAG apply to native apps or only websites?
WCAG was written for web content, but its principles and most success criteria apply to native apps, and the W3C's WCAG2ICT guidance shows how. The AHRC's guidelines cover mobile apps directly, so treat WCAG 2.2 AA as the app standard too.
Who handles accessibility complaints in Australia?
The Australian Human Rights Commission. It investigates complaints under the Disability Discrimination Act and tries to resolve them through conciliation. If that fails, the complainant can take the matter to the Federal Court or the Federal Circuit and Family Court of Australia.
Build it accessible from the first sprint
We design and build apps for Australian businesses with WCAG 2.2 AA in the brief, the design system and the test plan, not bolted on at the end. Send us your app or your idea for an accessibility review, or book a free call.