The WCAG 2.2 AA Checklist, in Priority Order

Why WCAG 2.2 Is the Standard Australian Sites Should Meet

WCAG 2.2 is the current W3C accessibility standard, and Level AA is the conformance level Australian organisations are expected to meet. This follows from section 67(1)(k) of the Disability Discrimination Act 1992, which requires goods and services — including online content — to be provided on an accessible basis, with the AHRC advising WCAG 2.2 AA as the benchmark (aligned to EN 301 549). For government and many large organisations, meeting WCAG conformance is mandatory rather than advisory.

WCAG 2.2 also tightened and expanded on 2.1. The criteria that most often break existing sites are the new Focus Not Obscured (Minimum) and Target Size (Minimum) requirements, plus refined versions of Consistent Help and Redundant Entry. If your site was last checked against WCAG 2.1, it is worth re-testing against 2.2.

Priority 1 — Criteria That Block People Entirely

These are the failures that make a site genuinely unusable for someone, and the ones to fix first. Almost none of them require a redesign.

1.1.1 Non-text Content — every meaningful image needs a text alternative that conveys the same information; decorative images need empty alt attributes so screen readers skip them.

2.1.1 Keyboard — all functionality must be operable by keyboard alone. If you cannot tab to and use your own contact form, nothing else matters.

2.4.7 Focus Visible — a keyboard user must always see where they are. If focusing a link or button shows no visible change, this fails.

3.3.2 Labels or Instructions — form inputs need associated <label> elements, not just placeholder text, which vanishes as soon as someone types.

1.4.3 Contrast (Minimum) — body text needs at least a 4.5:1 contrast ratio (3:1 for large text). This is the single most common automated failure on Australian business sites.

2.4.6 Headings and Labels — headings and labels must describe their topic or purpose, so a screen-reader user navigating by heading can make sense of your page.

Priority 2 — Criteria That Cause Real Friction

These do not usually make a site unusable, but they meaningfully degrade the experience — especially for screen-reader, keyboard and low-vision users.

2.5.8 Target Size (Minimum) — new in WCAG 2.2. Interactive targets should be at least 24×24 CSS pixels, with spacing exceptions. Small, tightly packed buttons and links are a common failure.

2.4.11 Focus Not Obscured (Minimum) — also new in 2.2. Sticky headers, chat widgets and cookie banners must not cover the element you are tabbing to.

1.4.10 Reflow — content must not require two-dimensional scrolling (sideways) at 320px width or 400% zoom.

1.4.4 Resize Text — text must be resizable to 200% without loss of content or functionality.

3.3.3 Error Suggestion — if a form submission fails, identify the error and suggest how to fix it, in text — not just a red border.

2.4.6 and 3.1.2 — ensure the page language is declared, and any language changes within the page are marked, so pronunciation is correct.

Priority 3 — Criteria That Are Easy Wins

Lower-impact, but quick to fix and worth doing in a single pass once you are in the code.

2.4.1 Bypass Blocks — provide a way to skip repeated navigation (a skip-to-content link).

2.4.2 Page Titled — every page needs a descriptive, unique <title>.

2.4.4 Link Purpose — link text should make sense out of context; avoid bare "click here" or "read more".

3.3.1 Error Identification — errors are described in text and tied to the field.

1.3.1 Info and Relationships — use semantic structure (real lists, tables and headings) rather than styled <div>s, so assistive tech can convey the relationships.

1.4.12 Text Spacing — content must survive user-applied spacing overrides without being clipped.

Why Checklists Are Not Enough on Their Own

This list is a genuine starting point, but conformance is not something you can confirm from a checklist alone. Automated scanners catch perhaps 20–30% of real issues. The failures that matter most — is this form usable by keyboard, are errors announced, is this navigation comprehensible — can only be confirmed by actually using the site the way an assistive-technology user would.

Treat the checklist as your manual test plan: work through it with a keyboard only, then with a screen reader, then zoomed to 200% and reflowed to 320px. If you cannot complete your key user journeys under those conditions, a professional audit will find it quickly. Our website accessibility service does exactly this — automated scan combined with real assistive-technology testing.