Australian Government Digital Standards: What a Website Redevelopment Must Prove, Not Merely Promise

A government website procurement can sound deceptively familiar: redesign the interface, improve navigation, migrate the content and launch a modern content management system. The real obligation is much broader. The project must demonstrate that the resulting service works for the people who need it, including people who face accessibility, language, connectivity, confidence or device barriers. It must also protect information, connect responsibly with other services, support accountable publishing and remain measurable after launch.

That distinction matters because a supplier can promise that a website will be “accessible”, “secure” or “user-centred” without defining the evidence that will prove it. If evidence is not designed into the delivery process, it often becomes a late-stage scramble: an accessibility scan after templates are built, a penetration test just before go-live, or a policy document that describes controls the operating team has not rehearsed.

The Australian Government’s current Digital Service Standard is outcome-led. Its ten criteria include clear intent, understanding users, inclusion, connected services, trust, reuse, avoiding harm, purposeful innovation, monitoring and keeping the service relevant. A website redevelopment should therefore be procured as a service transformation with a chain of evidence, not as a visual deliverable with compliance language attached.

Start by confirming which requirements actually apply

“Government standards” is not a single document. Commonwealth entities, state and territory agencies, local councils and government-funded organisations may face different mandatory policies, procurement rules, security classifications and recordkeeping obligations. The project team should identify the governing instruments before scope and price are fixed.

For non-corporate Commonwealth entities, the Digital Service Standard Version 2.0 transition has already moved beyond new projects. The official transition approach states that, from 1 July 2025, existing public-facing informational and transactional services owned by non-corporate Commonwealth entities were required to meet Version 2.0 or seek an exemption. The Standard’s scope page also identifies new or replacement public-facing services, new staff-facing services and existing public-facing services within its covered categories. See the transition approach and services covered.

The broader Digital Experience Policy includes three related standards:

the Digital Service Standard, focused on designing and delivering digital services
the Digital Inclusion Standard, focused on inclusive and accessible experiences
the Digital Access Standard, focused on reducing fragmented entry points and supporting unified access.

That policy structure is summarised on the Digital Experience Policy page. It means a project team should not treat the website as an isolated channel if the user’s real task crosses forms, identity services, call centres, portals, email and other agencies.

Other requirements can include the Australian Government Style Manual, branding guidance, the Protective Security Policy Framework, the Information Security Manual, privacy obligations, records authorities and the Hosting Certification Framework. The relevant set depends on the service, information classification, agency and technology. This is an area for agency governance, legal, privacy and cyber security owners to confirm; an implementation agency should not guess the compliance perimeter.

Accessibility is a design and operating requirement

The Digital Inclusion Standard requires agencies to make services accessible and comply with relevant legislation and standards, including the latest Web Content Accessibility Guidelines and the Australian Government Style Manual. Its accessibility criterion explicitly connects accessibility with the Disability Discrimination Act 1992 and current WCAG requirements. Australian Government digital guidance now references WCAG 2.2, and current government examples describe conformance at Level AA.

Accessibility cannot be proved by an automated score alone. Automated tools are useful for repeatable checks, but they cannot determine whether heading structure makes sense, error messages are understandable, keyboard focus follows a logical sequence, alternative text conveys the right meaning or a complex task is usable with assistive technology.

A credible evidence plan combines:

accessible design specifications and component states
keyboard-only testing across critical journeys
screen-reader testing with representative browser and device combinations
colour contrast, zoom, reflow and orientation checks
accessible forms, validation, status messages and error recovery
content checks for headings, links, tables, documents, captions and transcripts
testing with people who have relevant access needs
a documented defects process, ownership model and retest evidence.

The content management system also matters. If an editor can publish inaccessible headings, unlabelled links, uncaptioned media or poorly structured tables, the website can leave launch in good condition and degrade rapidly. The project must define authoring guardrails, training and ongoing governance as part of accessibility—not as an optional support activity.

The ten criteria need an evidence map

The Digital Service Standard is easiest to operationalise when each criterion is connected to decisions, artefacts, acceptance tests and an owner. The following evidence map is a practical starting point, not a substitute for the agency’s formal assessment approach.

