You cannot outsource accountability for accessible content

When a vendor builds your government website, the agency keeps the accessibility obligation. You can delegate the build. You cannot delegate the duty you owe the person using the service.

This guide is for the content lead or digital manager inside a procurement. Often with little formal power, and owning the site after the vendor leaves.

The Australian Human Rights Commission (AHRC) states the principle. Organisations can contract out the provision of digital goods or services. They cannot contract out their equal access responsibilities.

Under the Disability Discrimination Act 1992, section 24 attaches liability to whoever provides the service to the public. For a government website, that is the agency.

One nuance worth carrying into the room, because a lawyer will raise it. This does not make the supplier immune. A supplier can be a respondent in its own supply chain. The Act's ancillary liability provisions also reach a person who causes, instructs, induces, aids or permits an unlawful act.

What a contract can shift is commercial risk. What it cannot shift is the agency's duty to the person using the service.

A standard named in a tender does not produce an accessible site. The brief and the contract do.

Before you start

You need 3 things before you write a line of the brief:

• the standards, paired the right way, which the next section sets out

• a content model, or at minimum a list of the page types and components the site needs

• agreement from your procurement contact that accessibility can be a mandatory requirement, not a weighted criterion a vendor can trade away

Get the standards right before you cite them

This is where most briefs go wrong, and it is worth 12 minutes of your life. Name 4 instruments, and say what each one does.

• WCAG 2.2 Level AA, the Web Content Accessibility Guidelines, for the web content and the interface.

• AS EN 301 549:2024, for procured components.

• The Australian Government Style Manual, for content quality. Criterion 4 of the Digital Inclusion Standard names it as a compliance instrument.

• AS ISO 24495.1:2024, for plain language. It is Australia's adoption of the international standard.

The Australian Human Rights Commission lists all 4 on one page, alongside the rest of the standards landscape. It is the best single link to send a procurement officer who asks what any of this means.

Then get the version pairing right, because this is the part that catches people.

AS EN 301 549:2024 adopts the European standard EN 301 549 V3.2.1 without change. That version references WCAG 2.1, not 2.2. The Commission says so, and tells agencies to apply WCAG 2.2 where appropriate instead.

So the 2 are complementary requirements with a known gap, not a matched pair. Version 4.1.1 of the European standard, expected during 2026, is the one that picks up WCAG 2.2.

Two cautions when you check that page, because it is a map rather than a source of truth. It says AS EN 301 549:2024 adopts V3.1.1, when it adopts V3.2.1. And it says the Digital Inclusion Standard applies to existing services from July 2025, when digital.gov.au says 1 January 2026. Take the landscape from the Commission and the dates from the DTA.

Be careful with the status too. AS EN 301 549 is a voluntary Australian Standard, and no instrument names it as mandatory.

What makes it bite is the Commonwealth Procurement Rules. Where a standard is applicable, tender responses must show capability to meet it, and contracts must then contain evidence of it. The Commission's position is that agencies should require AS EN 301 549 for any technology procurement.

That is a strong argument. It is not a blanket rule, and overstating it invites somebody to check.

Step 1: make accessibility a deliverable, not a principle

Write accessibility into the statement of requirements as a deliverable. Give it a name, a test and a sign-off point. Do not leave it as a value in the preamble.

A requirement you cannot test is a requirement the vendor can ignore. The site will be accessible is unenforceable. The site will conform to WCAG 2.2 Level AA, verified by independent audit before final payment, is a deliverable.

Tie payment to it. Hold a meaningful part of the fee against the accessibility sign-off. That makes conformance a commercial obligation rather than a goodwill gesture.

Step 2: set acceptance criteria the vendor signs up to

List the acceptance criteria in the contract, not the kick-off deck. At minimum: WCAG 2.2 Level AA across all templates. AS EN 301 549:2024 for procured software components. Keyboard and screen-reader operability for every interactive element.

