Website Accessibility Audit: What It Covers, How It Is Reported and What It Takes to Fix

A website accessibility audit is a structured test of your site against a named standard. For most Australian organisations that standard is WCAG 2.2 at Level AA. The output is a report that tells you which barriers exist, who they affect, and what it takes to remove them.

The word “audit” gets used for very different things, from a free browser plugin score to a multi-week manual assessment. This post explains what a proper one covers, how the findings should arrive, and what to do so the fixes last. For what changed in the standard itself, see our post on WCAG 2.2 AA for Australian organisations.

What a WCAG 2.2 AA audit covers

WCAG 2.2 was published as a W3C Recommendation on 5 October 2023 and republished with errata fixes on 12 December 2024. Level AA means passing every Level A and Level AA success criterion. Six of the nine criteria added in 2.2 sit at A or AA. An audit tests those criteria against a defined sample of your site.

The W3C’s WCAG Evaluation Methodology (WCAG-EM) is the usual structure: define the scope and conformance target, explore the site, select a sample, evaluate, then report. The scope step decides most of the cost, so it is worth being precise about the templates and journeys that matter: sign-up, checkout, search, forms, and anything that takes payment or personal details.

Inside that scope, a thorough audit works through these areas:

• Automated scan. Missing labels, empty links, broken heading order, missing language attributes and some contrast failures.
• Keyboard testing. Every control reachable and operable without a mouse, in a sensible order, with a visible focus indicator. WCAG 2.2 adds a check that a sticky header or cookie banner does not hide the focused control.
• Screen reader testing. Pages and components read out with correct names, roles and states, on at least one desktop and one mobile screen reader.
• Colour and contrast. Text, icons and form borders against their real backgrounds, in each theme. We cover why scanners get this wrong in the contrast failures automated tools miss.
• Forms and errors. Labels, instructions, error messages that say what to fix, no repeated data entry, and logins that allow a password manager or paste.
• Documents and PDFs. Tagged structure, reading order, alt text and form fields in downloadable files. These are often the largest backlog on a public-sector or association site.
• Mobile and touch. Reflow at 320 CSS pixels, zoom, orientation, target size and alternatives to dragging.
• Media. Captions, transcripts and controls for anything that plays.

Audit method: what it catches and what it misses

No single method is enough, which is why an audit that stops at a scan is not an audit. The W3C notes that “most accessibility checks are not fully automatable.”

Method	What it catches	What it misses
Automated scan	Missing alt attributes, unlabelled fields, duplicate IDs, heading order, many contrast failures, missing page language	Whether alt text or labels are meaningful, focus order, keyboard traps, error message quality, contrast on images and gradients
Keyboard-only testing	Traps, missing or hidden focus, illogical order, controls that only work on hover or click, drag-only actions	Name, role and state problems that only a screen reader announces
Screen reader testing	Wrong or missing names, roles and states, broken live regions, confusing reading order, unlabelled icon buttons	Visual-only issues such as low contrast, small targets and layout at zoom
Visual and responsive review	Contrast, text spacing, reflow, zoom, target size, orientation	Anything that depends on the code behind the interface
Document and PDF review	Untagged PDFs, wrong reading order, missing alt text, inaccessible form fields	Problems in the web page that links to the file
Testing with disabled users	Real-world friction that passes every criterion on paper	Broad coverage: it samples a few journeys rather than every criterion

Our own experience with scanners backs this up. When we built a contrast checker for this site, 14 of its first 21 findings were artefacts of the checker, not real failures. A green scan score is a floor, not a verdict.

How findings are reported and prioritised

A useful report is something your team can act on. It should record:

• The criterion and level, for example 2.5.8 Target Size (Minimum), Level AA.
• Where it occurs: the page or component, ideally with a screenshot or a code reference.
• The user impact: who is blocked and how.
• A recommended fix, written for a developer or designer.
• A priority, so you can sequence the work.

Group findings by whether they block a task, hinder it, or are an annoyance. A keyboard trap in checkout blocks a task. A low-contrast placeholder hinders it. Prioritise by the number of journeys a barrier sits in, as well as how severe it is: the same unlabelled icon button repeated in a shared header is one fix with a site-wide effect.

