Every accessibility guide we've read for Australian business owners has the same problem. It either patronises ("did you know images need alt text?") or it dumps the W3C specification in front of you and tells you to read 87 success criteria. Neither is useful. The first wastes your time. The second makes you give up and hire a consultant.

This is what we wish someone had handed us years ago: WCAG 2.2 Level AA, translated into the actual things a developer or a business owner needs to do, in roughly the order they come up in real projects. About 50 success criteria apply at the AA level, but they cluster into a much smaller number of concepts. If you understand the concepts, you can hold a vendor accountable. If you don't, you'll be billed for "accessibility" that doesn't deliver.

The opinion up front: WCAG isn't a checklist you reach the end of. It's a design philosophy. The teams who hit AA are the ones who learned the concepts during the build, not the ones who tried to retrofit a non-compliant site three months after launch. If your developer can't explain these criteria in plain English, they don't know them.

What WCAG actually is

WCAG — Web Content Accessibility Guidelines — is published by the W3C, the same body that maintains HTML and CSS. It comes in three levels: A (basic), AA (the legal standard in Australia and most of the world), and AAA (aspirational, rarely required commercially).

WCAG 2.2 is the current version. It was finalised in October 2023 and formally adopted by the Australian Human Rights Commission in its April 2025 guidelines. It builds on WCAG 2.1, which built on WCAG 2.0. Everything from earlier versions still applies — 2.2 added nine new success criteria, four of them at the AA level.

WCAG is organised under four principles, conveniently abbreviated POUR: Perceivable, Operable, Understandable, Robust. We'll go through each.

Perceivable: can people sense your content

Content has to be available through more than one sense. If it's only available through sight, blind users can't access it. If it's only available through hearing, deaf users can't access it.

Text alternatives for images

Every image that carries information needs alternative text. The alt attribute is read aloud by screen readers and shown when an image fails to load. The rule: describe what the image communicates, not what's in it literally.

A photo of your barista is not "man with beard holding cup." It's "Tom, our head barista, with a freshly pulled espresso." A logo is the business name. A decorative pattern in the background gets alt="" so screen readers skip it. The mistake everyone makes is writing alt text for the image rather than for the purpose the image serves.

Captions and transcripts for video and audio

If you embed a video, it needs captions. If you publish a podcast, it needs a transcript. If you have an audio player on the homepage, there needs to be a text version. YouTube auto-captions are a starting point but they're not accurate enough on their own. You either edit them or you use a service like Rev.

The often-missed bit: live video also needs captions if it's longer than a short clip. Live events streamed from a venue, webinars, town halls — captions required, real-time.

Colour contrast that's high enough to read

Body text needs a contrast ratio of at least 4.5:1 against its background. Large text (18pt+ or 14pt bold) needs 3:1. Icons and form input borders need 3:1.

The fix is non-negotiable but easy. Use a contrast checker — WebAIM's tool is the standard — and design from accessible colours rather than trying to make brand colours work after the fact. Light grey body text on a white background is the single most common WCAG failure on Australian SMB sites. It's also the easiest to fix.

Don't rely on colour alone to convey meaning

"Required fields are in red" fails WCAG. A red asterisk plus the word "required" passes. Charts that distinguish data series with colour alone fail; the same charts with patterns or labels pass. Error states that are only red fail; the same errors with an icon or text label pass.

This one trips up designers who came up through print. Print can use colour freely because everyone perceives it the same way. The web has colour-blind users (about 8% of men), partially-sighted users, and users in bright sunlight on a cheap phone screen. Colour is one channel of communication, not the only one.

Text resizable to 200% without breaking layout

Users who need larger text should be able to zoom the browser to 200% without horizontal scrolling and without content getting cut off. This is almost free if you build mobile-first with responsive design. It's nearly impossible if you used fixed pixel widths everywhere.

Reflow at 320 CSS pixels

Related to the above: at a viewport width of 320 pixels (a small phone), content has to reflow rather than scroll horizontally. Tables and code blocks are the exceptions, but even those need to behave sensibly. If your site requires horizontal scrolling on a phone, it fails this criterion.

Operable: can people use the controls

Every interactive element on your site has to be usable by someone who can't use a mouse — keyboard only, voice control, switch device, or screen reader.

Everything works with a keyboard

Tab through your site. Can you reach every link, every form field, every button? Can you trigger the menus, the modals, the carousels? If anything requires hover or click without a keyboard equivalent, it fails.

This is the single most common failure on custom-built sites that look good but were built without accessibility in mind. JavaScript widgets — sliders, dropdowns, accordions — frequently work on click but not on Enter or Space. The fix is to use standard HTML elements wherever possible and to add the right keyboard handlers when you have to roll something custom.

Visible focus indicators

When you tab to a link or button, there has to be a visible indication of where focus currently is. The browser default is usually a faint outline. Designers often "clean that up" with outline: none in their CSS, which kills accessibility. The 2.2 standard requires the focus indicator to be substantial — solid contrast, large enough to see, not obscured by other content.

The new 2.2 criterion Focus Not Obscured (Minimum) is the rule that sticky headers and chat widgets routinely violate. If a user tabs to a link near the top of a section and your sticky header covers it, you fail. Test by tabbing through your own site with all the chrome visible.

