Accessibility statements

An accessibility statement is a published page describing a website’s current accessibility position. It states what standard the site aims for, its known limitations, and how a visitor can report a problem or ask for an alternative way to access content. It is a transparency and communication tool, not a compliance certificate. It does not, on its own, meet the legal obligation described on website accessibility in Australia.

What a genuine WCAG accessibility statement should contain, per Australian Human Rights Commission guidance

Element	What it communicates
The standard being worked towards	e.g. WCAG 2.2 Level AA, stated plainly rather than vaguely
Current known limitations	Honest disclosure of areas not yet meeting the standard, if any
How to report a problem	A genuine, monitored contact method, not a dead-end form
An alternative way to access content, where relevant	e.g. a phone number for a visitor who cannot complete an online process
Date of the statement and when it was last reviewed	So a visitor and the business itself know how current the claim is

The standard most commonly referenced is WCAG 2.2 Level AA, consistent with the Australian Human Rights Commission’s April 2025 guidance on equal access to digital goods and services.

Why honesty about accessibility guidelines and limitations is more valuable than a blanket claim

A statement claiming full, unqualified compliance is a stronger and riskier claim than one that honestly notes specific known limitations and a plan to fix them. A genuine gap might later come to light — through a complaint, an audit, or a user report. When that happens, an honest statement that already acknowledged limitations, with a path to improvement, holds up far better than a blanket compliance claim the business cannot actually back up. This mirrors the honesty this site expects of any claim it makes about itself. That standard is covered generally on why published web design statistics are usually unsourced.

Why an accessibility statement is not a legal shield against a Disability Discrimination Act (DDA) claim

Publishing an accessibility statement does not satisfy the Disability Discrimination Act’s underlying obligation, and it is not a defence to a complaint on its own — the Act is concerned with whether a service is actually accessible, not with whether a business has published a document describing its intentions. Treat a statement as a transparency and communication measure that sits alongside genuine accessibility work. It is never a substitute for that work.

The reporting mechanism matters more than the statement’s wording, and inclusion in practice, not just being accessible on paper

A statement that invites feedback through a contact method nobody actually monitors — or a generic email address that reaches no one — undermines its own value, even if the wording is otherwise accurate. Confirm that whatever contact method is published is genuinely checked. A report of a real problem needs to reach someone who can act on it. It should not be a cosmetic addition to the site.

Keeping a statement current with legislation and guidelines across Australia

A statement dated several years ago, describing a standard the site may no longer actually meet — or may now exceed — is worse than no statement at all. It actively misrepresents the current position. Review and update the statement whenever a significant redesign or audit happens. Note the review date visibly, so a visitor can judge how current the claim actually is.

Where a website accessibility statement fits alongside an Australian business’s other obligations

An accessibility statement adds to, rather than replaces, the practical work covered across this cluster: testing keyboard operability, checking contrast, writing meaningful alt text. It also sits alongside the legal position covered on website accessibility in Australia. Publishing a statement with no underlying work behind it is a transparency gesture with nothing to actually be transparent about.

Why a statement should name a specific contact, not just a form

A statement that invites reports through a named role or a specific, monitored inbox generally performs better than one pointing only to a generic contact-us form buried among other enquiry types. Otherwise, a report of an accessibility barrier can sit unrecognised in a queue of unrelated general enquiries. If your business already has a clear escalation path for other kinds of customer complaints, extending the same path to accessibility reports is usually simpler than building a separate one.

What a good-faith statement communicates that a vague one doesn’t

A statement naming specific, genuine limitations — “video content published before [date] does not yet have captions, and we are working through a backlog” — signals a business that has actually assessed its own position. Compare that with a generic statement claiming commitment to accessibility “for all users”, with no specific detail. The specificity itself is the credibility signal, both to a visitor and to anyone later assessing whether the business took the matter seriously.

Where a statement should live and how visible it should be

An accessibility statement is generally most useful placed somewhere a visitor will reliably find it — commonly linked from a site’s footer, alongside privacy and terms pages. Do not bury it with no path to it. A statement that technically exists on the site, but that no ordinary visitor could realistically find, delivers little of the transparency value the document is meant to provide.

What to include about assistive technology testing, if any was done

Specific assistive technologies might have been used to test the site: a named screen reader, a particular browser and operating system combination. Naming them in the statement adds a further layer of specificity and credibility beyond a general claim of testing. It also gives a visitor using different technology a clearer sense of what has and has not been checked.

What to do next

If your business publishes or is considering an accessibility statement, write it honestly. Name the actual standard targeted, any genuine known limitations, and a real, monitored way to report a problem, rather than making a blanket claim. Where this sits among the other separate pieces of a website project is covered on the separate pieces of a website project.