Writing Plain-Language Web Content for Government and Nonprofit Sites

Plain language is the cheapest improvement available to a public-sector website and the one most often skipped, because it is the only part of a redesign that cannot be delivered by a vendor alone. Somebody who understands the programme has to decide what it actually says.

It is also frequently an expectation rather than a preference — federal public-facing content carries a statutory expectation of clear writing, and many states and agencies have adopted equivalent policies. But the practical case stands on its own: a resident who cannot understand the page calls you instead.

Why government writing goes wrong

Nobody sets out to write badly. Public-sector prose is the product of specific pressures: it is drafted by the person who knows the regulation, reviewed by legal for accuracy, and edited by a committee that adds caveats. Every step makes the text more defensible and less usable.

The result is content that is correct and unreadable — accurate to the statute and useless to the person trying to find out whether they qualify. Plain language is not dumbing down; it is doing the translation work that would otherwise be pushed onto the resident.

Lead with what the reader needs

The most common structural failure is answer-last writing: three paragraphs of programme history and authorising legislation before the sentence saying who is eligible.

Invert it. Start with the answer, then the detail, then the background if anyone needs it. "You can apply online if you rent in the city and your household earns under $X. It takes about ten minutes." Everything else follows.

This helps three audiences at once: residents scanning on a phone, screen-reader users navigating by heading, and the AI assistants that increasingly answer on your behalf — see GEO for government websites.

Address the reader directly

Use "you" for the resident and "we" for the organization. Passive constructions and third-person abstractions ("applications may be submitted by eligible parties") hide who does what.

Compare: "Applications will be reviewed within 30 days of receipt" against "We will review your application within 30 days." The second is shorter, clearer, and makes an accountable commitment — which is usually why the first was written.

Replace the jargon that carries no meaning

Some terms are legally load-bearing and must stay. Most are not. "Utilise" is "use." "Prior to" is "before." "In the event that" is "if." "Commence" is "start."

Where a technical term must remain, define it on first use in the same sentence rather than in a glossary the reader will not visit. Watch for internal vocabulary especially — department names, form numbers and programme acronyms mean nothing to a resident. Somebody looking for help with a heating bill is not searching for the name of the ordinance that created the programme.

Break the page up so it can be scanned

Nobody reads a government page start to finish. They scan for the part that applies to them.

Short paragraphs, one idea each. Descriptive headings that answer questions — "Who can apply" rather than "Eligibility." Real lists for steps and requirements, marked up as lists so assistive technology announces them properly. Tables only for genuinely tabular data, never for layout.

Write link text that means something

"Click here," "read more" and "learn more" tell a scanning reader nothing, and a screen-reader user pulling up a list of links on the page gets a list of identical entries.

Make the link text describe the destination: "download the application form," "check your eligibility." This is an accessibility requirement as well as a usability one — it appears in our WCAG 2.2 AA checklist.

Get the numbers, dates and money right for a reader

Write dates in full — "April 24, 2026" rather than a format that means different things in different countries. State whether a deadline is the postmark date or the received date, because that ambiguity generates real failures. Give money as figures. Say what happens if someone misses the deadline, which is the question they actually have.

Test it on someone who does not work there

The only real test of plain language is comprehension by someone outside the organization. Give the page to a colleague from an unrelated department, or better, a resident, and ask three questions: what is this about, does it apply to you, and what would you do next?

Whatever they cannot answer is the part to rewrite. Reading-level tools are a rough guide but they cannot tell you that the page never actually explains where to send the form.

Make it stick after launch

A plain-language pass at launch decays as new content arrives from departments that were not part of it. Editor guidance, a short style reference, and the standards built into your component templates are what hold the line — the same governance problem covered in content governance when a hundred people can publish.

Prioritise ruthlessly. You will not rewrite everything. Rewrite the pages that carry the facts people act on — eligibility, applications, deadlines, fees, emergency information — and let the archive be what it is.

One more benefit worth naming

Plain-language English is cheaper and more accurate to translate, because shorter sentences with common words survive translation far better than statutory prose. If language access is on your roadmap, doing the plain-language pass first reduces the translation bill and improves the output — the argument made in multilingual requirements for public-sector websites.

We treat this as part of the build rather than a content afterthought on government and municipal projects, including California city and county sites where language access sits alongside the accessibility obligation.