The Thinnest Rules in the Standard, and What to Do Anyway

Cognitive accessibility covers memory, attention, processing speed, literacy, comprehension and executive function. It takes in dyslexia, ADHD, autism, acquired brain injury, learning disabilities, mental health conditions, and the ordinary effects of stress, illness, medication and age.

It is the area WCAG serves least well, and that is not an accusation. Most of what helps resists being written as a testable rule, because you cannot write a success criterion for "this makes sense". So the checklist runs out long before the job does, and this page is about what to do in the space it leaves.

Why the Rules Are Thin, Counted Rather Than Asserted

You can measure the gap instead of arguing about it. Guideline 3.1 Readable holds six criteria and four of them are Level AAA. Language of Page sits at Level A and Language of Parts at AA, and both are about declaring a language rather than about anybody understanding anything. Guideline 3.3 Input Assistance holds nine, three of them AAA.

So the criteria aimed squarely at comprehension are mostly parked at the level nobody is obliged to meet:

• 3.1.5 Reading Level is AAA.
• 3.1.3 Unusual Words and 3.1.4 Abbreviations are AAA.
• 2.2.6 Timeouts, warning about data loss, is AAA.
• 3.3.5 Help is AAA.

One of those is milder than its name suggests, and it is worth knowing before somebody uses it to argue against writing anything technical. The reading level criterion does not ask you to rewrite a document. It asks for supplemental content, or a version at a lower reading level, to be available alongside the original. A technical page can conform with a plain-language summary sitting next to it.

WCAG 2.2 did improve things, and three of its additions were aimed straight here. 3.2.6 Consistent Help and 3.3.7 Redundant Entry are both Level A, and 3.3.8 Accessible Authentication is Level AA. That last one is the biggest single win this audience has had from the standard in years, and it gets its own section below.

What W3C Says When It Is not Writing Rules

There is a W3C document for exactly this problem, and almost nobody outside the field has read it. Making Content Usable for People with Cognitive and Learning Disabilities was published by the task force that works on this subject, and it is organised around eight objectives.

1. 1Help users understand what things are and how to use them.
2. 2Help users find what they need.
3. 3Use clear and understandable content.
4. 4Help users avoid mistakes and know how to correct them.
5. 5Help users focus.
6. 6Make sure processes do not rely on memory.
7. 7Provide help and support.
8. 8Support adaptation and personalisation.

Say the obvious thing about it first. That document is a note rather than a standard, so it creates no requirements and no auditor will ever cite it against you. Which is the point. The requirements are thin here, and the best available guidance is deliberately not a requirement, so the only way this work happens is because somebody decided to do it.

The task force writes its user needs in the first person, and they land harder than any paraphrase of ours would. People saying they need to use a site without remembering or transcribing passwords, codes and usernames. Saying they need time to finish, and do not want a session expiring while they hunt for a piece of information. Saying they cannot function at all when a screen carries too much. Read those and the patterns underneath them stop looking like design opinion.

Underneath the Eight Objectives Sit 58 Numbered Patterns

The objectives are the summary. The work is one level down, in 58 numbered design patterns filed beneath them. That layer is what turns the document from a statement of intent into something you can hand somebody on a Monday. Objective three, on clear and understandable content, holds 13 of the 58. Objective four, on helping people avoid mistakes and correct them, holds 12. That means more than two fifths of the whole document is about writing and about form errors, which happen to be the two cheapest things on any website to change.

Every pattern is built to the same shape. A user need, written in the first person. A section headed What to Do. A section headed How it Helps. And worked examples. So a content editor can be handed one pattern and act on it without reading the other 57. That is not true of most accessibility guidance, and it is the whole reason this document is worth knowing about.

Pattern 4.4.1, Use Clear Words, is the most concrete instruction in it. Use common and clear words in all content, and look at the most common 1,500 words or phrases, because those are the terms people with severe language impairments are most likely to know. Strip vague filler such as and so forth. Remove or explain uncommon acronyms, abbreviations and jargon. And do not invent new words, or give existing words new meanings inside your product, because nobody should have to learn vocabulary to use your checkout.

