Understanding WCAG: A Complete Guide to the Web Content Accessibility Guidelines

What WCAG is, how it is structured, what changed in version 2.2, and how to apply the guidelines in practice.

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 digital products 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 ensure those millions of people can actually use their digital products, 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. It builds on earlier versions rather than replacing them, and is backwards‑compatible with WCAG 2.1.

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 digital products 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 to apply the guidelines in real projects.

It is written for people who commission and own digital products, 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 9 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 while remaining backwards‑compatible. 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
• 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 ensure 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 ensure the control is keyboard‑focusable, activates with the keyboard, and has 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 all the fields a user has entered the moment a single validation error occurs, with only a generic “submission failed” message, fails this principle. The understandable approach preserves the user’s input, identifies precisely 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 — ensures 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 establishes 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 specifying 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 an entire product, because some AAA criteria cannot reasonably be met for all types of content. Organisations typically apply AAA selectively to particularly critical content rather than site‑wide.

WCAG 2.2 contains 87 success criteria in total. 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 87.

If you meet WCAG 2.2 Level AA, you automatically meet WCAG 2.1 Level AA.

The nine new criteria focus on keyboard focus visibility, pointer and touch interactions, and cognitive accessibility:

• Focus Not Obscured (Minimum and Enhanced): a focused element must not be completely hidden behind sticky headers, banners or other overlapping content.
• Focus Appearance: focus indicators must be sufficiently visible.
• Dragging Movements: any action requiring dragging must have a simpler non‑dragging alternative.
• Target Size (Minimum): interactive targets such as buttons and links must be large enough to activate reliably.
• Consistent Help: help mechanisms must appear in a consistent location across pages.
• Redundant Entry: users should not be asked to re‑enter information they have already provided in the same process.
• Accessible Authentication (Minimum and Enhanced): logging in must not depend solely on a cognitive test, such as transcribing characters or solving a puzzle.

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”.

---

Applying WCAG in practice

Understanding the principles and levels is the starting point; applying them is where the real work lies.

A practical WCAG programme combines:

• Embedding accessibility into design and build
  • checking contrast before colours are finalised
  • ensuring keyboard operability
  • maintaining logical heading structure
  • designing forms with clear labels and error handling
• Structured testing to confirm conformance
  • using automated tools to catch common, machine‑testable issues
  • conducting expert manual review