Standard outcome	Evidence a redevelopment could produce
Clear intent	service vision, measurable outcomes, scope boundaries and baseline measures
Know your user	research plan, participant coverage, findings, validated needs and usability results
Leave no one behind	inclusion risks, accessibility evidence, assisted-digital pathways and content alternatives
Connect services	end-to-end journey maps, integration ownership, hand-off rules and failure states
Build trust	privacy notices, transparent status information, security controls and clear accountability
Do not reinvent the wheel	reuse assessment, design-system decisions and documented exceptions
Do no harm	risk assessment, safety considerations, exclusion analysis and escalation pathways
Innovate with purpose	hypothesis, controlled test, benefits, risks and decision criteria
Monitor your service	analytics design, operational monitoring, service measures and alert ownership
Keep it relevant	content lifecycle, improvement backlog, review cadence and retirement process

The Standard’s checklist says agencies need to meet all ten criteria. The important procurement question is therefore not “Will you comply?” It is “What evidence will be produced, at which delivery stage, and who has authority to accept it?”

Design the evidence across the project lifecycle

Discovery: establish intent, users, constraints and risks

Discovery should identify the service outcome, priority user groups, current evidence, constraints, dependencies, content estate, integrations, security classification, data handling, governance and measures of success. It should also expose disagreements before they become expensive. For example, a communications team may see the project as a publishing platform while a service owner sees it as the first step in a transactional journey.

The Digital Service Standard’s “Know your user” criterion requires agencies to understand users, conduct research and test and validate designs. That is set out in the official criterion guidance. Procurement should therefore allocate enough access, time and recruitment support for representative research rather than relying only on stakeholder opinions or existing analytics.

Discovery is also where scope confidence should be earned. If identity, data migration, integrations, personal information, multilingual delivery, legacy forms or complex governance are unresolved, a fixed implementation promise is premature. A paid Full Website Discovery can define the requirements, delivery architecture, risks, acceptance approach and realistic implementation pathway before a build commitment is made.

Alpha and design: test the risky assumptions

The design stage should prove that the proposed service model works before every template and integration is built. This can include low- and high-fidelity prototypes, content examples, accessibility annotations, component behaviours and tests of the hardest journeys.

Testing should cover more than the happy path. What happens when an identity check fails, a user does not have all required information, an integration is unavailable, a session times out or a person needs help? Government services often serve people under stress. Clear recovery paths and assisted alternatives are part of service quality.

Build and beta: turn requirements into traceable acceptance

During implementation, requirements should be traceable from the relevant standard or policy to a component, configuration, test and evidence record. This makes defects easier to manage and gives approvers something stronger than a supplier declaration.

The build evidence may include:

component-level accessibility and browser tests
integration contract tests and failure handling
security controls, code review and vulnerability remediation
privacy and data-flow validation
content migration reconciliation
performance budgets and test results
role and permission testing
analytics validation against a measurement plan
deployment, rollback and disaster-recovery procedures.

Live service: monitor, maintain and improve

The Standard includes “Monitor your service” and “Keep it relevant” because launch does not prove sustained compliance. The measuring success guidance says agencies are required to report on compliance and maintain continuous improvement against performance measures.

The operating model should therefore define who reviews analytics, accessibility findings, failed searches, content age, integration errors, complaints, cyber alerts and user feedback. It should also define how improvements are prioritised, approved and released. A warranty addresses eligible functional defects for a defined period; it is not a substitute for ongoing maintenance, optimisation, content governance or operational support.

Security, privacy and hosting need named owners

Government websites can process personal, sensitive, protected or operational information. Privacy and security decisions must be linked to the actual data flows, not generic statements in a proposal.

The Privacy Act includes 13 Australian Privacy Principles that govern collection, use, disclosure, governance, integrity, correction and access for covered entities. The OAIC’s APP overview and updated APP Guidelines should be considered with agency-specific privacy advice. APP 11 requires reasonable steps to protect personal information, including technical and organisational measures, as explained in the OAIC’s APP 11 guidance.

Hosting is also a procurement and risk decision. The Australian Government’s Hosting Certification Framework helps agencies identify hosting services that meet enhanced privacy, sovereignty and security requirements, according to Department of Finance guidance. The exact requirement should be confirmed by the agency’s security and procurement owners.

Emote does not sell or resell hosting infrastructure. Where hosting forms part of a website programme, Emote can help define application requirements, coordinate with an appropriate hosting partner or work with the client’s existing suitable provider. The client would normally contract and pay the hosting provider directly, preserving clear infrastructure accountability.

Procurement questions that expose delivery maturity

The following questions are more useful than asking for broad compliance assurances:

