Start with the task, not the reading level
Imagine a resident using a city website to request a repair to a broken streetlight. They need to find the right form, describe the location, and know whether the request went through. At every step, the words on the screen can either reduce uncertainty or add to it. A button marked “Submit” may be familiar, but “Send repair request” tells the resident what will happen.
Cognitive disabilities can affect memory, attention, language processing, or planning in different ways. People also bring different experiences, preferences, and levels of familiarity with a service. Plain-language writing should not assume that everyone needs the same amount of detail. Its goal is to make essential information easy to find and understand while leaving room for people who want more explanation.
Begin by identifying what someone needs to decide or do on each screen. Put that information first. Use common words, short sentences, and specific actions. Keep necessary terms, such as the name of a document someone must provide, but explain unfamiliar terms where they appear rather than sending the reader elsewhere to decode them.
Make choices and next steps explicit
A useful label describes the result of an action. “Save draft” and “Send request” distinguish between two choices that may look similar but have different consequences. Link text such as “See accepted documents” is more informative than “Learn more,” especially when several links appear together. Headings should name the subject of a section so people can scan for what they need or return to it later.
Instructions work best when they appear close to the action they describe. Before an upload field, say which file is needed and which formats are accepted, if those limits apply. If a form has multiple steps, name the steps and show where the person is in the process. Avoid making someone remember a rule from an earlier page. When a task takes time, explain whether progress can be saved and what happens if the person leaves.
Consistency matters as much as simplicity. If one page calls an item a “request,” do not rename it an “application” on the next page unless there is a meaningful difference. Use the same words for the same actions throughout the service. Predictable wording helps people build confidence as they move between screens.
Write errors that help people recover
An error message should answer three questions: What went wrong? Where is the problem? What can I do now? “Enter a street name” beside an empty street-name field is more useful than “Invalid input” at the top of a form. If a date must use a particular format, show an example near the field before submission and repeat it in the error message when needed.
Avoid blaming language such as “You failed to complete this form.” The interface may have given unclear instructions, and the person still needs a way forward. Use calm, direct wording: “The photo did not upload. Choose the file and try again.” If previously entered information remains saved after an error, say so when that reassurance is relevant.
Confirmation messages deserve the same care. After the streetlight request is sent, a clear page can say “Your repair request has been sent,” show a reference number if one exists, and explain what the resident can do next. Do not promise a response time unless the service can support that promise.
Support the words with a predictable interface
Writing cannot fix every barrier on its own. Clear instructions are harder to use when a page moves unexpectedly, a pop-up interrupts the task, or a button changes its label without explanation. Writers and designers can work together to keep related information together, make the main action easy to identify, and avoid presenting too many competing choices at once.
Offer helpful detail without burying the main task. For example, a short instruction might say “Enter the nearest street address.” A nearby explanation can then describe what to do if the streetlight has no address. This approach keeps the primary path easy to follow while making an alternative available when it is needed.
Do not rely on icons, color, or images alone to convey instructions. A symbol may be unfamiliar or open to several interpretations. Pair it with a clear label, and make sure the wording still makes sense when read out of its visual context.
Check whether the writing works in real tasks
A writer can review a screen for long sentences and jargon, but a task walkthrough can reveal different problems. Ask someone to use the interface to complete a realistic goal, such as reporting the streetlight. Notice where they hesitate, reread, or choose an unexpected path. Ask what they expected a button or message to mean rather than asking only whether the words seemed clear.
Include people with cognitive disabilities in testing when possible, and make participation accessible: explain the activity in advance, allow breaks, and avoid treating one person’s experience as representative of everyone’s. Feedback may point to a wording change, a design change, or both. If testing is not available, a team can still check whether each screen states its purpose, uses consistent terms, explains consequences, and offers a route back from mistakes.
Plain language is not a one-time simplification pass. As a service changes, labels and instructions can drift away from what the interface actually does. Reviewing the complete task regularly helps keep the words accurate, respectful, and useful.
