Website Accessibility in Australia: Practical WCAG and Inclusive UX Guidance

Website accessibility in Australia means building sites that people with disability can use, including with a keyboard, screen reader, magnification or voice control. WCAG 2.2 is the technical standard to design and test against. The Disability Discrimination Act 1992 is the law that prohibits discrimination. Australian Human Rights Commission guidance connects the two. Most organisations should target WCAG 2.2 Level AA.

This guide is for Australian businesses, not-for-profits and product teams who want a practical plan rather than a lecture. It explains how best practice, the WCAG standard and legal obligations differ, what WCAG 2.2 changed, how to test properly, and how to sequence fixes. It is general information, not legal advice.

For generic depth, see our website accessibility guide, accessible UI/UX design, ecommerce accessibility and the ecommerce accessibility checklist. This page adds the Australian legal context, a criterion-level audit table and a remediation roadmap.

People often use ‘accessible’, ‘WCAG compliant’ and ‘legally compliant’ as if they meant the same thing. They do not, and the difference affects how you plan.

The best-known Australian web accessibility matter is Maguire v SOCOG. Bruce Maguire, who is blind and uses a refreshable braille display, complained in 1999 that the Sydney Olympics website was inaccessible. In August 2000, the Human Rights and Equal Opportunity Commission (now the Australian Human Rights Commission) found that the Sydney Organising Committee for the Olympic Games had engaged in unlawful discrimination under the DDA, and $20,000 in damages was ordered. The W3C case study reports that SOCOG had argued accessibility would cost $2.2 million, while expert evidence estimated far less.

Two points follow. First, the DDA can apply to websites and digital services. Second, the case was decided by a commission, not a court, and it is from 2000; it shows the principle rather than setting a current technical standard. Today's practical benchmark is WCAG 2.2, and the AHRC's 2025 guidelines are the current reference point for how the Commission sees digital access.

Complaints under the DDA are made to the Australian Human Rights Commission. If you are assessing your own legal exposure, speak to a lawyer; this article does not give legal advice.

The ABS Survey of Disability, Ageing and Carers 2022 found that 5.5 million Australians, or 21.4% of the population, have disability (ABS media release, 4 July 2024). Disability rates rise with age. That figure does not include people with temporary injuries, people using a phone in bright sun, or people whose first language is not English, all of whom benefit from the same design choices.

Accessibility is not only about screen readers. It covers people who navigate by keyboard or switch device, people who zoom to 200% or more, people with colour vision deficiency, people with tremors who struggle with small targets, and people with cognitive disability who need clear language and forgiving forms.

WCAG 2.2 was published as a W3C Recommendation on 5 October 2023, and the current edition of that Recommendation is dated 12 December 2024. It adds nine success criteria to WCAG 2.1 and removes 4.1.1 Parsing. The W3C notes that content conforming to WCAG 2.2 also conforms to 2.1 and 2.0, so targeting 2.2 is the simplest choice.

Most accessibility comes from using the right HTML element for the job. A real button element is focusable, works with Enter and Space, and announces itself as a button. A div styled to look like a button does none of that unless a developer rebuilds each behaviour by hand.

Check: one H1 per page and a logical heading order; landmarks for header, navigation, main content and footer; lists marked up as lists; data tables with header cells; links for navigation and buttons for actions; the page language set (en-AU) so screen readers pronounce text correctly. Good structure starts before code, in the information architecture. These map mainly to WCAG 1.3.1 Info and Relationships, 2.4.6 Headings and Labels, 3.1.1 Language of Page and 4.1.2 Name, Role, Value.

Everything that works with a mouse must work with a keyboard (WCAG 2.1.1), and focus must never get stuck (2.1.2 No Keyboard Trap). Focus order should follow the visual order (2.4.3), and the focused element must be visible (2.4.7).

WCAG 2.2 adds 2.4.11 Focus Not Obscured. The common failure is a sticky header, a cookie consent bar or a chat launcher covering the element that has focus as the user tabs down the page. Fixes include adding scroll padding equal to the sticky header's height, making consent banners non-overlapping or dismissible before content, and ensuring chat widgets do not sit over form fields.

Quick test: unplug the mouse. Tab from the address bar through the whole page. Can you see where focus is at every step? Can you open and close the menu, use filters, add to cart and complete a form? Does a skip link take you to the main content?

Forms are where accessibility failures cost the most, because they block enquiries, sign-ups and purchases. The W3C WAI forms tutorial recommends using the label element to label controls, grouping related controls, giving instructions and validating input with clear notifications.

Labels (1.3.1, 3.3.2): every field has a visible label that stays visible while typing; placeholder text is not a label. Errors (3.3.1, 3.3.3): identify the field in error in text, explain how to fix it, and do not rely on colour alone. Place error messages next to the field and announce them to screen readers. Autocomplete (1.3.5): use the right autocomplete values for name, email, address and phone, so browsers and assistive tools can fill them.

Redundant Entry (3.3.7): do not make people type the same information twice in one process. In a checkout, offer ‘billing address same as delivery’; in a multi-step application, carry details forward. Accessible Authentication (3.3.8): do not block paste in password or one-time-code fields, support password managers, and offer an alternative to puzzle CAPTCHAs. Our checkout UX guide covers the conversion side of the same patterns.

Contrast (1.4.3, 1.4.11): body text needs a contrast ratio of at least 4.5:1 against its background, and large text at least 3:1. Interface components and meaningful graphics, such as input borders and icons, need at least 3:1. Brand palettes often fail on light grey text and pale buttons; fix these in design tokens rather than page by page.

