Short answer. The Web Content Accessibility Guidelines (WCAG) are the international standard for making websites and apps accessible to people with disability. The current version is WCAG 2.2, and Level AA is the target for almost every Australian organisation. It is built on four principles (perceivable, operable, understandable and robust) and contains 86 success criteria, 55 of them at Levels A and AA.

WCAG 2.2 for Australian organisations: why it matters and how to use it

The Web Content Accessibility Guidelines (WCAG) are the international standard for making digital content accessible to people with disability. Developed by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative (WAI), WCAG is referenced in accessibility laws and policies across dozens of countries. For any organisation that wants its websites and apps to be accessible, and to demonstrate that accessibility to regulators, customers and partners, WCAG is the primary benchmark.

For Australian organisations, the stakes are concrete. The Australian Bureau of Statistics 2022 Survey of Disability, Ageing and Carers found that 5.5 million Australians (21.4% of the population, more than one in five) live with disability. WCAG is the practical standard Australian businesses, governments and not-for-profits use to make sure those people can actually use their websites and apps, and it is the standard Australian courts and regulators look to when accessibility is tested.

The current version, WCAG 2.2, became a W3C Recommendation on 5 October 2023, and in 2025 it was also published as an international standard, ISO/IEC 40500:2025. It builds on earlier versions rather than replacing them.

WCAG matters because it turns a vague aspiration, “our website should be accessible”, into something specific, testable and demonstrable. Rather than relying on opinion or good intentions, organisations can measure their websites and apps against precise, internationally agreed criteria, identify exactly where they fall short, and demonstrate conformance with confidence.

This guide explains:

  • how WCAG is structured
  • what each of its four principles means in practice
  • how the three conformance levels work
  • what changed in WCAG 2.2
  • how WCAG applies in Australia
  • how conformance is tested
  • how to apply the guidelines in real projects
  • what is coming in WCAG 3.

It is written for people who commission and own websites and apps, rather than for accessibility specialists, so it favours clear explanation and concrete examples over technical detail.

A brief history: how WCAG developed

WCAG has evolved over more than two decades.

  • WCAG 2.0 (2008) established the structure still used today.
  • WCAG 2.1 (2018) added 17 success criteria, with a particular focus on mobile accessibility, low vision and cognitive disability.
  • WCAG 2.2 (2023) added nine further criteria and removed one that was no longer needed.

Each version builds on the last rather than replacing it, so the guidelines have grown steadily more comprehensive. You will still see all three versions referenced in laws, contracts and procurement requirements, but for new work, WCAG 2.2 is the version to build against.

The four principles of WCAG (POUR)

Every WCAG success criterion sits under one of four foundational principles, commonly remembered by the acronym POUR: Perceivable, Operable, Understandable and Robust.

These principles are the conceptual heart of WCAG. Understanding them is more valuable than memorising individual criteria, because they explain why the criteria exist.

Perceivable

Information and interface components must be presentable to users in ways they can perceive. No information should be available through only one sense, because not every user has access to that sense.

In practice, this means:

  • providing a text alternative for every image that conveys meaning, so that a person using a screen reader receives the same information as a sighted user
  • providing captions for video and transcripts for audio, so that people who are deaf or hard of hearing are not excluded
  • ensuring sufficient colour contrast between text and its background, so that people with low vision or colour vision deficiency can read it
  • never relying on colour alone to convey meaning. For example, marking an invalid form field in red only, with no text or icon, fails this principle because a colour-blind user cannot perceive the distinction.

Example: On a product page, the only indication that an item is on sale is that its price is shown in red. A sighted customer sees the sale instantly; a colour-blind customer, or a screen reader user, receives no such signal. The fix is to add a visible “Sale” label and make sure the screen reader announces it. The information is now available regardless of how the user perceives the page.

Operable

User interface components and navigation must be operable: every user must be able to actually use the controls, not just perceive them.

Key implications:

  • Everything that works with a mouse must also work with a keyboard alone, because many people, including those with motor disabilities and most screen reader users, do not use a mouse.
  • Users must have enough time to read content and complete tasks, and should be able to extend or turn off time limits.
  • Content must not be designed in ways known to cause seizures, such as rapid flashing.
  • Navigation must be clear and consistent, with descriptive page titles, logical heading structure, and mechanisms like “skip to content” links.

Example: A checkout where the “Place order” button can only be clicked with a mouse, and cannot be reached or activated by pressing Tab and Enter, is not operable. A keyboard user, including someone using a screen reader, simply cannot complete the purchase. The fix is to make the control keyboard-focusable, activate it with the keyboard, and give it a visible focus indicator.

Understandable

Information and the operation of the interface must be understandable.

