Inclusive language

The core principle

Write for the widest realistic audience. Every word choice that unnecessarily narrows that audience is a participation barrier — even if unintentional.

This doesn’t mean writing in a way that is vague or over-hedged. It means writing precisely, without embedding assumptions about who the reader is, what they look like, how they live, or what they know.

People-first and identity-first language

People-first language puts the person before the attribute: “person with a disability” rather than “disabled person”. It’s the widely recommended default in professional contexts and is required in many government style guides.

Identity-first language inverts this: “disabled person”, “autistic person”. Some communities actively prefer identity-first language because they view their identity as integral, not incidental. Neither form is universally correct.

The practical guidance:

• In UI copy that applies broadly to all users, default to people-first: “people with accessibility needs”, “participants with disabilities”
• In copy that is addressed directly to a specific community or audience who have indicated their preference, follow their lead
• If you’re writing survey questions or consultation prompts about disability or accessibility, use open-ended framing that doesn’t impose a label: “Do you have any accessibility requirements we should know about?”
• Never write “suffers from” or “afflicted by” — these frame disability as inherently negative

Avoiding assumptions

Gender

• Use “they/them” as the singular pronoun when referring to a generic person, an unnamed participant, or anyone whose pronouns you don’t know
• Don’t default to “he” or use “he or she” — both are exclusionary
• In product copy, address users directly as “you” wherever possible — it sidesteps the pronoun question entirely and is warmer
• When offering gender options in forms, include options beyond “Male” and “Female”: at minimum, add “Non-binary”, “Prefer not to say”, and “Prefer to self-describe” with a text input

Family structure

• Don’t write “husband/wife” — write “partner” or “spouse”
• Don’t assume users have children: “Do you have children under 18?” not “How many children do you have?”
• Don’t assume a traditional household structure in questions about housing, property, or community connection

Cultural context

• Avoid culturally specific references that not all users will share: idioms, sporting metaphors, historical references tied to one country
• Don’t assume a shared cultural calendar: “the holiday season” is not universal
• For Australian government contexts: acknowledge that consultations may reach Aboriginal and Torres Strait Islander people and communities — write with that audience explicitly in mind, not as an afterthought

Technology literacy

• Don’t assume users know what a “consultation”, “submission”, or “engagement platform” is — especially in public-facing Social Point copy. Use plain alternatives where possible (see below)
• Don’t assume users have broadband, a desktop computer, or a printer
• Instruction copy should describe actions by what they do, not by where they are: “Select your answer” not “Click the radio button”

Community and participation language

Many terms common in government engagement work are jargon to the general public. In Social Point community-facing copy, prefer plain alternatives. In Open Point (professional, stakeholder-facing), the standard terms are appropriate.

Terminology reference

This table covers common terminology decisions. It is not exhaustive — when you encounter a term not listed here, apply the core principle: write for the widest realistic audience without embedding assumptions.

Writing about sensitive topics

Open Point consultations often cover topics with direct, significant impacts on people’s lives: infrastructure changes that affect neighbourhoods, environmental decisions, housing policy, road projects. These require particular care.

• Acknowledge the impact directly. Don’t write as though a proposal is neutral when it clearly affects people’s homes, environment, or livelihoods. “This proposal will change the character of the area” is more honest than “This proposal may involve some changes”.
• Don’t minimise concerns. Consultation copy that downplays opposition or frames all feedback as welcome while structurally discouraging negative responses erodes trust. Write copy that genuinely invites all views.
• Avoid language that presupposes outcomes. “Tell us how you’d like to see the new park developed” presupposes approval. If the project is still in planning, write: “Tell us what matters most to you about this area.”
• Be specific about what the consultation can affect. If a decision has already been made and the consultation is about implementation detail, say so. People who discover they were consulted on something already decided feel deceived.

When you don’t know who you’re writing for

In community-facing contexts, you often won’t know the exact audience. Write for the broadest realistic range of people who might engage with this consultation:

• Assume a mix of ages, literacy levels, cultural backgrounds, and technology access
• Write at a reading level accessible to most adults — see the Writing for accessibility page for specific guidance
• Don’t write only for people who are already informed about the project — include enough context that someone encountering it for the first time can participate meaningfully
• Use plain language by default, even if you know some users will be specialists — specialists can read plain language; non-specialists cannot read jargon
• If you know specific groups are particularly affected or likely to participate, add tailored guidance or terminology — but don’t make those groups the only audience your copy speaks to