Cognitive Accessibility & Plain Language

Most accessibility work has a clear pass or fail. A control either has an accessible name or it does not; contrast either meets 4.5:1 or it does not. Cognitive accessibility is harder, because the questions are ones a machine cannot answer: is this sentence clear? is this flow simple enough? will someone remember this on the next screen? That is why an automated scan can report zero issues on a page that is still, in practice, unusable for a large share of your audience.

The group it affects is broad. It includes people with learning disabilities such as dyslexia and dyscalculia, attention conditions such as ADHD, autism, memory impairments, aphasia and other language processing differences, acquired brain injury, and the cognitive changes of aging. Cognitive and learning disabilities are among the most common disabilities of all. And cognitive capacity is situational: the tired parent, the stressed traveler, the person reading in a second language, and the developer skimming your docs at midnight are all, in that moment, working with reduced attention and memory. Design that lowers cognitive load is the accessibility work with the widest reach.

There is also a reason it gets neglected: these users rarely complain. A blind user who hits an unlabeled button can name the problem. Someone who is confused by your checkout usually just assumes the fault is theirs, gives up, and leaves quietly. The failure looks like a bounce, not a bug report. So the work has to be proactive.

One assumption to drop: that because much of this is not testable, it is not required. The laws that govern the rest of your product reach it too, measured against WCAG Level AA, which now includes cognitive criteria. This guide is the build layer; for the letter of the standard, see the WCAG 2.2 Level AA requirements.

If you do only one thing for cognitive accessibility, write plainly. Plain language, now formalized in the international standard ISO 24495-1, means your intended reader can find what they need, understand it the first time, and act on it. It is not about lowering the intelligence of the content. The ideas stay as sophisticated as the subject requires; what changes is how you deliver them.

The core moves

• Lead with the point. Put the answer or the action first, then the detail. Do not make people read three paragraphs of background to reach what they came for.
• One idea per sentence. Long, multi-clause sentences are the single biggest driver of unreadable copy. Aim for around 15 to 20 words.
• Common words, active voice, second person. Say “you can cancel any time” rather than “cancellation may be effected by the subscriber at their discretion.”
• Define jargon, expand abbreviations, avoid idioms. Figurative language (“ballpark figure,” “low-hanging fruit”) is a barrier for many autistic readers and for anyone reading in a second language.
• Chunk it. Break content with meaningful headings, short paragraphs, and bullet lists so it can be scanned rather than read wall to wall.

Before and after

<!-- Before: 41 words, one sentence, passive, bureaucratic -->
<p>In the event that the aforementioned documentation is not
   submitted prior to the stipulated deadline, the processing
   of your application may be subject to delay or, in certain
   circumstances, cancellation without further notification.</p>

<!-- After: three short sentences, active, leads with the action -->
<p>Send us your documents before the deadline. If they arrive
   late, we may delay your application. If we cannot reach you,
   we may cancel it.</p>

Reading level, and what the score does not tell you

For a general audience, target a lower secondary reading level (roughly eighth to ninth grade), which is what 3.1.5 Reading Level points at. A Flesch Reading Ease score around 60 or higher is a handy proxy. But readability formulas only count sentence length and syllables; they cannot tell whether the meaning is clear, and you can hit a great score while saying nothing understandable. Use the score to catch long sentences and dense vocabulary, then rely on human review and testing for actual clarity. When a topic truly needs advanced reading ability, 3.1.5 asks for a simpler alternative (a summary, a glossary, an explainer), not a dumbed-down original. The accessible typography guide covers Flesch-Kincaid scoring and dyslexia-friendly type in depth.

COGA objective six is blunt: processes should not rely on memory. Short-term and working memory are exactly what many cognitive disabilities affect, so every time your interface asks someone to remember a code, a value, or a step, you add a point of failure. WCAG 2.2 turned two pieces of this into requirements.

Redundant Entry (3.3.7): stop asking twice