This means:

  • content should be readable and written as plainly as the subject allows
  • unnecessary jargon should be avoided, and unfamiliar terms explained
  • the interface should behave predictably: interacting with a component should not trigger an unexpected change of context, such as automatically submitting a form or navigating to a new page when a user selects an option
  • forms should provide input assistance: clear labels, plain-language error messages, and guidance on how to correct mistakes.

Understandability is especially important for people with cognitive and learning disabilities, but it benefits everyone.

Example: A form that clears every field the moment a single validation error occurs, with only a generic “submission failed” message, fails this principle. The understandable approach keeps the user’s input, identifies exactly which field needs attention, and explains how to fix it (for example, “Please enter a valid email address, for example name@example.com”).

Robust

Content must be robust enough to be interpreted reliably by a wide range of user agents, including assistive technologies, and to keep working as technologies evolve.

In practice, robustness comes from:

  • using valid, well-structured code
  • applying correct semantics: building interface elements so that assistive technologies can accurately determine what each element is, what state it is in, and how to interact with it.

Example: A custom-built control that looks like a checkbox but is not coded with the correct underlying semantics may be invisible or meaningless to a screen reader, which cannot tell whether it is checked or even that it is a checkbox at all. Building it on robust, standard foundations, or correctly conveying its role and state, makes sure it works with the assistive technologies people actually use, today and in the future.

WCAG conformance levels: A, AA and AAA

WCAG defines three levels of conformance, reflecting increasing degrees of accessibility. The levels are cumulative: each builds on the one before.

  • Level A is the minimum level. It addresses the most basic accessibility requirements: the barriers that, if present, make content impossible for some people to use at all.
  • Level AA is the level most organisations and regulators target. It removes the most common and significant barriers and gives a level of accessibility that works for most people with disability using assistive technology. When a law, contract or policy refers to “WCAG conformance” without naming a level, it almost always means Level AA.
  • Level AAA is the highest level. It provides the most comprehensive accessibility, but it is rarely required across a whole website or app, because some AAA criteria cannot reasonably be met for every type of content. Organisations usually apply AAA selectively, to especially important content.

WCAG 2.2 contains 86 success criteria in total. Meeting Level AA means meeting all 55 criteria at Levels A and AA. For the great majority of Australian organisations, WCAG 2.2 Level AA is the right and sufficient target.

What changed in WCAG 2.2

WCAG 2.2 builds on WCAG 2.1 rather than replacing it. It adds nine new success criteria and removes one, 4.1.1 Parsing, which modern browsers and assistive technologies made redundant, bringing the total to 86.

The nine new criteria focus on keyboard focus, pointer and touch interactions, and cognitive accessibility. Six are at Levels A or AA, so they count in a standard audit:

  • 2.4.11 Focus Not Obscured (Minimum), AA: the element with keyboard focus must not be completely hidden by sticky headers, cookie banners or other overlapping content.
  • 2.5.7 Dragging Movements, AA: anything done by dragging, such as a slider or reordering a list, must also work with a single click or tap.
  • 2.5.8 Target Size (Minimum), AA: buttons and links must be at least 24 by 24 CSS pixels, or have enough space around them.
  • 3.2.6 Consistent Help, A: help options such as contact details or a chat button must appear in the same place across pages.
  • 3.3.7 Redundant Entry, A: people should not be asked to re-enter information they have already given in the same process.
  • 3.3.8 Accessible Authentication (Minimum), AA: logging in must not depend on a memory or puzzle test, such as retyping characters, unless there is an alternative like allowing paste and password managers.

The other three are at Level AAA:

  • 2.4.12 Focus Not Obscured (Enhanced): no part of the focused element is hidden.
  • 2.4.13 Focus Appearance: focus indicators must be large and high-contrast enough to see easily.
  • 3.3.9 Accessible Authentication (Enhanced): no cognitive test at all, even with an alternative such as recognising objects.

Most of these will feel like common-sense usability improvements, because they are. WCAG 2.2’s additions narrow the gap between “technically accessible” and “genuinely usable”. Most of them also live in shared components such as buttons, headers, forms and login screens, so fixing the component fixes every page that uses it.

WCAG in Australia

Australia has no single “WCAG law”, but WCAG sits underneath most of the rules that apply to websites and apps.

  • The Disability Discrimination Act 1992 (DDA) makes it unlawful to discriminate against people with disability in providing goods, services and information, and that includes websites and apps. Maguire v SOCOG (2000) and Innes v State of Queensland (2018) confirmed it applies online. The Australian Human Rights Commission recommends WCAG 2.2 Level AA as the minimum.
  • Australian Government websites must meet the Digital Service Standard and the Digital Inclusion Standard, which both require the latest version of WCAG, currently 2.2.
  • Government ICT procurement uses AS EN 301 549:2024, which covers documents, software and hardware as well as web content. Its web clause still references WCAG 2.1, but federal agencies should ask for WCAG 2.2.
  • State and territory governments have their own digital standards. Most point to WCAG, though some still name older versions.

