Cognitive accessibility: plain language and error recovery

Plain-language writing, consistent navigation and help placement, reducing memory and redundant entry, timeouts, and forgiving error recovery.

Plain language

• Keep sentences short and one idea each. Front-load the important word so a reader skimming with a screen reader at speed hears it first.
• Avoid metaphors, idioms and humour in instructions. They do not translate and they do not survive being read aloud.
• Expand an acronym on first use and use it consistently afterwards. Changing between forms makes a page harder to search.
• Write link text that makes sense read alone. "View the pricing page" survives being listed out of context; "click here" does not.
• Give the page one clear purpose. A page that answers three unrelated questions is harder to understand for everyone.

Consistency and memory load

1. Keep navigation in the same order and the same place on every page. A moving menu forces the user to re-scan every time.
2. Do not ask for the same information twice in one process. Carry it forward and let the user correct it.
3. Show the steps and the progress in a multi-step process, and let the user go back without losing what they entered.
4. Provide help in a consistent place. A help link that moves between pages is worse than no help link.
5. Offer autocomplete for anything the browser or the operating system can supply - names, addresses, email, card details.
6. State the format expected before the field, not in an error after they get it wrong.
7. Warn before a session expires, and let the user extend it. Never discard entered work silently.

<!-- an expected format, given up front -->
<div class="field">
  <label for="dob">Date of birth</label>
  <p id="dob-hint">For example, 24 March 1990</p>
  <input id="dob" name="dob" autocomplete="bday" aria-describedby="dob-hint" />
</div>

<!-- progress the user can see and understand -->
<nav aria-label="Checkout progress">
  <ol class="steps">
    <li aria-current="step">1. Your details</li>
    <li>2. Delivery</li>
    <li>3. Payment</li>
  </ol>
</nav>

<!-- a timeout warning that is announced and extendable -->
<div role="alertdialog" aria-labelledby="timeout-title">
  <h2 id="timeout-title">You will be signed out in 2 minutes</h2>
  <button type="button">Stay signed in</button>
</div>

Redundant entry and memory load are the criteria people most often skip, and they are among the cheapest to fix. Every field the system already knows is a field the user does not have to remember or re-type.

Forgiving error recovery

• Say what went wrong, where, and what to do next. Three parts, in that order.
• Never blame the user. "That date has already passed" is factual; "you entered an invalid date" is not useful.
• Keep the user's input on failure. Clearing it is the most damaging and most common mistake.
• Undo beats confirm. An undo option after an action is less disruptive than a modal before every action.
• Confirm destructive actions in plain words, naming the thing being destroyed.
• Avoid time-limited interactions unless there is a genuine reason, and always allow an extension.
• Offer a way out. A dead end with no alternative path is a barrier for everyone.

<!-- a confirmation that names the thing, and an undo afterwards -->
<dialog id="delete-project" aria-labelledby="del-title">
  <h2 id="del-title">Delete "Renewal pipeline"?</h2>
  <p>The project and its 42 tasks will be removed. You can restore it for 30 days.</p>
  <button type="button">Cancel</button>
  <button type="button">Delete project</button>
</dialog>

<div role="status" class="toast">
  Project deleted.
  <button type="button">Undo</button>
</div>

FAQ

Related

Motion, zoom, reflow and vestibular safety Forms, labels and accessible validation

Last refreshed 2026-09-18.