TL;DR: The Australian Government’s Digital Experience Policy is now in force. New government websites launched from 1 January 2025 must meet three new standards (Digital Inclusion, Digital Access, Digital Performance) in addition to the updated Digital Service Standard (DSS), which fully rolled out in 2024–25. The effect: stronger expectations for WCAG 2.1/2.2 accessibility, plain-English content, and key content in multiple languages. Below we explain what this means and a practical roadmap to comply. 
Why accessibility and multilingual content are now front-of-mind
- There’s a whole-of-government direction now in play. The Digital Experience Policy mandates a unified approach to inclusive digital services, with three new standards applying to new sites from 1 January 2025 and complementing the DSS. Expect stronger oversight and clearer expectations about inclusive content and service quality. 
- The Digital Service Standard (DSS) was refreshed to “leave no one behind”, placing explicit emphasis on inclusion and accessibility across 10 criteria (e.g. Know your user, Leave no one behind, Do no harm, Monitor your service). This is now the baseline for all Commonwealth digital services. 
- The Disability Discrimination Act 1992 (DDA) underpins accessibility obligations. The Australian Human Rights Commission’s 2025 guidance points agencies to WCAG 2.2 (use at least AA) and recognises AS EN 301 549:2024 (ICT accessibility) in procurement and governance. States and territories also reference WCAG and AS EN 301 549 in their policies. 
- The Multicultural Access and Equity Policy and the Language Services Guidelines expect agencies to make information accessible to Australians from culturally and linguistically diverse (CALD) communities – practically, that means translating key content and offering interpreter pathways. 
What the Digital Service Standard expects (in plain terms)
The DSS sits inside the Digital Experience Policy alongside the Digital Inclusion, Digital Access and Digital Performance standards. Together they set the bar for inclusive design, findability, consolidation and ongoing quality.
The DSS (v2.0) requires teams to design and run services that people can actually use – safely and independently. For accessibility and inclusion, focus on:
- Understand users, barriers and contexts (research with people who use assistive tech, have low digital literacy, or limited English).
- Leave no one behind (plan for disability, language, culture and connectivity; provide alternate formats and translation as needed).
- Use plain English and meet WCAG (AA as a minimum; move towards WCAG 2.2).
- Continuously monitor and improve (don’t “ship and forget”; test with real users, fix issues quickly). 
Multilingual content: when and what to translate
Government websites should offer human-validated translations for high-value, high-risk, or frequently used content. Think eligibility pages, how-to steps, forms, deadlines, emergency and health information. Automated machine translation alone is not sufficient for critical content and can sometime make mistakes. Use accredited translators and follow the federal Language Services Guidelines. 
At a minimum, provide:
- Key tasks and summaries in the top community languages you serve, plus clear interpreter pathways on every page template
- Translated PDFs and forms where relevant (and accessible PDFs), or better – HTML pages with the same level of accessibility and search visibility 
- A visible language switcher, meta tags for language, and governance for keeping translations in sync with updates. 
A practical compliance roadmap (that holds up in audit)
1) Commit and scope
Assign an executive sponsor; confirm DSS/DXP applicability; set WCAG target (2.2 AA) and policy alignment (DDA, AS EN 301 549 for ICT, Style Manual for plain English). 
2) Baseline audit
Run an accessibility audit covering pages, templates, components, documents and media; include assistive tech testing. Prioritise issues by user impact and frequency. 
3) Content uplift (plain English first)
Rewrite complex pages to Style Manual guidance; add summaries, step-by-steps, alt text, captions and transcripts. You can use ICON’s free AusStyle Editor if you have access to ChatGPT. Or ask us how we can build a custom AI editor for your organisation.
4) Multilingual strategy
Identify key tasks and languages (usage, risk, audience). Commission NAATI-certified translation with bilingual QA; publish HTML counterparts and language toggles; add TIS National contact flows. 
5) Design-system fixes
Remediate colour contrast, focus states, keyboard order, error messaging, form labels, landmarks. Keep changes in a component library to scale. 
6) User research and inclusive testing
Test prototypes and live pages with people who use screen readers, magnification, voice control – and with CALD participants (moderated sessions in English and target languages).
7) Governance and measurement
Publish an Accessibility Statement (scope, standards, contact). Track ongoing performance (issues fixed, error rates, task success, language usage). Align to Digital Performance expectations. 
8) Train teams
Upskill authors, designers, developers and product owners on DSS criteria, WCAG 2.2, language services workflow, and the Style Manual. Refresh quarterly. 
9) Plan the next 12 months
Lock in accessibility sprints and content updates; schedule annual audits and CALD retesting; keep pace with evolving standards and DTA updates. 
What good looks like (quick checklist)
- Meets WCAG 2.2 AA across web pages, PDFs, apps and media
- Clear plain-English content aligned to the Style Manual 
- Key content translated and validated; visible language selector and interpreter info 
- Evidence of inclusive research and testing (disability and CALD users)
- Performance and accessibility metrics monitored and published
FAQs for government readers
Is WCAG 2.2 mandatory?
The DSS and Digital Inclusion Standard direct agencies to meet the latest WCAG and DDA obligations. In practice, treat WCAG 2.2 AA as your target for new work and plan uplift for existing sites. 
Do we have to translate everything?
No. Prioritise high-value/critical content and common tasks for translation, with human validation. Provide interpreter pathways and make sure translated pages are as accessible as English originals. 
How do state rules fit in?
States and territories align with WCAG and commonly reference AS EN 301 549 for ICT procurement (e.g. NSW). Agency-specific policies (e.g. Queensland) reiterate WCAG 2.1 AA as a baseline. 
How ICON can help
ICON pairs accessibility specialists, service designers, content strategists and accredited translators to deliver end-to-end DSS-aligned upgrades: audits, plain-English rewrite, translation workflows, design-system remediation, and inclusive testing. If you’d like a rapid compliance gap review and multilingual content plan, we can start with a short discovery project that will set you up for meeting the new compliance rules.