WCAG 2.2 content requirements for government: the criteria your content team owns, not developers

WCAG 2.2 is now the version Australian government must meet, and several of its new success criteria are content decisions, not code. If you write, structure, or sign off web content for a government agency, this guide covers the WCAG 2.2 content requirements that land on your desk, and what to do about each one.

Here is the part most agencies get wrong. They hand all of WCAG 2.2 to developers. Consistent Help, Redundant Entry, and Accessible Authentication are won or lost in copy, instructions, and page structure, and a developer cannot fix a content problem.

The obligation is not optional. The Digital Inclusion Standard requires agencies to apply the latest version of WCAG, and the Disability Discrimination Act 1992 makes accessibility a legal duty. WCAG 2.2 added nine success criteria over 2.1. This guide covers the ones a content team owns.

The WCAG 2.2 content requirements government teams keep mishandling

Three of the new criteria are decided almost entirely in content:

• Consistent Help (3.2.6), Level A

• Redundant Entry (3.3.7), Level A

• Accessible Authentication, Minimum (3.3.8), Level AA

Levels A and AA are both mandatory for government. Two of these three sit at Level A, the baseline floor, so an agency that misses them is not just below best practice, it is below the minimum. You can read all nine additions on the W3C "What's new in WCAG 2.2" page.

Before you start

You need three things: the list of WCAG 2.2 AA criteria, edit access to your help and support content, and a walk-through of your agency's forms and sign-in flows. You do not need to be a developer. You do need to be in the room when forms and authentication are designed.

Step 1: Sort the new criteria into code and content

Split WCAG 2.2's nine additions into what a developer fixes and what you fix. Developers own the visual and interaction criteria: Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), and most of Target Size (2.5.8). You own the rest.

Log the content criteria against content, not the development backlog. If Consistent Help, Redundant Entry, and Accessible Authentication sit in a developer queue, they will not get fixed, because the fix is a sentence, a label, or a page pattern.

Why it matters: accessibility audits return these as failures, and "waiting on dev" is not a defence when the problem is wording.

Step 2: Put help in the same place on every page (Consistent Help, 3.2.6)

What to do: choose one help mechanism and place it in the same relative position across every page in a service. If a "Get help" link with a phone number sits in the footer on one page, it sits in the footer on all of them.

Why it matters: people who navigate by screen reader, or who rely on memory, should not have to re-find help on each screen. Moving it breaks the pattern they have learned.

Consistent Help is a placement decision, not a feature you build. Decide the pattern once, document it, and hold every team to it.

Step 3: Stop asking for the same information twice (Redundant Entry, 3.3.7)

What to do: in any multi-step process, do not make people re-enter information they already gave you in the same session, unless it is essential, such as re-confirming a password for security.

Why it matters: re-typing an address or a reference number is a memory and motor load that falls hardest on people with cognitive or physical disability. It is also a common point of form abandonment.

You can find most redundant entry by walking through your own form. If step 1 captures a postal address and step 4 asks for it again, auto-populate it, or show it back and ask "Is this still correct?". The wording is yours to write.

Step 4: Write authentication people can complete (Accessible Authentication, 3.3.8)

What to do: make sure people can sign in without solving a cognitive function test, such as transcribing characters, solving a puzzle, or recalling a one-time code with no support. Allow copy and paste, support password managers, and give a clear recovery path.

Why it matters: cognitive function tests lock out people with memory and processing disabilities. The criterion does not ban security. It bans security that depends on a memory test with no alternative.

Most authentication barriers are written ones: the instruction, the error message, and the recovery path. If your screen says "Enter the code from your email", let people paste it, tell them where to find it, and offer a plain recovery option when it expires.

Step 5: Treat the cognitive-support criteria as plain language by another name

What to do: read the instruction-heavy criteria, such as clear labels, error identification, and help text, as a plain language brief. Apply the Style Manual's accessible content guidance to every label, hint, and error message.

Why it matters: a team that already writes to an Australian Year 7 reading level, and tests its instructions on real users, is most of the way to the cognitive-support intent of WCAG 2.2.

At the content layer, accessibility and plain language are the same discipline. The Style Manual sets this out in Make content accessible.

Step 6: Get into the room where forms and authentication are designed

What to do: make sure a content person reviews every form, sign-in flow, and help pattern before it ships, not after an audit flags it.

Why it matters: in my experience, the most consistent accessibility failure is not ignorance of WCAG. It is that nobody at the design table has a brief to ask whether a person can read and complete the screen.

WCAG 2.2 compliance is a governance question as much as a content one: who reviews content before release, and who signs it off.

What good looks like

When this is working, you can name which WCAG 2.2 criteria your content team owns, and they are logged against content, not the development backlog. Help appears in the same place across the service. Your forms do not ask for the same detail twice. Sign-in instructions can be read, pasted, and recovered. A content reviewer sees every form before it goes live.

So here is the test. If an auditor opened your busiest online form tomorrow, would the failures be code, or would they be words?

Photo by halacious on Unsplash.