Alternative text (1.1.1): informative images need text alternatives that convey the same information; decorative images should have empty alt text so screen readers skip them. Product images need alt text that describes what matters to a buyer (colour, pattern, angle), not the file name.

Resize and reflow (1.4.4, 1.4.10): text should resize to 200% without loss of content, and content should reflow at a width equivalent to 320 CSS pixels without two-dimensional scrolling, except for things like data tables and maps. Test by zooming the browser to 400% on a desktop screen.

WCAG 2.5.8 Target Size (Minimum) requires pointer targets to be at least 24 by 24 CSS pixels, unless they are spaced so that a 24-pixel circle centred on each does not overlap another target, or another exception applies (an equivalent larger control, inline links in text, browser-default controls, or where the size is essential).

The usual failures are small icon buttons (close, quantity steppers, carousel dots), tightly packed filter chips and footer links. Many teams adopt a larger internal minimum for primary actions on mobile; 24 pixels is the AA floor, not a design goal.

2.5.7 Dragging Movements also matters on mobile: if a price-range slider or a reorderable list needs dragging, provide buttons or input fields as an alternative.

Custom components cause a large share of accessibility failures because each one has to reproduce behaviour that native elements provide. The WAI-ARIA Authoring Practices Guide documents expected keyboard interaction and roles for common patterns. Use it as the specification for your component library, and prefer native elements wherever they exist.

Screen readers behave differently across browsers and platforms, so test the combinations your users are likely to have. You do not need all of them for every release, but key journeys should be checked on at least one desktop and one mobile screen reader.

Automated scanning (axe DevTools, WAVE, Lighthouse, Accessibility Insights) finds some issues quickly and is worth running in development and in CI. But automated scans cannot confirm conformance. They cannot tell whether alt text is accurate, whether the focus order makes sense, whether an error message is helpful or whether a custom dropdown works with a screen reader.

Manual testing covers what tools cannot: keyboard-only passes, zoom and reflow checks, screen reader walkthroughs of key journeys, contrast checks on states (hover, focus, disabled), and review of content clarity. Testing with disabled people finds what experts miss, because real users bring their own settings, strategies and assistive technology. Pay participants for their time and recruit through disability organisations or specialist research panels.

Build it into the process: add accessibility acceptance criteria to tickets, annotate designs with focus order and labels, run automated checks on every pull request, and repeat a manual check of key journeys before each major release.

This table covers the checks we run first on most sites. It is not a full WCAG 2.2 audit, but it catches the issues that most often block real users.

Most audits produce a long list. The roadmap below turns it into a sequence. Timeframes depend on the size of the site and how much is in shared components, so we describe phases rather than promising durations. This is our working approach, not a formal standard.

Hypothetical scenario, not a client. An Australian online retailer with a custom theme runs an automated scan and gets a few hundred warnings. The team is tempted to work through the list from the top.

A manual pass tells a different story. A keyboard user cannot open the mobile menu, the size selector is a set of unlabelled divs, the cookie banner hides focused links at the bottom of every page, and the checkout blocks paste in the one-time code field. Those four issues stop purchases outright; most of the automated warnings are repeated instances of two template problems.

The team fixes the four blockers first, then corrects the product card and form components, which clears most of the scan warnings in one release. They add axe checks to their build, write alt text guidance for the merchandising team, and schedule a session with screen reader users before the next major redesign.

Accessibility is cheapest when it is built into the design system and component library from the start, and most expensive when it is bolted on after launch. When you brief a partner, ask how they test (and with which assistive technologies), whether accessibility criteria are part of their definition of done, how they handle third-party scripts, and what documentation you get at handover.

Our guides to choosing a web development company in Australia and website development costs in Australia cover the wider selection and budgeting questions. Accessibility also overlaps with conversion and security: see ecommerce conversion optimisation in Australia, website security in Australia and, for Shopify stores, Shopify development in Australia. If you are adding AI features such as chat or recommendations, AI ecommerce in Australia and AI customer service in Australia cover how to keep them accessible, and digital product development in Australia covers the wider product process. If those AI features make decisions about customers, see AI governance in Australia. Accessible, well-structured pages are also easier for search engines and AI tools to read, as our AI search visibility guide explains.

Standards: W3C, Web Content Accessibility Guidelines (WCAG) 2.2; W3C WAI, What's New in WCAG 2.2; W3C WAI, forms tutorial; W3C WAI-ARIA Authoring Practices Guide.

Australian guidance and policy: Australian Human Rights Commission, Guidelines on equal access to digital goods and services (April 2025); Digital Transformation Agency, Digital Service Standard Criterion 3.

Case and statistics: W3C WAI, SOCOG case study; ABS, 5.5 million Australians have disability (4 July 2024).

Requirements and guidance change; re-check before relying on them. Nothing here is ZSpace client data, and nothing is legal advice.

Website accessibility in Australia sits at the meeting point of a technical standard, a discrimination law and plain good design. WCAG 2.2 Level AA gives you a testable target, the DDA explains why it matters legally, and the AHRC's guidelines show how the Commission connects the two. None of that replaces testing with real people.

Start with the journeys that matter most, fix the shared components that cause the most issues, test with keyboards and screen readers as well as scanners, and build accessibility into how you design and release. The result is a site that more people can use, and fewer surprises later.