Writing microcopy for Australian government forms: labels, help text, errors

Guide
Written By Ellen Harvey

Most Australian government forms fail at the microcopy layer. The fields are arranged correctly. The submit button works. The form still fails because the labels copy the policy term, the help text was written by a lawyer worried about liability, and the error messages blame the user for mistakes the form invited.

This guide is for content designers and content officers writing or reviewing the microcopy on Australian government forms. Agency portals, application services, registration flows, feedback forms — anywhere a user has to read a label, a hint, or an error and decide what to type next.

Form completion is a content design problem, not a UI problem. A well-arranged form with the wrong words is still broken. The microcopy is where most forms quietly fail.

Before you start

You will need:

  • The user task the form supports, in the user's words

  • The current form copy, including labels, help text, and every error state

  • Access to the developer or service designer who can change microcopy in the build

  • The Australian Government Style Manual forms guidance and the relevant WCAG 2.2 success criteria for forms (3.3.1, 3.3.2, 3.3.3, 3.3.4)

If you do not have access to the error states, stop and get them. Most form failures live in the errors, and you cannot fix what you cannot see.

Step 1: Name the user task before you write a single label

The form is built around what the user is trying to do, not what the agency needs to record.

Before you touch the microcopy, write one sentence describing the user's task. "Renew a driver licence." "Apply for a concession card." "Report a pothole." If you cannot write that sentence, the form's purpose has not been agreed yet and the microcopy cannot be fixed in isolation.

The user task determines every label after it. The licence renewal user thinks in terms of "my licence." The concession card user thinks in terms of "do I qualify." The pothole user thinks "where it is and how bad."

Step 2: Write labels in the user's words, not the policy term

Labels carry the highest microcopy load on any form. Most agency forms get them wrong.

The most common failure: the label copies the field name from the legislation or the database schema. "Date of issuance of original document." "Primary nominee identifier." "Eligibility category code." Nobody phrases their question that way.

Replace every policy-term label with the word a user would say out loud. "When was this issued?" "Who is the main contact?" "Which group are you in?" The Style Manual's forms guidance calls this out directly. So does WCAG 2.2 3.3.2 Labels or Instructions — labels must help users understand what input is expected.

If the legal team objects to plain-language labels, the answer is not to bring back the policy term. The answer is to map the plain label to the policy term in the underlying record, where the lawyers need it, and let the user see the human version.

Step 3: Use help text only when the field is genuinely confusing

Help text is not a safety net for legal risk. It is information the user actively needs to answer the question.

The wrong use is a 90-word block under every field explaining the program, the eligibility rules, the relevant Act, and what the field means in policy terms. The user stops reading after the first line.

Use help text only when:

  • The field asks for something a user might not have on hand. ("Your customer reference number. You will find it on the top right of your renewal letter.")

  • The field has a non-obvious format. ("Use 11 digits, no spaces.")

  • The field has a genuine ambiguity. ("Date your business started trading, not the date you registered.")

If the help text exists to manage legal risk, move that text to the page-level information panel before the form starts, or to the confirmation screen after submission. It does not belong inside a field.

Step 4: Write three kinds of error message: format, missing, system

Error messages are the most-read microcopy on any form. They are also the most consistently bad.

Australian government form errors usually fall into three patterns. Each needs a different fix.

Format errors. The user typed something the field cannot accept. The error must say what the field expected and how to fix it. Not "Invalid input." Try: "Enter the date as DD/MM/YYYY, for example 14/06/1985."

Missing field errors. A required field is empty. Name the field and what to do. Not "This field is required." Try: "Add your contact email so we can confirm your application."

System errors. Something has failed on the agency's side. Be honest about whose problem it is. Not "An error has occurred." Try: "We could not save your form. Try again in a few minutes. If it keeps failing, call us on 13 XX XX."

Three rules apply across all three patterns. Be specific. Do not blame the user. Tell them what to do next.

Step 5: Map every error message to a WCAG 2.2 success criterion

Accessibility for forms is a content responsibility, not just a developer one.

Form errors sit at the centre of WCAG 2.2 compliance. Three success criteria apply directly:

A blameless, specific error message that suggests the fix passes all three. A vague "Invalid entry" passes none.

Step 6: Test the microcopy with real users, not just the team

Internal review of microcopy is not the same as user testing. Both miss different things.

Run the form past five users from the actual audience. Watch them fill it in. Note where they pause, where they re-read a label, where they hit an error, and what they say out loud.

You will discover three things internal review never catches:

  • Labels that mean something different to the user than to the team

  • Help text the user does not see because it sits below the field

  • Error messages that do not match what the user thinks they did wrong

If you cannot run formal user testing, ask three people in your call centre or front desk what users phone about. The repeated questions are your microcopy gaps.

Step 7: Document the microcopy patterns

The next form team should not solve labels and errors from scratch.

Once the patterns work, write them down. A short pattern library covering: how labels are phrased, when help text is used, the structure of each error type, and the tone for system errors. Pin it to your design system, your CMS template, or your governance framework. Wherever your team writes new forms is where the patterns belong.

When I led whole-of-government digital consolidation for the ACT Government, the patterns that survived the project were the ones documented in shared standards. The patterns that lived only in one team's head got rewritten by the next team and lost.

What good looks like

A form with finished microcopy has these properties:

  • Labels match the words a user would speak. No policy terms inside fields.

  • Help text appears only on fields where it is genuinely needed, and is one short line.

  • Error messages say what went wrong, what to do, and never blame the user.

  • Every error meets WCAG 2.2 3.3.1, 3.3.3, and where applicable 3.3.4.

  • The patterns are documented for the next team.

If a content officer can read your form and answer "what is this asking?" in their own words, the microcopy is doing its job. If they cannot, it is not, regardless of how clean the layout looks.

Photo by Hal Gatewood on Unsplash.

Ellen Harvey
Next

Content design vs UX writing vs content strategy: the disciplines, the overlaps, the differences