You should also expect a statement of what was tested and how: the sample, the browsers and assistive technologies, and the conformance target. That statement is what a tender or internal risk owner asks for, and it should be honest about gaps. A claim of full conformance that does not survive scrutiny is worse than a qualified one.

What it takes to fix versus to audit

The audit is usually the smaller piece of effort. Fixing is where the work sits, and it varies by the type of finding:

• Content and design fixes are quick: alt text, link wording, heading structure, colour values, error copy.
• Template and component fixes take more care but pay back, because one corrected component fixes every page that uses it.
• Structural fixes are the heavy end. If a component library has no keyboard support, or a custom date picker, carousel or mega menu was built from unlabelled elements, the component gets rebuilt rather than adjusted.
• Documents scale with volume. A few hundred legacy PDFs can outweigh the entire website remediation, and the usual answer is to fix the high-traffic ones and publish the rest as accessible HTML going forward.

The practical lesson is the one we put on our accessibility compliance page: deciding contrast, focus states, target sizes and keyboard paths at design time costs far less than retrofitting them. On a recent membership-body website we specified WCAG 2.2 AA in the statement of work, so the criteria were part of the build rather than a late discovery. Overlay widgets cannot fix the underlying markup, so the fixes belong in the code.

The Australian context

Disability Discrimination Act 1992. The Act applies to anyone providing goods or services, “whether for payment or not”. It does not mention websites or WCAG. The Australian Human Rights Commission’s guidance treats online services as services covered by the Act. We are developers, not lawyers, so take advice on your own obligations.

Australian Human Rights Commission guidance. The Commission’s older web advisory notes carry a notice saying they are no longer current, and in 2025 the Commission published Guidelines on equal access to digital goods and services. Its chapter on digital accessibility says organisations “should conform with WCAG 2.2 at a minimum Level AA”. These are guidelines rather than legislation, but they show what the Commission considers reasonable.

Government. The Digital Transformation Agency’s Digital Service Standard asks agencies to comply with the Disability Discrimination Act 1992, the “latest version of the Web Content Accessibility Guidelines (WCAG)” and the Australian Government Style Manual. The Style Manual names WCAG 2.2 as current. NSW and Victoria also name WCAG 2.2 AA. If you supply government, build to the version your contract names, and to 2.2 where it names none.

AS EN 301 549:2024. This edition supersedes the 2020 and 2016 editions. It is Australia’s adoption of the European standard for ICT accessibility, used in procurement. The Commission says its requirements should be met, but because it references WCAG 2.1, WCAG 2.2 should be used where appropriate. In a tender, ask whether the buyer wants conformance reported against both.

Keeping it from regressing

An audit is a snapshot. The first release after it can undo the fixes, so build the checks into how you work:

• Automated checks in CI. Run an accessibility rule set such as axe against key templates on every pull request, and fail the build on new violations. This catches the mechanical regressions for almost no effort per release. It does not replace manual testing, so keep a short keyboard and screen reader checklist for releases that change interaction.
• Design tokens. Put colour pairs, focus ring styles and minimum target sizes in tokens, and only publish pairs that pass contrast. Designers then cannot pick a failing combination by accident.
• Accessible components. Build or buy a component set with keyboard support and correct names, roles and states, and test each component once, thoroughly. Pages assembled from it inherit the result.
• Content rules. Give editors a short guide on alt text, headings, link wording and PDFs, and make authors check files before publishing.
• Training. Designers, developers and editors each need the part of WCAG that applies to their role. Short, role-specific sessions work better than a long policy document.
• A re-audit schedule. Re-test key journeys when you redesign, change platforms or add a major feature.

If you want a tested starting point, our UX and UI design work covers the design-time half of this.

---

Sources: WCAG 2.2, WCAG-EM and Selecting Web Accessibility Evaluation Tools (W3C), Digital Service Standard criterion 3 (DTA), Standards and guidelines for digital accessibility (Australian Human Rights Commission), Disability Discrimination Act 1992 (Federal Register of Legislation), all checked November 2026.