Which standards and policies have you assumed apply, and which require agency confirmation?
How will you trace each requirement to evidence and acceptance?
How will users with disability, low digital confidence, limited English or constrained connectivity be included in research and testing?
Which tests are automated, which are manual and which involve representative users?
How will integration failures and assisted-service hand-offs be designed?
Who owns privacy, security, content, analytics and service acceptance on each side?
What must be resolved in Discovery before implementation can be priced responsibly?
How will the CMS prevent or reduce inaccessible publishing?
What operational monitoring and continuous-improvement process begins at launch?
What evidence will the agency retain for assurance and future change?

Strong answers should identify methods, responsibilities and decision gates. A long list of certifications or technologies does not by itself prove that the delivery approach fits the service.

Common reasons compliant intentions fail

Compliance is deferred until testing

Testing can find defects, but it cannot cheaply repair a service model that excluded key users or an architecture that mishandles data. Standards need to influence requirements and design from the beginning.

The website boundary is drawn too narrowly

If the user journey continues into an external form, identity provider, CRM, PDF, call centre or another agency, those hand-offs determine the real experience. They must be included in journey and failure-state design even when another team owns them.

Evidence has no acceptance owner

Reports accumulate but nobody has authority to decide whether a risk is accepted, remediated or blocks launch. The governance model should name accountable owners and escalation paths.

Content governance is left for after launch

Government websites commonly contain large estates of duplicated, outdated or inaccessible content. Migration should include ownership, retention, rewriting and retirement decisions—not merely automated transfer.

The project confuses launch with completion

Monitoring, accessibility maintenance, security patching, platform upgrades, content review and improvement all continue. The delivery model and budget should make that operating reality explicit.

A practical definition of done

A government website redevelopment is not “done” because pages render correctly and stakeholders approve the appearance. It is ready when the agency can show a coherent evidence set: validated user needs, inclusive journeys, accessible components and content, secure and privacy-aware data flows, tested integrations, accountable publishing, reliable deployment, meaningful measures and an operating plan.

That definition creates a healthier procurement conversation. It allows suppliers to price the work that genuinely creates assurance and enables the agency to compare proposals on delivery substance rather than on the confidence of their promises.

Frequently asked questions

Does every Australian government website have to meet the same standards?

No. Requirements vary by jurisdiction, entity type, service, information classification and procurement context. Commonwealth policies may be mandatory for particular entities while state, territory and local government organisations can have their own standards. Confirm the applicable framework with the responsible governance, legal, privacy and security owners.

Is WCAG 2.2 AA enough to prove the whole service is accessible?

It is an important technical benchmark, but it does not replace research and testing of the complete service. Inclusion also involves language, connectivity, digital confidence, cognitive load, assisted pathways and the accessibility of connected documents and systems.

Can an automated accessibility scan prove compliance?

No. Automated testing identifies some repeatable issues but cannot assess every semantic, interaction, content or real-user problem. Use it with manual expert testing and representative user testing.

Should standards be written into acceptance criteria?

Yes, but broad statements are insufficient. Link requirements to specific evidence, tests, severity thresholds, remediation rules and an accountable acceptance owner.

When is paid Discovery necessary?

Discovery is particularly important when user groups, integrations, data, identity, security, content migration, governance or the operating model are unresolved. It converts ambiguity into a defensible scope and implementation pathway.

Does a penetration test prove a website is secure?

No single test proves ongoing security. Security also depends on architecture, configuration, access control, development practice, patching, monitoring, incident response and the hosting environment. Testing provides evidence at a point in time.

Who should own hosting compliance?

The client agency should retain clear accountability and normally contract directly with the selected hosting provider. The website delivery partner can define application requirements and coordinate implementation, but should not blur infrastructure ownership.

What happens after the standard 30-day functional warranty?

For a completed Emote website implementation, the standard 30-day functional warranty begins at production go-live unless a signed project-specific agreement says otherwise. It covers eligible implementation defects, not new features, content work, optimisation, platform maintenance, security operations or ongoing improvement. Those services require an appropriate support arrangement.

How Emote can help

A government website programme needs more than polished screens and a compliance appendix. It needs a delivery model that connects user evidence, policy requirements, technical decisions, testing and operational accountability. Emote can help organisations turn those obligations into a practical website programme spanning strategy, UX/UI, content structure, technology, integration planning and implementation.

Emote’s website design and development work brings those requirements into one practical delivery pathway.

Planning a government or public-sector website programme? Book a website planning conversation with Emote to discuss the brief and evidence already available.