WCAG 2.1 AA Compliance: What It Actually Means for Australian Organisations

Clients usually arrive at this topic one of three ways: a tender asked for it, a participant or patient complained, or somebody sent a scary email offering to fix their non compliance for a fee. This article explains what the standard is, where it sits legally in Australia, what conformance costs and how long it takes. It is the what and the why. Our website accessibility checklist covers the how, item by item.

What WCAG is and who publishes it

WCAG stands for the Web Content Accessibility Guidelines. It is published by the World Wide Web Consortium, the international body that maintains the standards behind the web, through its Web Accessibility Initiative. It is not an Australian invention and it is not owned by any vendor. That international neutrality is exactly why governments and procurement teams around the world reference it instead of writing their own rules.

The guidelines are built on four principles. Content must be perceivable, operable, understandable, and robust. Under those principles sit thirteen guidelines, and under those sit the testable success criteria that people actually audit against. WCAG 2.0 was published in 2008, WCAG 2.1 in 2018, and WCAG 2.2 in 2023. Each version adds criteria without removing old ones, so meeting 2.1 AA means you also meet 2.0 AA.

A, AA and AAA: why everyone targets the middle

The three conformance levels are not difficulty ratings. They reflect how essential a criterion is and how practical it is to apply across all content types.

One detail worth knowing: conformance is claimed per page, and a page only conforms if it fully meets every criterion at that level. There is no such thing as 87 per cent AA compliant in the formal sense, however useful that number is for tracking progress internally.

The Australian legal position, in plain terms

We build websites; we are not lawyers, and nothing here is legal advice. If you need certainty about your own exposure, speak to a solicitor. What follows is the general position as it is commonly understood in the industry.

Australia does not have a statute that says "your website must meet WCAG 2.1 AA". What it has is the Disability Discrimination Act 1992, a federal law that makes it unlawful to discriminate against a person on the basis of disability in areas including the provision of goods, services and facilities. A website through which you provide information about your services, take bookings or accept payments is generally understood to fall within that. The Act does not name a technical standard; it describes an outcome, which is that people with disability are not treated less favourably.

The Australian Human Rights Commission, which administers complaints under the Act, has published guidance on web accessibility for many years. That guidance points to WCAG as the practical means of meeting obligations under the Act. In other words, the law sets the duty and WCAG is the accepted way to demonstrate you have discharged it.

Complaints under the Act typically start with conciliation through the Commission rather than court proceedings. Most matters resolve there, quietly, with an agreement to remediate. That is a good thing, but it also means there is little public case law and organisations wrongly conclude nothing ever happens. Australia's best known web accessibility matter, brought against the Sydney Organising Committee for the Olympic Games over its website in 2000, was decided in the complainant's favour and remains the reference point people cite.

Government websites

Australian government agencies operate under a firmer requirement. Through the National Transition Strategy, all federal, state and territory government websites were required to meet WCAG 2.0 Level AA, with that commitment carried forward into the Digital Service Standard. Many agencies have since moved to 2.1 AA in practice. The practical consequence for private business: if you tender for government work, or you subcontract to an organisation that does, accessibility conformance will appear in the contract. We see it in NDIS related tenders and health service procurement constantly.

Why NDIS and healthcare providers carry a heavier practical obligation

The legal duty is the same for a cafe and a support coordinator. The practical obligation is not, for three reasons.

First, your audience. If you are an NDIS provider, a meaningful proportion of the people reading your site have a disability. That is the entire market. A site that fails keyboard navigation is not failing an abstract minority; it is failing your primary customer, and they will simply go to the provider whose booking form works. We make this argument constantly during NDIS website development projects, and it lands better than any compliance framing.

Second, the funding relationship. NDIS providers, particularly registered ones, operate within a quality and safeguards framework built around participant rights, choice and dignity. An inaccessible website sits awkwardly against provider obligations around accessible communication and informed choice. Auditors have started asking about it.

Third, professional standards. Allied health practitioners registered with AHPRA work under codes of conduct requiring clear communication with patients and advertising that is not misleading. Publishing intake forms that a portion of your patients cannot complete is difficult to defend. If you run a clinic, our notes on allied health website design cover how this intersects with AHPRA advertising rules.

Aged care providers face the same logic from the other direction. Your website is mostly read by people over 70 and by adult children researching on their behalf. Low vision, reduced dexterity and hearing loss are the norm in that audience, not the exception. Everything AA asks for, larger contrast ratios, resizable text, captions, generous touch targets, is the same thing good aged care marketing would ask for anyway.

What WCAG 2.1 added, and why it matters more than it sounds

WCAG 2.0 was written when the iPhone was a year old. WCAG 2.1 added seventeen success criteria across three areas that 2.0 had barely addressed: mobile devices, low vision, and cognitive or learning disability. Five of them sit at AA and are the ones you need to care about.