Target size at least 24×24 CSS pixels

A new 2.2 AA criterion. Every interactive element — buttons, links, icon controls — needs a hit area of at least 24 by 24 pixels. The rationale is users with motor impairments, users on touch devices, and users on shaky public transport. The Apple Human Interface Guidelines recommend 44×44; WCAG only requires 24×24. Either way, those tiny "x" icons on close buttons are usually too small.

Skip links and bypass mechanisms

A keyboard user shouldn't have to tab through the entire navigation on every page to reach the main content. A "Skip to main content" link at the top — visible when focused, hidden otherwise — fixes this. Three lines of CSS.

No content flashes more than three times per second

Photosensitive epilepsy. Don't build strobe effects. This one is rarely an issue on business sites but worth knowing exists.

Dragging movements have a non-dragging alternative

Another 2.2 addition. If your site requires drag-and-drop — for example to rearrange items in a list — there must also be a way to do the same thing without dragging, like up/down buttons. Drag-only interactions exclude users who can't perform that motor action.

Understandable: can people make sense of your content

Language declared on every page

The <html lang="en-AU"> attribute tells screen readers what language to speak in. Without it, an English page might be read in a Spanish accent — or worse. One attribute, set once, fixes this forever.

Consistent navigation and consistent help

Navigation should appear in the same place on every page. Help links — phone, email, chat — should be in the same place on every page. The new 2.2 criterion Consistent Help makes this explicit. Users with cognitive disabilities depend on consistency.

Labels and instructions on forms

Every form input needs a visible label. Placeholder text is not a label. "Email" written inside the field and disappearing on focus fails WCAG. A visible <label> element associated with the input passes.

Where input formatting matters — phone numbers, dates, postcodes — say so. "Date of birth (DD/MM/YYYY)" is accessible. "Date of birth" with no format hint is not.

Error identification and recovery

When a form errors, the error message must be visible and clearly associated with the field that failed. "Please correct the highlighted fields" with red borders is not enough — it's a colour-only signal. The message has to say what went wrong and how to fix it. Inline error text beneath the field, announced to screen readers, is the standard.

Redundant entry

Another 2.2 addition. If a user has entered information once in a session — say, a billing address — don't make them re-enter it for shipping unless functionally necessary. Auto-fill, copy-from-billing checkboxes, and pre-populated fields satisfy this.

Robust: does your code play nicely with assistive tech

This is the most technical category. The criteria are short but the implementation discipline matters.

Valid HTML and proper semantic markup

Use the right element for the job. Buttons should be <button>, not styled <div> elements. Headings should be <h1> through <h6> in a logical order. Lists should be <ul> or <ol>. Navigation should be inside <nav>. Forms should be inside <form>.

This is the area where templated platforms and page builders fall apart. Sites built with Elementor or Webflow often nest divs eight deep with no semantic meaning, breaking screen readers entirely. A hand-coded site can get this right by default.

Name, role, value for all interactive components

Every interactive element must expose its purpose to assistive technology. A custom dropdown built with divs needs the right ARIA roles and properties. A modal needs role="dialog" and proper focus management. A live region — content that updates dynamically — needs aria-live.

If you're building anything beyond standard HTML elements, you need a developer who knows the WAI-ARIA spec. Most don't. That's why standard HTML elements are preferable wherever possible.

Status messages

When content updates without a page reload — a search result count changes, a cart total updates, a form submission succeeds — the change must be announced to screen reader users via an aria-live region. Visible-only feedback isn't enough.

What the AA checklist looks like, in order

If you're auditing or building, work through it in roughly this sequence.

Run axe DevTools and Lighthouse. Fix everything they flag. (Catches about 30% of issues.)
Tab through every page from top to bottom. Note what you can't reach with a keyboard.
Check colour contrast on every text/background combination with WebAIM's checker.
Test forms — labels, error states, required fields, format hints.
Test focus indicators are visible and not obscured by sticky elements.
Verify alt text on every image. Decorative images get empty alt.
Verify captions on every video, transcripts on every podcast.
Check <html lang> attribute and heading hierarchy.
Test with a screen reader. VoiceOver on Mac, NVDA on Windows. Both are free.
Get someone who actually uses a screen reader to test. Charge $400-$800 for a few hours of their time. Worth every dollar.

The honest closing thought

WCAG AA is achievable on every site we've ever built, and it has been on our standard delivery checklist for years. It's not optional and it's not exotic. The reason most Australian SMB sites fail WCAG isn't that compliance is impossible — it's that the agencies that built them never bothered. The ones built on visual page builders frequently can't be made compliant without abandoning the platform entirely.

The new 2.2 criteria — focus visibility, target size, consistent help, redundant entry, dragging alternatives — are easy to hit if you know they exist. They're murder to retrofit if your site already shipped without them.

If you'd like us to run the full AA audit on your existing site and give you a prioritised list of what fails and what it would cost to fix, book a free audit. We'll be straight with you about whether your platform can get there, or whether the right move is a rebuild.

WCAG 2.2 AA Checklist — Plain English Guide (2026)