How to write for the web for Australian government: a practical guide for content team

Most writing guidance for government websites focuses on what not to do: avoid jargon, do not use passive voice, check your reading level. That guidance is correct, but it starts too late.

The writing problems on most government websites are decisions that were never made. Nobody agreed on the user task the page was meant to support. The title describes the program, not what someone can do. The opening paragraph establishes context that only the content owner needed. The writing is fine. The design is wrong.

This guide gives content teams the sequence that makes writing for the web for Australian government work, starting before anyone opens a document.

Before you start: what you need

Who you need: a content designer or writer, plus someone who understands the policy or service well enough to brief them accurately. Trying to write without a proper brief is the most common source of rework.

What you need access to: any available analytics (page views, search queries, exit rates), any existing research or feedback about the topic, and the policy or program guidance the content needs to reflect.

What good looks like once you are done: a page that completes the user's task, passes a plain language check, meets WCAG 2.1 AA accessibility requirements, and has a review date set.

Step 1: Define the user task

Before writing a word, answer this question: what task does the user need to complete on this page?

Not the subject of the page. Not the name of the program. The actual thing someone is trying to do.

Bad: "This page is about the Community Services Access Program."

Better: "Someone wants to know if they are eligible, and what they need to do to apply."

In my experience working across ACT Government directorates, this is where most pages go wrong. The page exists to publish information, not to support a task. Users can tell the difference immediately. They scan, do not find what they need, and call instead.

The user task determines everything that follows: the title, the opening paragraph, the structure, the call to action, and the decision about what to leave out.

If you cannot name the user task in one sentence, the page is not ready to write.

Step 2: Write the title as a task, not a topic

Most government page titles are topic labels: "Eligibility criteria," "Program overview," "Resources," "Our team."

Topic labels make sense to the people who built the site. They make less sense to users who search in questions and tasks.

Write the title as the thing the user is trying to do or understand:

• "Who can apply for community housing assistance" not "Eligibility: community housing assistance"

• "How to renew your vehicle registration" not "Vehicle registration renewal"

• "Understanding the NDIS planning process" not "NDIS information"

The Australian Government Style Manual is clear that headings should be active and describe the content that follows. Task-framed titles do this by design.

Step 3: Lead with what matters

The first sentence on any government web page should answer the user's most pressing question, not establish context.

Most first paragraphs introduce the policy, explain the history of the program, or describe what the page contains. Users do not read this. They are already scanning for the thing they need.

Start with the answer, the action, or the key fact:

• "You need to apply at least 10 business days before your current licence expires."

• "If you earn under $80,000 a year, you may be eligible for this rebate."

• "This service is for people who live in the ACT and are experiencing financial hardship."

The opening sentence should hold up even if the user reads nothing else.

Step 4: Structure for skim-reading

Most users do not read government web content from top to bottom. They scan for the answer to their specific question.

Structure your content to support this:

• Use meaningful H2 and H3 headings that work as signposts, not decorative labels. "What you need to bring" is a signpost. "Information" is not.

• Keep paragraphs short: three sentences maximum, one idea per paragraph.

• Use bullet points for lists of three or more items, especially eligibility criteria, required documents, or steps.

• Put the most important information first in every section. Do not build to a reveal.

• Use bold text to highlight key facts such as dates, dollar amounts, and deadlines, not for decoration.

If a user can skim the headings and understand the structure of the page, the structure is working.

Step 5: Apply plain language and test it

Plain language is a legal requirement for Australian government web content, not a style option. Under the Disability Discrimination Act 1992 and WCAG 2.1 Success Criterion 3.1.5, content must be accessible to users with cognitive and reading disabilities.

What plain language looks like in practice:

• Short sentences (average under 20 words)

• Active voice (the subject does the thing)

• Common words over technical language; explain the technical term if you need to use it

• No jargon without definition

• Reading level around Year 7 to Year 9 (you can test this in Word or with Hemingway Editor)

The test that actually matters: give the draft to someone outside your team and ask them what they would do next. Not "do you understand this?" The right question is: "What would you do next?" Understanding and acting are different things.

Step 6: Check accessibility before publishing

WCAG 2.1 AA is the minimum standard for Australian government websites. Most accessibility reviews focus on code and images, but content has its own checklist:

• Alt text for all images that carry meaning (not decorative)

• Link text that makes sense out of context ("Find out how to apply" not "Click here")

• Heading hierarchy that follows logical structure (H1 to H2 to H3, no skipping)

• Tables only for data, not for layout; each table has a caption and column headers

• Acronyms defined on first use

• Reading level tested

The WCAG Quick Reference is the authoritative source. The DTA's content guide also covers accessibility for government content teams.

Step 7: Set a review date

Every page should have a review date before it publishes.

Outdated content is one of the most consistent problems on government websites. Policy changes, programs end, contact details change, and the web team often finds out only after users have been given wrong information.

Set a review date based on how likely the content is to change:

• High-change content (eligibility criteria, fees, contacts): 6 months

• Stable policy content: 12 months

• Evergreen guidance: 24 months

The review date belongs in whatever CMS or content management workflow your team uses. If you publish without one, the content becomes invisible to your governance process.

What good looks like once you are done

A page that has been through this process:

• Has a title that matches how users search for the task

• Opens with the answer, not the context

• Can be understood by someone with a Year 9 reading level

• Passes a WCAG 2.1 AA content check

• Has a review date

That is not a high bar. Most government web content does not clear it. The gap is not usually poor writing. It is the absence of a structured process that connects the user task to the published page.

When I led the digital consolidation across ACT Government, cutting from 60 websites down to act.gov.au, the pages that survived were the ones that could answer: what is the user task, and does this page complete it? Average call centre time dropped from 7 to 4 minutes after we applied this thinking across the content. The writing was not the variable. The decisions were.

Does your team have a process that runs every piece of content through these steps before it publishes? If not, the checklist is a start. The longer-term solution is a governance decision about who owns that process and when it runs.

Photo by Aliona Zahrai on Unsplash