Writing for accessibility

Plain language as a requirement

WCAG 2.1 Success Criterion 3.1.5 calls for reading levels that don’t require more than a lower secondary education. Beyond WCAG, plain language is a legal requirement in many of the government contexts Open Point operates in.

The practical test: if a person with average literacy, reading your copy for the first time, can understand what they need to do and why — the copy is accessible. If they’d need to re-read it, look something up, or ask someone — it needs work.

Target reading levels

• Open Point (professional interfaces): Year 10 / US Grade 8 / CEFR B1 — clear prose at professional standard, but no unexplained jargon
• Social Point (community-facing copy): Year 8 / US Grade 6 — short sentences, concrete language, no assumption of prior knowledge about the project or process
• Error messages across both products: As plain as possible — this is not the place to demonstrate technical accuracy

Sentence structure

• One idea per sentence. If a sentence contains “and”, “but”, or “which” midway through, consider splitting it.
• Active voice by default. “We couldn’t process your file” not “Your file could not be processed.” Active voice names who is doing what, which is almost always clearer.
• Front-load the key information. Put the most important thing first. Don’t warm up to the point.
• Short sentences, especially in instructions. A sentence over 25 words is usually doing too much. Instructions should be 10–15 words where possible.

Multilingual and international audiences

Open Point is used globally. A significant proportion of participants in any community consultation may be reading in English as a second or third language. Write for them by default — it costs nothing and it helps everyone.

• No idioms. “Take the plunge”, “get the ball rolling”, “touch base” — these are meaningless without cultural context and often translate poorly.
• No culturally specific references. Sporting metaphors, political events, media references, and historical examples that only make sense to one nationality are exclusionary.
• Write literally. Say exactly what you mean. “Select the blue button at the top of the form” is better than “Hit the button up top”.
• Avoid contractions in high-stakes instructions where clarity is paramount — “You will receive a confirmation email” is unambiguous in translation; “You’ll get a confirmation” is less so.
• Avoid double negatives. “Not uncommon” means “common” — say “common”. “Don’t not submit” — just say “Submit”.

Writing for screen readers

Screen reader users navigate differently. They may jump between headings, scan only links, or tab through interactive elements. Copy that only makes sense in visual context fails them.

Link text

Link text must describe the destination or action — on its own, out of context. Screen reader users often pull up a list of all links on a page; “click here” and “read more” are useless in that list.

Button labels

Avoid generic verbs like “Submit” on their own. They tell the user what to do mechanically, but not what will happen. Pair the verb with its object.

Alt text

Alt text describes what an image conveys — not what it looks like. For functional images (icons with meaning, charts, diagrams), the alt text must capture the meaning. For decorative images, use an empty alt attribute (alt="") so screen readers skip it.

For complex charts and visualisations: alt text alone is rarely sufficient. Provide a data table or text summary adjacent to the image. See the Data visualisation accessibility page for full guidance.

Programmatic error association

Error messages must be associated with their field in the DOM — not just visually adjacent to it. Use aria-describedby on the input to reference the error element’s ID. A screen reader user who tabs to a field with an error should hear both the field label and the error message, in that order.

Visually moving focus to the first error on submit is also required — don’t just add red outlines; move the user to the problem.

Error messages — plain language in practice

Error messages are the point at which users most need clarity and least receive it. Technical error copy is one of the most common accessibility failures in software.

What a good error message contains

• What went wrong — specific enough to distinguish it from other errors
• Why it went wrong — when this helps the user fix it (not always needed)
• What to do next — a clear, actionable step

Not every error needs all three elements. “File too large. Maximum size is 10 MB.” is complete without a “why”.

Cognitive accessibility

Cognitive accessibility covers a wide range: learning disabilities, ADHD, anxiety, acquired brain injuries, dementia, situational impairments (tired, stressed, distracted). Writing for cognitive accessibility is largely the same as writing well — but a few specific rules help.

Consistent terminology

Use the same word for the same thing throughout. If a feature is called “consultation” in one place and “project” in another, users have to figure out whether these are the same thing. They shouldn’t have to.

No unexplained abbreviations

Spell out abbreviations on first use in any body copy or instruction. In UI labels where space is tight, only use abbreviations that are universally understood in context (PDF, URL, ID). “CALD”, “SES”, “ATSI”, “LEP” — these require explanation outside of specialist contexts.

Don’t rely on colour alone in copy

This applies to written copy that references visual states: “required fields are shown in red” is insufficient. Say “required fields are marked with an asterisk (*)” and ensure the asterisk is present. Never describe an action or error using only colour as the indicator.

Instructions: one thing at a time

Multi-step instructions should be numbered, not listed as a paragraph. Users with working memory difficulties benefit from numbered steps they can follow sequentially and check off. “Select a closing date, then add a description, then invite stakeholders” is a lot to hold in memory — turn it into three numbered steps.