Name the standard and the version. Latest accessibility guidelines drifts. WCAG 2.2 Level AA does not.

Be specific about scope. State that the criteria apply to every page template and component delivered. Error states, forms and documents included, not a representative sample.

For tested wording, use the CAUDIT accessible technology procurement guide. CAUDIT is the Council of Australasian University Directors of Information Technology. The Commission recommends it for any organisation, noting that it was designed for higher education and travels well beyond it.

Two cautions. Use it for the clauses and the process, not for standard versions, because its standards page still lists AS EN 301 549:2020. And use the link above, hosted by the Australian Disability Clearinghouse on Education and Training, which is the accessible version.

For a government-sector alternative, New South Wales publishes accessibility standards for technology procurement. It sets out a 3-round tender evaluation model and a downloadable sample declaration of conformance, which is the most practical thing of its kind in Australian government.

Take the process from it, not the versions. That page was last updated in June 2023 and still says NSW websites must meet WCAG 2.0 Level AA.

Step 3: require a conformance report before sign-off

Make an accessibility conformance report a condition of final acceptance. Such a report states which success criteria the product meets and where it falls short.

Ask for one against AS EN 301 549:2024 and WCAG 2.2 Level AA. A completed Voluntary Product Accessibility Template is one acceptable form. Do not make that the headline term. It is a template registered by a United States industry body and built around Section 508.

No conformance report, no sign-off, no final payment. Asking for it after launch means asking the vendor to fix problems on your budget, once you have paid them.

A credible report states its own limits on its face. The test method, the scope, the product version, the date, and whether somebody independent produced it. Ask for independent testing, covering delivered content rather than an empty template shell.

Step 4: make the vendor populate a content model you control

Give the vendor a content model and templates, and make them build to it. A content model defines your page types, fields and components. Content is then structured and reusable rather than poured into a free-text box.

A free-text page is where accessibility goes to die. Structured fields let you enforce heading order, alternative text and meaningful link text at the template level. An author then cannot ship an inaccessible page by accident.

Reference the Style Manual guidance on accessible content in the brief. Ask for templates that make the accessible choice the default one.

Note that the Style Manual's Make content accessible page was last updated on 7 July 2023, and its reference list still cites AS EN 301 549:2016 and WCAG 2.1. Use it for the content guidance and take your standard versions from elsewhere.

Step 5: specify who tests, with what content, and how

Name the testing approach in the contract. Automated checks, manual testing against WCAG 2.2, and testing with assistive technology by people who use it. Automated tools catch only part of the issues.

Test with real content, not lorem ipsum. A template can pass an audit empty. It fails the moment a long heading, a complex table or a real document goes in.

Build a remediation window into the schedule. State how long the vendor has to fix defects found in testing. The fix is at their cost, and it happens before sign-off.

Step 6: write a maintenance and handover clause

Specify what the vendor hands over so accessibility survives the contract. Documented templates, the content model, an accessibility statement, and training for the team who will maintain the site.

Accessibility is not a launch event. It is a maintained state. A site that meets WCAG 2.2 on handover will drift the first time an untrained author adds a page, unless governance and skills move across with the build.

Ask for an accessibility statement at handover. The Style Manual asks agencies to include one. It should explain how the agency has addressed WCAG, what the testing covered, and the extent of compliance.

Australia has no mandated format, unlike the European Union and the United Kingdom, which both prescribe a model statement. That gives you latitude and no excuse.

What good looks like

• Accessibility sits in the contract as a tested deliverable with payment held against it.

• The vendor built to a content model your agency owns.

• You hold a conformance report from independent testing, against a named standard and version.

• Your team holds the templates and the content model, and somebody trained them at handover.

• Nobody in the agency believes the vendor carries the legal duty.

So here is the test. If the vendor walked away tomorrow, could your team keep the site accessible?

If yes, the brief did its job. If no, the accountability was always going to land on the agency, and now it has nothing to stand on.

Photo by Roman Kravtsov on Unsplash.