Digital services have become the default front door for government, education, and enterprise in Australia and New Zealand. As more transactions, applications, and enrolments move online, regulators and the public are paying closer attention to whether those services actually work for people with disabilities. In Australia, the Disability Discrimination Act 1992 (DDA) has been used for over two decades to challenge inaccessible websites, and the Australian Human Rights Commission (AHRC) sharpened that scrutiny in April 2025 with new guidance affirming WCAG 2.2 Level AA as the practical benchmark for digital goods and services. In New Zealand, the Government Web Accessibility Standard 1.2, effective March 2025, formally requires public service web pages to conform to WCAG 2.2 at Level AA.
Against that backdrop, “running a scan” is no longer a credible substitute for an audit. A WCAG audit is a structured evaluation process, not a single tool output, and organisations that treat it as the latter tend to discover the gap during a complaint or procurement review rather than before one. Understanding what digitale Zugänglichkeit actually requires, and how it differs from automated website accessibility checking, is the first step toward a defensible compliance position.
This guide walks through what a proper WCAG audit involves, the steps required to run one, and the regional considerations specific to Australian and New Zealand organisations. A proper WCAG audit combines structured scoping, automated validation, manual evaluation, and documented remediation planning, all aligned to WCAG 2.2.
What Is A WCAG Audit?
A WCAG audit is a systematic evaluation of a digital property against the Web Content Accessibility Guidelines, typically version 2.1 or WCAG 2.2, to determine where it meets or fails specific success criteria. WCAG defines three conformance levels: A (minimum), AA (the level expected by most regulators, procurement frameworks, and government standards in the region), and AAA (an enhanced level not mandated in full). An audit measures conformance against named, testable criteria rather than a general impression of “accessible” or “inaccessible.”
Every success criterion sits under one of four principles, commonly abbreviated as POUR: content must be Perceivable, Operable, Understandable, and Robust. A genuine audit assesses all four across every relevant surface, not just the homepage or a marketing site. This includes web pages and portals, but also downloadable documents such as PDFs, which are explicitly in scope under both Australian guidance and the New Zealand Government Web Accessibility Standard.
It’s worth being precise about what an audit is not. Automated scanning tools are valuable and necessary, but they mechanically detect only a subset of WCAG failures, generally somewhere between 18 and 30 percent depending on the tool and the site’s complexity. Criteria that depend on human judgment, such as whether alt text is meaningful, whether a focus order makes logical sense, or whether an error message is genuinely understandable, require manual testing and often direct testing with assistive technology. A WCAG audit is only complete when it pairs automated coverage with manual evaluation and produces documentation mapping findings to specific success criteria,and remediation steps. Human rationale and expert analysis is what separates an audit from a scan, and it’s what makes the resulting compliance position defensible if it is ever challenged.
Step 1: Define Scope And Standards
Before any testing begins, scope needs to be agreed and written down. Audits that start without a defined scope tend to drift toward whatever pages are easiest to test, producing an incomplete picture and a false sense of confidence. Defining the standard you’re testing against matters just as much, since “WCAG comformant” means very different things depending on which version and level is named.
Select The Appropriate WCAG Version And Level
WCAG 2.1 and WCAG 2.2 share the same foundational structure, but 2.2 adds new success criteria addressing cognitive accessibility, motor impairment, and mobile interaction patterns that 2.1 does not cover, including requirements around focus visibility, target size, and avoiding redundant data entry. Both the AHRC’s 2025 guidance and the New Zealand Government Web Accessibility Standard 1.2 now point to WCAG 2.2 AA, making it the practical benchmark for Australasia organisations regardless of sector. Level AA is the level expected almost everywhere compliance is assessed; AAA criteria are valuable in specific contexts but aren’t a realistic blanket target for most digital estates. Whatever version and level you select, document it as the explicit standard for the audit and align it with any internal accessibility policy already in place, so there’s no ambiguity later about what “pass” or “fail” meant.
Define Audit Scope Clearly
Scope should be defined by user journey and page template, not by guesswork. A representative scope typically includes public-facing informational pages, authenticated member or client portals, transactional workflows such as applications, payments, or bookings, the high-traffic templates most users actually encounter, embedded third-party tools and widgets (booking engines, chat tools, payment gateways), and downloadable PDFs. Auditing only the homepage is one of the most common ways organisations end up with a false sense of compliance, because homepages are frequently the most polished page on a site and rarely representative of the forms, tables, and interactive components buried deeper in the experience.
Step 2: Conduct Automated Accessibility Testing
Once scope is defined, automated testing is the efficient starting point. Automated tools scan rendered HTML and CSS against a subset of WCAG success criteria and can run across hundreds or thousands of pages in a fraction of the time manual testing requires. They’re particularly effective at catching pattern-based, code-level failures: missing or empty alt attributes on images, insufficient color contrast ratios, heading structures that skip levels or are used for visual styling rather than document structure, and form fields lacking programmatically associated labels.
Tools such as Grackle Check und Grackle Go are useful here for establishing a fast, repeatable baseline across a site or document set before manual testing begins. That said, automated results should be treated as a starting inventory, not a conclusion. Automated tools can’t judge whether alt text is meaningful in context, whether a tab order makes logical sense, or whether a custom widget actually behaves correctly for assistive technology users; those judgments require a person. Any audit that stops at the automated scan stage is reporting partial coverage, not WCAG compliance.
Step 3: Perform Manual WCAG Evaluation
Manual evaluation is where audit credibility is established, because it tests what automated tools structurally cannot assess: actual usability with a keyboard, with a screen reader, and through interactive components built with custom scripting. This stage takes the most time and expertise, and it’s the one most commonly skipped by organisations relying on tooling alone.
Keyboard Navigation Testing
A tester should unplug the mouse and navigate the entire scoped journey using only a keyboard, verifying that tab order follows a logical reading sequence, focus indicators are visible at every stop, skip links are present and functional for bypassing repetitive navigation, no keyboard trap exists where focus becomes stuck inside a component, and modal dialogs correctly capture and return focus when opened and closed.
Screen-Reader-Tests
This stage verifies the experience makes sense when consumed audibly rather than visually. Testers check that heading hierarchy is logical and accurately reflects document structure, that landmark regions (header, navigation, main, footer) are correctly identified so users can jump between sections, that form fields announce their labels, required status, and validation errors correctly, and that reading order matches the visual layout.
Interactive Component Testing
Modern interfaces lean heavily on custom-built components, dropdowns, tabs, carousels, accordions, that don’t behave like native HTML elements unless properly coded. Testing here covers whether ARIA roles, states, and properties are implemented correctly and update as the component changes state, whether dynamic content updates (live search results, form validation) are announced to assistive technology, and whether error messaging is both visible and programmatically associated with the relevant field.
Step 4: Test Real User Journeys
Beyond testing individual pages and components in isolation, a complete audit walks through entire journeys end to end, the way a real user would move through the site. This typically includes completing and submitting forms, lodging an application, booking a service or appointment, logging into and navigating an authenticated portal, and opening or interacting with linked documents.
PDFs deserve specific attention here, since they’re frequently the weakest point in an otherwise accessible digital journey. A government form, annual report, or policy document published as an untagged or poorly structured PDF can undo the accessibility work done on the surrounding website, and PDFs are explicitly within scope under both Australian guidance and the New Zealand standard. Tools like Grackle PDF are built specifically to test and remediate document accessibility issues that page-level scanners typically miss entirely. The broader point of this step is that a WCAG audit evaluates whether a person can actually complete a task, not just whether individual elements pass isolated technical checks.
Step 5: Document Findings Against WCAG Criteria
Findings are only useful if they’re recorded in a way someone outside the audit team, an engineering lead, a procurement officer, a regulator, can act on or verify. Each issue should be mapped to the specific WCAG success criterion it violates, rather than described in general terms, so remediation teams know precisely what “fixed” looks like.
Each finding should include a screenshot or code reference, or clear reproduction steps so a developer or content author can confirm the issue without re-running the entire audit, and a recommended remediation approach. Once findings are assessed, include a remediation roadmap with realistic timelines, providing a prioritised plan helps to drive remediation. This level of documentation supports a defensible accessibility compliance position: it demonstrates that issues were identified systematically, prioritised reasonably, and tracked to resolution, rather than addressed reactively after a complaint.
Australasia Regulatory Considerations
Regional regulatory context shapes how urgently and how broadly an organisation should be auditing, but it’s worth being clear about what this section is and isn’t: it’s regulatory awareness to inform planning, not legal advice, and organisations should consult their own legal counsel on specific obligations. What’s consistent across both Australia and New Zealand is that WCAG, now specifically WCAG 2.2 AA, has become the technical benchmark referenced when assessing whether a digital service meets accessibility expectations.
Australia – Disability Discrimination Act (DDA)
The Disability Discrimination Act 1992 prohibits discrimination against people with disabilities in the provision of goods and services, and it has been applied to websites since Maguire v. Sydney Organising Committee for the Olympic Games in 2000, which established that the DDA’s reach extends to digital services. The AHRC, the statutory body responsible for investigating discrimination complaints, issued updated guidelines in April 2025 on equal access to digital goods and services, pointing specifically to WCAG 2.2 Level AA as the benchmark for assessing whether an organisation’s digital products and services meet its obligations. This applies across both public and private sector organisations providing public-facing digital services, not government agencies alone.
New Zealand – Web Accessibility Standard
New Zealand’s approach is more directly prescriptive for the public sector. The New Zealand Government Web Accessibility Standard 1.2, effective 17 March 2025, requires that every web page within scope, a definition that explicitly includes web applications and documents such as Word files and PDFs, conform to WCAG 2.2 at Level AA, subject to a small number of defined exceptions. The Standard is mandatory for Public Service departments, the Defence Force, Police, and the Parliamentary Counsel Office, and other public sector and local government organisations are encouraged, though not required, to adopt it. For any organisation delivering services to or alongside New Zealand government agencies, alignment with this standard is increasingly treated as an expectation rather than a recommendation.
Common WCAG Audit Mistakes
Even organisations that commit to running an audit can undermine its value through a handful of recurring mistakes. The most frequent is relying solely on automated tools and presenting the scan output as a complete audit, which leaves the criteria most likely to genuinely block users, focus order, meaningful alt text, custom component behavior, untested. Closely related is the homepage-only trap, where the most visible and best-resourced page on a site is tested while the deeper templates, forms, and transactional flows carrying the most user activity are left unexamined.
PDFs and other downloadable documents are routinely excluded from scope entirely, despite being explicitly covered by both Australian and New Zealand guidance and frequently being where accessibility breaks down hardest. Third-party SaaS tools and embedded widgets, booking systems, chat interfaces, payment processors, are another common blind spot; organisations test their own code while assuming embedded vendor tools are “someone else’s problem,” even though the end user experiences them as part of the same journey. Finally, two structural mistakes tend to erode long-term compliance regardless of how good the initial audit was: failing to retest after remediation, which leaves no verification that fixes actually resolved the underlying issue, and treating the audit as a one-time project rather than a recurring discipline, which guarantees compliance erodes as the site evolves and new content is published.
When To Engage Professional Accessibility Auditors
Some organisations can run a credible first-pass audit internally, particularly smaller sites with limited templates and straightforward content. But there are scenarios where internal resourcing alone is unlikely to produce a result that will hold up to scrutiny. Complex enterprise platforms with many content types, custom components, and integrated third-party systems require specialised testing depth and tooling that’s difficult to build in-house from scratch. Organisations with high regulatory exposure, large public-facing government services, financial institutions, or universities serving large and diverse student populations, carry more risk if an audit misses something material.
Thanks to the Australian accessibility procurement standard AS EN 301 549, Government procurement processes increasingly require documented evidence of WCAG conformance as a condition of contract award, which means an internally run, informally documented audit may not satisfy the evidentiary bar a procurement officer is required to apply. And in litigation or formal complaint scenarios, independent, third-party validation carries more weight than self-assessment, both because it removes any question of bias and because experienced auditors are familiar with methodologies like WCAG-EM, the W3C’s Website Accessibility Conformance Evaluation Methodology, which structures sampling and evaluation in a way that’s recognised and repeatable. In any of these scenarios, a structured, independently validated audit is a materially stronger position to be in if the result is ever questioned.
Schedule Your Strategic WCAG Audit Today →
Building A Sustainable WCAG Compliance Program
A single audit, however thorough, is a snapshot. Digital properties change constantly, new pages, new features, new content, and without a program in place, conformance achieved today erodes within months. Durable compliance treats accessibility as an operational discipline rather than a project with an end date.
- Establish Accessibility Governance. Assign clear executive accountability for accessibility outcomes, rather than leaving it as an unowned responsibility scattered across content, design, and development teams.
- Conduct A Baseline WCAG Audit. Use the structured process outlined above to identify systemic issues across the digital estate, not just isolated defects on individual pages.
- Prioritise Remediation Strategically. Address the issues that block the most users from completing the most critical tasks first, rather than working through findings in the order they were discovered.
- Integrate Accessibility Into Development Workflows. Build automated checks and manual review gates into design and development processes so new accessibility issues are caught before publication, preventing regression of work already completed.
- Schedule Regular Re-Audits. Revisit the full audit process on a recurring cadence to confirm that remediated issues stay fixed and that newly published content meets the same standard.
A WCAG Audit Is The Starting Point, Not The Finish Line
A WCAG audit’s value lies in what it makes visible: the specific, documented barriers preventing people with disabilities from using a digital service fully. But identifying those barriers is only half the work. Sustainable digital accessibility depends on governance, integrated development workflows, and a recurring audit cadence that prevent the same issues from quietly reappearing months later. For Australasia organisations operating under increasing regulatory attention from the AHRC and the New Zealand Government Web Accessibility Standard alike, accessibility is best treated not as a one-off remediation sprint, but as an ongoing operational discipline with the same rigor applied to security or data governance.
If your organisation is preparing for a WCAG audit or aligning with WCAG 2.2 standards, speak with the GrackleDocs team about a structured assessment that supports long-term accessibility compliance.