• Orientation (1.3.4): content must not be locked to portrait or landscape only. Someone with a wheelchair mounted tablet cannot rotate their device.
• Identify Input Purpose (1.3.5): common fields such as name, email and address must be marked with autocomplete attributes so browsers and assistive tools can fill them in.
• Reflow (1.4.10): content must work in a 320 pixel wide column without horizontal scrolling. This is the criterion that makes desktop zoom and mobile usable for people with low vision.
• Text Spacing (1.4.12): if a user increases line height and letter spacing through their own stylesheet, nothing may break or overlap.
• Content on Hover or Focus (1.4.13): tooltips and hover menus must be dismissible, hoverable and persistent, rather than vanishing the moment the pointer drifts.

Plus a set of A level additions covering pointer gestures, motion actuation, label in name and status messages. If your site was built to 2.0 AA and never touched since, reflow and hover content are where you will fail first.

Should you be targeting 2.2 instead?

WCAG 2.2 adds nine criteria, including a 24 by 24 pixel minimum target size, consistent help placement, and accessible authentication that does not force people to solve cognitive puzzles. Most Australian procurement still specifies 2.1 AA. Our advice is to write 2.1 AA into your contracts and build to 2.2 anyway, because the extra criteria are mostly cheap and the standard will move under you within a couple of years.

What an audit involves and what it costs in AUD

A proper audit is manual testing by a person, supported by automated scanning, not a scan alone. The scope is normally a representative sample of page templates rather than every URL, because a 400 page site usually has fifteen distinct templates and the same defects repeat.

Remediation is the bigger number and it varies enormously. On a well built site with a modern component library, fixing AA failures is often three to eight days of developer time. On an ageing theme with a page builder, custom sliders and a bolted on booking system, it can exceed the cost of rebuilding. That is a genuinely common finding, and we say it plainly when it happens: if remediation is 60 per cent of the cost of a new build, do the new build. Our pricing page sets out where accessibility work sits within a full project, and it is not an optional extra in anything we ship.

If you are commissioning a new site rather than fixing an old one, insist on accessibility being written into the specification before design starts. Retrofitting AA onto a finished design typically costs three to five times what building it in would have, because the colour palette, the interaction patterns and the component structure all have to be reopened. Any competent web development partner should be quoting it in by default.

Accessibility statements

An accessibility statement is a public page describing the conformance level you aim for, how you tested, what is known to fall short, and how someone can report a problem and get help another way. It is not a legal shield. It is a genuinely useful document, and it demonstrates good faith if a complaint ever arises.

Keep it honest. A statement claiming full conformance on a site that fails contrast in six places is worse than one that says "we meet AA on our main templates, our older PDF forms do not yet meet the standard, and we are replacing them by December". Include a real email address and phone number, and make sure someone answers them. Date the statement and review it annually.

The honest truth about overlay widgets

You have probably seen the pitch. A single line of JavaScript, a little accessibility icon in the corner, a monthly fee of maybe 60 to 200 AUD, and claims of instant WCAG and DDA compliance. We get asked about these constantly, so here is our position without hedging.

They do not achieve conformance. An overlay runs in the browser after your page loads and tries to guess at fixes. It cannot rewrite a heading structure that carries no meaning. It cannot invent accurate alt text for a photo it has never seen, and the machine generated descriptions it produces are frequently wrong in ways that mislead rather than help. It cannot fix a keyboard trap in a third party booking widget. It cannot caption your video. The criteria overlays actually address are a small subset of AA, and those are usually the cheapest ones to fix properly anyway.

Worse, they can interfere. Screen reader and magnifier users already have their software configured the way they want it. An overlay that hijacks focus, changes ARIA attributes at runtime or injects its own keyboard shortcuts can break tools that were working fine. Thousands of accessibility practitioners and assistive technology users have signed public statements opposing overlays, and there have been legal actions in other jurisdictions against businesses that installed one and were sued anyway. An overlay does not stop a complaint; in some cases it has been cited as evidence the organisation knew about the problem and chose a cosmetic response.

There is one narrow, honest use: a personalisation widget offering optional preferences such as larger text or a dyslexia friendly font, marketed as a convenience feature and not as compliance, sitting on top of a site that already meets AA. That is fine. It is also, notably, not what most of these products are sold as.

Where to start if you are starting today

Run Lighthouse and axe on your five most important pages this afternoon, and Tab through your contact form with no mouse. That costs an hour and tells you whether you have a small problem or a big one. Then decide whether to remediate or rebuild, get a written scope with dates, publish an accessibility statement once you have something true to say, and put a recurring calendar entry six months out to check it has not regressed. Accessibility decays the moment someone uploads a PDF or drops in a new plugin, so treat it as maintenance rather than a project with an end date.

Frequently Asked Questions