3.3.7 Redundant Entry requires that information the user already entered in the same process is either auto-populated or available to select, unless re-entering is essential (a password confirmation), the data is security-sensitive, or the earlier value is no longer valid. The classic case is a shipping and billing address:

<!-- Let people reuse what they already typed -->
<label>
  <input type="checkbox" name="same-as-shipping" checked>
  Billing address is the same as shipping
</label>

<!-- And help the browser fill known fields, cutting entry entirely -->
<input name="email" type="email" autocomplete="email">
<input name="address" autocomplete="street-address">

Accessible Authentication (3.3.8): logging in without a memory test

3.3.8 Accessible Authentication prohibits a cognitive function test (remembering a password, transcribing characters, solving a puzzle) as the only way to authenticate, unless you provide an alternative or a mechanism to help. In practice that means: allow paste and do not block password managers, keep autocomplete on so credentials can be filled, and prefer methods that lean on recognition or the device rather than recall, such as passkeys, an email link, or an OTP the user can paste.

<!-- Password managers can fill it; nothing blocks paste -->
<input type="password" name="password" autocomplete="current-password">

<!-- One-time code the user can paste, and the OS can offer to fill -->
<input type="text" inputmode="numeric" autocomplete="one-time-code"
       name="otp" aria-label="One-time code">

<!-- Do NOT do this: onpaste return false blocks the very users 3.3.8 protects -->

Puzzle and transcription CAPTCHAs are a direct violation when they are the only path through. The accessible form validation guide works through 3.3.7 and 3.3.8 alongside the rest of the WCAG 3.3 input-assistance cluster.

Show, do not make them recall

Beyond the two requirements, the general principle is to keep the information people need visible, not in their heads. Show a running summary in a multi-step checkout, keep the instructions on screen while the person acts on them rather than in a dismissed dialog, show a clear step 2 of 4 progress indicator, and confirm choices back to the user before they commit.

Attention is a finite resource, and for people with ADHD, autism, anxiety, or memory conditions it can be especially hard to protect. Interfaces that grab, move, and interrupt spend that resource for the user. The fix is restraint.

• No moving, blinking, or auto-advancing content. Carousels that rotate on their own, animated ads, and marquee text pull focus away from the task and can be impossible to read (2.2.2 Pause, Stop, Hide). If content moves, give a control to stop it, and honor prefers-reduced-motion.
• Do not interrupt. Pop-ups, surprise dialogs, and toasts that steal focus or cover the content derail whatever the person was doing. Let people finish, and let them dismiss anything that appears.
• One primary action per screen. Reduce the number of choices in view. A page that presents a dozen equally weighted buttons forces a decision cost on every one. Make the main path obvious and demote the rest.
• Be predictable. Nothing should change context just because a control received focus or a field changed value; a menu that navigates on focus, or a select that submits the page on change, is disorienting (3.2.1, 3.2.2).

/* Respect the OS "reduce motion" setting for anything that animates */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

This is the area where a green automated report means the least. A scanner cannot tell you whether your copy is clear or your flow is simple. Use a layered approach instead:

• Readability pass. Run your real copy through a Flesch-Kincaid or similar score to flag long sentences and dense vocabulary. Treat it as a smoke alarm, not proof of clarity.
• Plain-language edit and the explain-it-back test. Read a screen, look away, and try to say what it asked you to do. If you cannot, or you had to re-read, it is too complex.
• A cognitive walkthrough of key flows. Step through signup, checkout, and support looking specifically for memory demands, re-entered information, surprise timeouts, inconsistent components, jargon, and interrupting motion.
• Usability testing with real users. The single most valuable step is moderated sessions with people who have cognitive and learning disabilities. They surface confusion no guideline predicts, and it is where you learn what your product actually feels like to use.
• The COGA checklist. Work through the checklist that ships with the W3C Making Content Usable document, objective by objective.

Cognitive accessibility sits alongside the rest of your testing, not instead of it. Combine it with a screen reader pass and keyboard testing, and fold it into your overall accessibility audit.