For the government detail, see our article on AS EN 301 549 and WCAG 2.2 for government websites. For the business perspective, including legal risk, see Web Accessibility for Australian Businesses: A Complete Guide.

How WCAG conformance is tested

No single test tells you whether a website or app conforms. A reliable assessment combines several methods, each of which catches things the others miss.

  1. Automated testing. Tools such as axe and WAVE scan pages quickly for issues a machine can detect, such as missing alt text, low contrast and unlabelled form fields. They are a useful first pass, but they check only part of WCAG. Most criteria need human judgement.
  2. Expert manual review. An accessibility specialist works through each relevant success criterion on a representative sample of pages and templates, following a recognised method such as the W3C’s WCAG-EM. This is where most conformance decisions are made.
  3. Assistive technology testing. Key pages and journeys are tested with the tools people actually use: screen readers such as NVDA, JAWS, VoiceOver and TalkBack, screen magnification, keyboard-only navigation and voice control.
  4. Testing by people with disability. People who use assistive technology every day work through real tasks. WCAG does not require it, but it is the most reliable way to find out whether something that technically conforms actually works.

A good audit report states the WCAG version and level tested, the scope, the method and the date, and gives a result for each success criterion with a prioritised plan for anything that does not yet conform.

Applying WCAG in practice

Understanding the principles and levels is the starting point; applying them is where the real work lies. A practical WCAG program combines four things.

Accessibility built into design and build:

  • checking contrast before colours are finalised
  • making sure everything works with a keyboard
  • keeping a logical heading structure
  • designing forms with clear labels and error handling
  • testing shared components once, so every page built from them benefits.

Structured testing to confirm conformance:

  • using automated tools to catch common, machine-testable issues
  • conducting expert manual review against each criterion
  • testing key journeys with assistive technology
  • testing with people with disability.

Fixing in priority order. Start with the barriers that stop people completing important tasks, such as signing in, paying or applying, then work through the rest. Retest fixes to confirm they work.

Keeping it current. Websites and apps change constantly, and every release can introduce new barriers. Ongoing monitoring catches regressions between audits, and a full retest after major redesigns, and at least once a year for websites and apps in active development, keeps your evidence current.

Looking ahead: WCAG 3

The W3C is developing WCAG 3, and published an updated working draft in September 2026. It is not a standard yet, and the W3C says it will not be finished for a few more years. It will have a different structure and a new way of measuring conformance, and WCAG 2 will not be withdrawn for several years after WCAG 3 is complete.

For now, WCAG 2.2 Level AA remains the standard to meet. The W3C itself says meeting WCAG 2.2 is the best way to prepare for WCAG 3.

Frequently asked questions

What does WCAG stand for?

Web Content Accessibility Guidelines. They are published by the World Wide Web Consortium (W3C).

What is the current version of WCAG?

WCAG 2.2, published in October 2023. WCAG 3 is still a draft.

How many success criteria does WCAG 2.2 have?

86 in total, across Levels A, AA and AAA. Level AA conformance means meeting the 55 criteria at Levels A and AA.

The Disability Discrimination Act makes inaccessible websites and apps a discrimination risk, and WCAG is the accepted way to show you have met that obligation. Australian Government websites must meet WCAG 2.2 under the Digital Service Standard and Digital Inclusion Standard.

Which level should we aim for?

Level AA. It is the level referenced by Australian law, government policy and procurement, and the level the Australian Human Rights Commission recommends.

Can an automated tool or overlay make a website conform?

No. Automated tools check only part of WCAG, and an overlay is not evidence that the underlying website or app conforms. Conformance needs expert manual review and assistive technology testing.

How often should we test?

After significant redesigns or major releases, and at least once a year for websites and apps in active development, with monitoring in between.

  • WCAG 2.2 checklist: all 86 success criteria in plain English
  • Web Accessibility for Australian Businesses: A Complete Guide
  • AS EN 301 549 and WCAG 2.2: the accessibility standards Australian government websites must meet in 2026
  • Component accessibility on government websites: what to ask your builder
  • How to choose a digital accessibility consultant in Australia
  • Top Accessibility Issues and How to Fix Them
  • How to Conduct a DIY Accessibility Audit

Talk to us

Want to know where your website or app stands against WCAG 2.2 Level AA? Book a free 15-minute call and we will tell you what an audit would involve for your site.