In short and in plain language
Some people find it hard to read, to remember things or to work with numbers. This is called a cognitive disability. For them, a website is often hard to use.
There are rules for good websites. They are called WCAG. But these rules only help in part when someone has trouble remembering or understanding.
So there is extra help. It comes from the group that also writes WCAG. The help has eight goals. One goal is: you should not have to remember anything.
A form should have only one topic per step. You should not have to type the same thing twice. Help should be in the same place on every page.
Also test a website with people who have such problems themselves. A test tool alone is not enough.
An order form can meet every WCAG 2.2 Level AA success criterion and still fail: because of many fields on a single page, jargon in hints and error messages, or shipping costs that only appear in the last step. For exactly these barriers the W3C published the note “Making Content Usable for People with Cognitive and Learning Disabilities”, dated 29 April 2021 (W3C, Making Content Usable). It describes eight objectives and the design patterns that go with them for people with cognitive and learning disabilities. Following the patterns is explicitly not required for WCAG conformance (W3C, Making Content Usable); they address barriers that were not included in the normative WCAG 2.x and may not otherwise be addressed (W3C, Making Content Usable). This article puts the eight objectives next to the audit as a review grid, shows what WCAG 2.2 already covers and explains where the success criteria stop.
Key takeaways
- The W3C note “Making Content Usable” of 29 April 2021 sets out eight objectives with design patterns for people with cognitive disabilities; they are not required for WCAG conformance (W3C, Making Content Usable).
- Just over 7.8 million people in Germany have a severe disability; for 16 percent the most severe one is intellectual or mental, for 9 percent a cerebral disorder (Destatis).
- WCAG 2.2 adds three Level A and AA criteria for memory and help: help in the same place (3.2.6), no repeated entry (3.3.7), login without a memory test (3.3.8) (W3C, WCAG 2.2).
- Clear language, one topic per step, costs up front and human help are not required at Level AA; reading level and context-sensitive help exist only at AAA (W3C, WCAG 2.2).
- Rebuild forms along the grid: step indicator, five or fewer main choices per screen, carried-over entries, saving instead of time pressure (W3C, Making Content Usable).
- Testing means a WCAG audit plus sessions with affected users: the note advises involving people with cognitive disabilities throughout design and development (W3C, Making Content Usable).
What cognitive accessibility covers
Cognitive accessibility serves people whose difficulties lie in thinking, learning, remembering or understanding rather than in seeing, hearing or moving. The W3C note includes cognitive disabilities, learning disabilities, neurodiversity, intellectual disabilities and specific learning disabilities (W3C, Making Content Usable). It covers long-term, short-term and permanent difficulties, for example with reading, writing or math, with processing new or complex information, and with memory and attention (W3C, Making Content Usable). In everyday terms this means people with dyslexia, dyscalculia or ADHD, autistic people, people living with dementia, people recovering from a stroke and people with Down syndrome.
How many people are affected can only be measured in parts. At the end of 2025, just over 7.8 million (Destatis) people with a severe disability lived in Germany. For 16 percent (Destatis) of them the most severe disability was intellectual or mental, for another 9 percent (Destatis) a cerebral disorder. The statistic only counts people who have been assessed with a degree of disability of at least 50 (Destatis) and lists only their most severe disability. People with dyslexia or ADHD usually do not appear in it. The note itself points out that people with cognitive disabilities are less likely to have a formal diagnosis than people with physical or sensory impairments (W3C, Making Content Usable).
Other groups appear in that statistic only partly or not at all. At the end of 2025 an estimated 1.8 million (Deutsche Alzheimer Gesellschaft) people in Germany were living with dementia, that is, with a decline and loss of cognitive abilities (Deutsche Alzheimer Gesellschaft). Around 6.2 million (LEO 2018) German-speaking adults aged 18 to 64 read and write at a low level. Low literacy is not a disability, but it calls for the same patterns: clear words, short sentences, few distractions. How to write understandable copy is covered in the article on plain language on the web.
The note is specific about what slows these groups down online. People with impaired short-term memory may be unable to recall passwords or copy access codes (W3C, Making Content Usable). People with impaired working memory may only be able to hold one to three items (W3C, Making Content Usable) in mind at the same time. People who struggle to keep or regain focus may fail at simple tasks when there are many distractions and interruptions (W3C, Making Content Usable). The long, multi-step flows where online shops and service providers do their business sit exactly there: sign-up, login, checkout, customer account, cancellation.
The W3C note Making Content Usable at a glance
The note was published by the Cognitive and Learning Disabilities Accessibility Task Force (COGA) of the Accessible Platform Architectures Working Group and the Accessibility Guidelines Working Group; the latter is also responsible for WCAG (W3C, Making Content Usable). The status is deliberate: it is a Working Group Note, and the groups involved do not expect it to become a W3C Recommendation (W3C, Making Content Usable). It is therefore not a standard with conformance levels but a guide for everyone who designs, builds and edits websites and applications.
It is organized in several parts. User stories describe from the users’ perspective what they need. The design guide assigns patterns to each objective, each with a user need, instructions, a rationale and examples of what to use and what to avoid. A separate section deals with usability testing, focus groups and informed consent. Ten personas (W3C, Making Content Usable) make the needs tangible, from Alison, an aging user with mild cognitive impairment, through Jonathan with dyscalculia and Tal with dyslexia to Yuki with ADHD.
The way the note positions itself matters. Its objectives and patterns are supplemental guidance beyond the WCAG requirements, and following them is not required for WCAG conformance (W3C, Making Content Usable). They may improve usability for everyone, but for some people with cognitive disabilities they are essential to use content independently (W3C, Making Content Usable). WCAG 2.2 also points to the note in its introduction and encourages authors to consider it (W3C, WCAG 2.2).
The eight objectives as a review grid
The note is structured around eight high-level objectives (W3C, Making Content Usable). Each objective can be turned into a question about a page or a flow. That makes them useful as a grid that sits next to a WCAG audit rather than replacing it. The overview summarizes the patterns per objective:
Objective 1: Understand
Clear page purpose, familiar design, every step recognizable, unambiguous controls, icons that actually help.
Objective 2: Find
Most important tasks visible, understandable structure, media in chunks, a search that forgives typos.
Objective 3: Clear content
Common words, simple tense and voice, literal language, succinct text and summaries of long documents.
Objective 4: Avoid mistakes
Nothing moves unexpectedly, going back works, costs come first, inputs accepted in several formats.
Objective 5: Keep focus
Limit interruptions, short paths, not too much content, and say up front what the task will need.
Objective 6: No memory load
Login without memorizing, simple login, voice menus that can be skipped, no calculating or memorizing across steps.
Objective 7: Help
Human help, alternatives for complex content, explain the effects of choices, help easy to find.
Objective 8: Adapt
Moving content under user control, extensions allowed, a simplified view, a familiar interface.
In an audit, the objectives can be combined with the test questions in section 5 of the note, which phrase one question for each objective of the design guide (W3C, Making Content Usable): Does the user understand what things are and how to use them? Can they find what they need? Can they avoid mistakes and correct them easily? Can they complete the process without relying on memory? The questions sound general but become concrete as soon as you ask them about a single flow, such as signing up for a customer account.
The patterns themselves are usually specific enough to test. The note suggests using each pattern’s “use” and “avoid” examples as test cases (W3C, Making Content Usable). Some patterns give reference values. To keep an interface simple, offer five or fewer (W3C, Making Content Usable) main choices per screen and remove unnecessary content. For clear words, the note refers to the 1,500 (W3C, Making Content Usable) most common words or phrases of a language. And English paragraphs of more than 50 words (W3C, Making Content Usable) are best broken into two, the note suggests, a guideline that translates loosely to German copy with its longer words.
What WCAG 2.2 already covers
WCAG 2.2 has been a W3C Recommendation since 5 October 2023 (W3C, What's New in WCAG 2.2) and adds 9 (W3C, What's New in WCAG 2.2) new success criteria compared with WCAG 2.1. Three of them turn patterns from the note into testable requirements at Levels A and AA:
- 3.2.6 Consistent Help (Level A): if contact details, a contact mechanism, a self-help option or an automated chat repeat across pages, they appear in the same order relative to the rest of the content (W3C, WCAG 2.2). People who need help can find it more easily if it is in the same place (W3C, What's New in WCAG 2.2).
- 3.3.7 Redundant Entry (Level A): information already entered or provided in the same process is either filled in automatically or available to select (W3C, WCAG 2.2). Some people with cognitive disabilities have difficulty remembering what they entered before (W3C, What's New in WCAG 2.2).
- 3.3.8 Accessible Authentication (Minimum) (Level AA): no login step requires a cognitive function test such as remembering a password or solving a puzzle unless an alternative or assistance is offered, or the test only asks users to recognize objects or images, video or audio they provided themselves (W3C, WCAG 2.2). Some people with cognitive disabilities cannot solve puzzles, memorize a username and password, or retype one-time passcodes (W3C, What's New in WCAG 2.2).
On top of that, 3.3.9 at Level AAA no longer allows these two exceptions (W3C, WCAG 2.2). We cover the new criteria in detail in WCAG 2.2: new success criteria and the login in accessible authentication.
Older criteria cover parts of the objectives too. Forms need labels or instructions (3.3.2, Level A) (W3C, WCAG 2.2), and detected input errors come with a suggested correction where one is known (3.3.3, Level AA) (W3C, WCAG 2.2). For legally or financially binding transactions, users can review, confirm and correct their information before submitting (3.3.4, Level AA) (W3C, WCAG 2.2). Apart from exceptions such as a real-time auction, time limits must be possible to turn off, adjust or extend; when extending, users get a warning and at least 20 seconds (W3C, WCAG 2.2) for a simple action, at least ten times (W3C, WCAG 2.2) (2.2.1, Level A). Fields for personal data expose their purpose in a machine-readable way (1.3.5, Level AA) (W3C, WCAG 2.2) so browsers can fill them in. How timers and countdowns comply is covered in countdown, timer, pop-up.
The table maps the eight objectives to the success criteria (W3C, WCAG 2.2). It also shows where WCAG only says something at Level AAA and what appears only as a pattern in the note (W3C, Making Content Usable). The mapping is a professional assessment, not an official W3C mapping.
| Objective of the note | Criterion at Level A or AA | Only at Level AAA | Only a pattern in the note |
|---|---|---|---|
| 1 Understand | 3.3.2 Labels or Instructions, 3.2.4 Consistent Identification, 2.4.6 Headings and Labels | 2.4.8 Location | state the page purpose, familiar design |
| 2 Find | 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, 1.3.1 Info and Relationships | 2.4.10 Section Headings | highlight the most important tasks, search with typo correction |
| 3 Clear content | none at the language level | 3.1.3 Unusual Words, 3.1.4 Abbreviations, 3.1.5 Reading Level | common words, literal language, short paragraphs |
| 4 Avoid mistakes | 3.3.1, 3.3.3, 3.3.4, 2.2.1, 3.2.2 | 2.2.6 Timeouts, 3.3.6 | costs at the start, several input formats |
| 5 Keep focus | 2.2.2 Pause, Stop, Hide; 1.4.2 Audio Control | 2.2.4 Interruptions | short paths, little content per screen |
| 6 No memory load | 3.3.7 Redundant Entry, 3.3.8 Accessible Authentication, 1.3.5 Identify Input Purpose | 3.3.9 Accessible Authentication (Enhanced) | no calculating or memorizing across steps |
| 7 Help | 3.2.6 Consistent Help (location, not provision) | 3.3.5 Help | human help, explain the effects of options |
| 8 Adapt | 1.4.4 Resize Text, 1.4.12 Text Spacing, 1.3.5 Identify Input Purpose | 1.3.6 Identify Purpose | simplified view, allow extensions |
Companies that test against the German Accessibility Strengthening Act (BFSG) need one more note. Until the European Commission cites the new version of EN 301 549 in the Official Journal, version V3.2.1 remains the reference, and it is based on WCAG 2.1 Level AA (AccessibleEU). The three new criteria 3.2.6, 3.3.7 and 3.3.8 are therefore not yet part of the legal reference standard. Version V4.1.1, published in September 2026 (AccessibleEU), adopts WCAG 2.2 as the benchmark for websites, software and digital documents (AccessibleEU). Anyone rebuilding now builds toward what is coming. More on the standard in EN 301 549: the EU standard behind the BFSG.
Where the success criteria stop
The W3C says itself that WCAG does not cover everything. By its own account, the guidelines offer only some accommodation for learning disabilities and cognitive limitations and will not address every user need of the people affected (W3C, WCAG 2.2). In the introduction to WCAG 2.2, the working group describes significant challenges in defining additional criteria for cognitive, language and learning disabilities: a short timeline and a lack of consensus on testability, implementability and international considerations (W3C, WCAG 2.2).
Testability is the core issue. Success criteria are written as testable, technology-neutral statements (W3C, WCAG 2.2). “Use common words” or “keep text succinct” is hard to express that way, and what is clear for one group may be too abstract for another. Where criteria do exist, they often sit at Level AAA: reading level (3.1.5) (W3C, WCAG 2.2), context-sensitive help (3.3.5) (W3C, WCAG 2.2) or a warning about data loss from inactivity unless data is kept for more than 20 hours (W3C, WCAG 2.2) (2.2.6).
Level AAA only helps so far. The W3C does not recommend requiring AAA conformance as a general policy for entire sites because not all AAA criteria can be met for some content (W3C, WCAG 2.2). And it states that even content conforming at AAA will not be accessible to everyone, particularly in the cognitive, language and learning areas (W3C, WCAG 2.2). Whether the next generation of guidelines will do more here is open; the current status is described in WCAG 3.0 draft 2026.
Conformant does not mean understandable
Neurodiversity: different needs, not one profile
Cognitive accessibility is not a single target group with one profile. Often only some functions are impaired while others are unaffected; the note’s example is that someone with dyslexia may be a fantastic engineer (W3C, Making Content Usable). Design therefore does not mean simplifying across the board but removing specific loads: reading, remembering, calculating and distraction.
Sometimes needs even conflict. Content with fewer words and more numbers may be ideal for some autistic and dyslexic users (W3C, Making Content Usable). For people with dyscalculia who struggle with numeric information, the same content is inaccessible (W3C, Making Content Usable). The note therefore recommends usability testing with a diverse group: people with memory, learning, attention, numeric and language impairments as well as intellectual disabilities (W3C, Making Content Usable). What helps individual groups can still be named:
- Dyslexia: short paragraphs, clear sentence structure and a search that corrects misspellings and suggests terms (W3C, Making Content Usable). Fonts, line length and spacing are covered in accessible typography.
- ADHD: limit interruptions, because they stop people with memory or attention impairments from completing their task (W3C, Making Content Usable). Carousels and tickers need a stop control; the persona Yuki could not switch them off on her own website (W3C, Making Content Usable).
- Autism: literal language instead of jokes and similes, because some autistic people may not understand them (W3C, Making Content Usable). This matters most in instructions and error messages.
- Dyscalculia: make quantities understandable without numbers, for example with product photos or sizes such as small, medium and large, as the persona Jonathan needs when shopping (W3C, Making Content Usable).
- Dementia and memory loss: every step shows where the user is so they can pick up again after an interruption, and nothing has to be carried from one page to the next (W3C, Making Content Usable).
One form step before and after
A typical checkout shows how the grid works in practice. In the original version, billing address, delivery address, date of birth, customer account and voucher code share one page, with an accessories offer in between. The help link sits in the header on one page and next to the submit button on another. Anyone entering a different delivery address types their name and phone number a second time. Every field can be labeled correctly and the page still overloads a limited working memory.
The revised version does not change the data, only its order and the load it creates:
- Make the step visible: “Step 2 of 4” with the names of the steps. The pattern asks for completed, current and pending steps so users can reorient themselves after a distraction (W3C, Making Content Usable).
- One topic per step: only the delivery address, no accessories, no upsells. Optional steps are separated and not forced on the user (W3C, Making Content Usable).
- Carry entries over: name and phone number from step 1 are ready, and a checkbox “deliver to the billing address” reuses the address. That meets 3.3.7 and saves everyone typing (W3C, WCAG 2.2).
- Help in the same place: phone and chat sit in the same spot in every step (3.2.6). The pattern goes further and recommends human help that is easy to find on each page and at each step of a process (W3C, Making Content Usable).
- Costs up front: shipping costs and possible surcharges appear at the start, not on the last page. The note asks for all charges at the start of a transaction, including typical values (W3C, Making Content Usable).
- No time pressure: no session that expires halfway through the form, progress is saved as users go (W3C, Making Content Usable). Where a time limit cannot be avoided, 2.2.1 applies.
- Accept formats: postal codes with or without spaces, phone numbers with or without parentheses. The field accepts variations instead of flagging them as errors (W3C, Making Content Usable).
In code, the rebuild is manageable. The example shows the second step with a progress indicator, carried-over data and a fixed help area:
<!-- Step 2 of 4: one topic, carried-over data, help in a fixed place -->
<nav aria-label="Checkout progress">
<ol class="steps">
<li>Contact <span class="visually-hidden">(completed)</span></li>
<li aria-current="step">Delivery address</li>
<li>Payment</li>
<li>Review and order</li>
</ol>
</nav>
<h1>Step 2 of 4: Delivery address</h1>
<form action="/checkout/payment/" method="post">
<label>
<input type="checkbox" name="same_address" checked>
Deliver to the billing address from step 1
</label>
<fieldset id="other-address" hidden>
<legend>Different delivery address</legend>
<label for="street">Street and house number</label>
<input id="street" name="street" autocomplete="shipping street-address">
<label for="zip">Postal code</label>
<input id="zip" name="zip" inputmode="numeric" autocomplete="shipping postal-code">
<label for="city">City</label>
<input id="city" name="city" autocomplete="shipping address-level2">
</fieldset>
<a href="/checkout/contact/">Back to contact</a>
<button type="submit">Continue to payment</button>
</form>
<!-- sits in the same place in the source of every step -->
<aside class="help-panel" aria-labelledby="help-title">
<h2 id="help-title">Help with your order</h2>
<p><a href="/contact/">Phone and chat</a>, answers in <a href="/help/">FAQ</a></p>
</aside>The checkbox is preselected, and the fields below only appear when it is cleared. The autocomplete values meet 1.3.5 and let browsers and password managers fill in what they already know (W3C, WCAG 2.2). The help area sits in the same place in the source of every step so the order stays the same when users zoom in. The back link returns to the previous step without discarding entries. What error messages look like in this flow is covered in accessible forms: labels and validation.
Bringing the grid into audit and development
The note does not work as a second, endless checklist but as a close look at the flows that matter for customers and revenue. A six-step approach keeps the mandatory and the optional apart:
- Secure the baseline: test WCAG 2.2 at Level AA, including 3.2.6, 3.3.7 and 3.3.8. The grid adds to this test, it does not replace it. Process and scope are described on the WCAG audit page.
- Pick the core flows: sign-up, login, search, product page, checkout, contact and cancellation. Go through the eight objectives as questions for each flow.
- Check patterns against examples: for each pattern, check whether a “use” example is implemented and the “avoid” examples are absent. The note also mentions work on testable statements per pattern with test processes and failure examples that was still ongoing when it was published (W3C, Making Content Usable).
- Test with affected users: the note recommends involving people with cognitive and learning disabilities throughout the design and development process (W3C, Making Content Usable). How such sessions work is covered in usability testing with disabled participants.
- Keep findings apart: list WCAG failures and recommendations from the note in separate columns of the remediation plan so that obligations and extra benefit are not confused.
- Anchor patterns in components: build the step indicator, help area, error message and review page once, properly, and reuse them, as described in accessible design system.
Eight questions for every core flow
What the BFSG requires and what it does not
The German Accessibility Strengthening Act (BFSG) explicitly includes people with cognitive disabilities. Under section 2 no. 1 BFSG, people with disabilities are people with long-term physical, mental, intellectual or sensory impairments (BFSG); long-term means a period that is highly likely to last longer than six months (BFSG). Under section 3 (1) BFSG, products and services are accessible if people with disabilities can find, access and use them in the usual way, without particular difficulty and, as a rule, without outside help (BFSG).
For websites, section 12 no. 3 of the BFSG ordinance (BFSGV) specifies that they must be perceivable, operable, understandable and robust in a consistent and adequate way (BFSGV). “Understandable” is therefore part of the obligation. It is demonstrated technically through the harmonized standard, which relies on WCAG criteria at Level AA. The patterns of the COGA note go beyond that and are not a legal obligation. They do help answer whether a flow can really be used “without particular difficulty”, for instance when a complaint comes in. Scope and exemptions are summarized on the BFSG requirements page.
From pattern to component
The patterns have the most effect when they are not a retrofit but part of templates and components. A stepper with a step indicator, a help area in a fixed position, error messages in common words and a review page before submitting are built once and then apply to every form. For editors and designers, the content patterns count instead: clear words, short paragraphs, literal language and summaries. They belong in the style guide and in training because they are decided anew with every new piece of text.
Having copy translated into Easy Language covers part of the third objective; flows, memory and help remain separate tasks. How commissioning works is described in commissioning Easy Language. For older customers, who often combine cognitive and physical limitations, older customers and online shopping barriers sets out an order for the most important changes. Our accessible web development team handles the rebuild in your existing code, and our training passes the knowledge on to your team.
Sources
Related Articles
Bus, rail, ferry: what § 15 BFSGV requires you to publish
Long-distance bus, train, ferry or flight: the four types of information § 15 BFSGV requires, when the regional exemption applies and how to test your site.
Accessible ticket shop: seat map, companion seat, e-ticket
Ticket shops under the BFSG: seat map with an equivalent seat list, bookable wheelchair and companion seats, mark B, a fair time window and a readable e-ticket.
Select Menus Without Surprises: WCAG 3.2.2 On Input
WCAG 3.2.2 in online stores: why sort, language and variant menus must not reload on the first arrow key, and how an Apply button and a keyboard test fix that.