The reason W3C gives is the part that stays with you. Somebody with mild dementia is trying to turn on a heating and air conditioning unit. The control for choosing heat or cool is labelled mode. They cannot use the unit at all because of that one word, and the document records plainly that this kind of design has caused emergencies such as hypothermia. One label, one word nobody thought twice about, and a person sitting in a cold house.

That same pattern also says where to start, which most guidance never does. Headings, labels, navigation, instructions and error messages, in that order, on the grounds that fixing those raises usability without a large time commitment. On most sites that is about a day. The list below is our own shorter version of the same territory, built from what we actually find in audits.

The Thirteen Things That Help Most

None of these need technical work. Most are free, and twelve of the thirteen sit under one of those eight objectives, which is a better foundation than our say-so.

1. 1Write in plain language. Short sentences, common words, active voice, one idea per paragraph.
2. 2Put the answer first. Do not build towards a conclusion. Lead with it and explain afterwards, and somebody who only reads one line still leaves with the answer.
3. 3Keep navigation identical across pages. Same items, same order, every time, so nobody has to relearn your site on each page.
4. 4Break long forms into steps, with a visible indicator of where somebody is and how much is left.
5. 5Write error messages that say what to do, rather than what went wrong in the abstract.
6. 6Do not ask for the same information twice in one process, and do not rely on the browser's autofill to cover for you, because the rule asks the site to supply what it already has.
7. 7Remove time limits wherever you can, and warn well before the rest of them expire.
8. 8Let people paste, especially into password fields, and let password managers do their job.
9. 9Use icons alongside text, never instead of it.
10. 10Make important actions reversible, or confirm before they happen, so a misclick is not a disaster.
11. 11Keep help easy to find in a consistent place, so nobody has to hunt for it at the moment they are already stuck.
12. 12Reduce choice on any single screen. Twelve options is a decision. Four is a step. Those numbers are our rule of thumb rather than anybody's research, and the principle underneath them is W3C's.
13. 13Let people adapt what they see. Larger text, a simpler layout, their own symbols, their own colours. Personalisation is the eighth objective on that list and the one product teams skip.

One of those needs a caveat, because it sits next to a rule that says something narrower. Consistent Help is about keeping help mechanisms in the same relative order across a set of pages, not about pinning a help button to a fixed spot on the screen. Keeping it in the same place is good practice and it is ours, not the standard's.

The Login Problem

Authentication is where this group gets excluded most reliably, and WCAG 2.2 finally named it. 3.3.8 bars a cognitive function test at any step of signing in, and it names four ways out rather than one. Another route that skips the test. A mechanism that helps somebody through it. A test that only asks them to recognise objects. Or a test that only asks them to identify content they supplied themselves.

Those last two settle the CAPTCHA question, and they settle it in a direction that surprises people. An image challenge asking you to pick out the buses is object recognition, so it passes at Level AA. It only fails at AAA. A distorted-text or logic puzzle with no alternative fails at AA, because neither of those is recognising an object.

The mechanism route is why an ordinary password field still passes. The password manager is the mechanism. That has a condition attached that most teams never think about, because a password manager can only fill a field it understands. Correct autocomplete attributes on your form, and no JavaScript fighting the fill, are what keep that route open. Break either and you have removed the thing the rule was relying on.

So what actually fails is blocking paste, blocking password managers, a puzzle CAPTCHA with no alternative, and asking somebody to carry a code from one screen to another out of their head.

Worth knowing what is not a cognitive function test, because it is the first thing anybody asks. Name, email address and phone number are carved out by name. They are personal to the user and consistent everywhere, so asking for them is not a memory test however long the form is.

Blocking paste is the one we still find most. It gets added deliberately, for security reasons that do not survive examination, and the national security bodies W3C cites take the same view. It forces people to retype long strings from memory, which is precisely the test the rule prohibits.

Plain Language Is Not Dumbing Down

The objection is common and the premise is wrong. Plain language is about being understood the first time, not about removing substance. Nothing on this page asks you to take the detail out. It asks you to stop making the reader work to reach it.

And it serves everybody else at the same time. Non-native speakers. People reading on a phone. People in a hurry, people under stress, people who are ill, and people who are simply tired at four in the afternoon. That is most of your visitors on most days, which is why this is the rare accessibility change nobody argues with once it ships.