Cognitive accessibility is the part of digital accessibility that gets the least attention and affects the most people. It covers everyone who finds dense text, unpredictable layouts, and high-friction forms hard to use: people with dyslexia, ADHD, or memory impairments, but also anyone tired, distracted, or using your site in a second language.
For designers and content teams, the good news is that cognitive accessibility is mostly about decisions you already control: how you write, where you put things, and how much you ask people to remember. WCAG 2.2 made two of these concrete with new Level A criteria, 3.2.6 Consistent Help and 3.3.7 Redundant Entry, both part of the European Accessibility Act baseline that applies from 28 June 2025. This guide covers the four moves that matter most.
Plain language: write for the reader, not the brand
Most cognitive load on a website comes from prose, and most of that is self-inflicted. Long sentences, abstract nouns, and jargon force the reader to hold more in working memory than the content actually requires. Plain language is not dumbing down; it is removing the work that does not need to be there.
Concrete edits that pay off immediately:
- Lead with the action. "To reset your password, open Settings" beats "Settings is where password resets can be initiated."
- Cut nominalisations. "We will make a decision" becomes "We will decide." Verbs carry meaning with less effort than noun phrases.
- Keep one idea per sentence and aim for 15 to 20 words. Break the 40-word sentence into two.
- Expand an acronym on first use, and avoid stacking three in a row.
- Front-load links and headings with the keyword, so someone scanning sees "Refund policy" not "Click here for more."
Reading-level conformance (WCAG 3.1.5 Reading Level) is a Level AAA criterion, so plain language is not strictly mandatory at the A/AA baseline. But it directly strengthens criteria you must meet: clear labels satisfy 3.3.2 Labels or Instructions (Level A), and plainly worded errors support 3.3.1 Error Identification (Level A) and 3.3.3 Error Suggestion (Level AA). Also set the page language with the lang attribute (3.1.1 Language of Page, Level A) and mark inline language changes with lang on the element (3.1.2 Language of Parts, Level AA), so screen readers pronounce content correctly.
Clear, consistent layout reduces the cost of every page
A predictable layout lets people reuse what they learned on the last page instead of re-orienting on each new one. When navigation, search, and key actions stay in the same place, the interface stops competing for attention with the content.
- Keep navigation in the same order site-wide (3.2.3 Consistent Navigation, Level AA) and label repeated controls identically (3.2.4 Consistent Identification, Level AA). The cart icon should not become a basket icon on the checkout page.
- Use a logical, visible heading structure. Headings are the primary way many users (and screen readers) build a mental map of a page; skipping levels or styling text to look like a heading without marking it up breaks that map. You can sanity-check structure with a free heading checker.
- Give content room. Don't override the user's ability to adjust line height and spacing (1.4.12 Text Spacing, Level AA). Generous whitespace lowers visual load.
- Make focus and targets obvious. WCAG 2.2 added 2.4.11 Focus Not Obscured (Minimum, Level AA) and 2.5.8 Target Size (Minimum, Level AA, 24 by 24 CSS pixels) so interactive elements are easy to find and hit.
Adequate contrast is part of clarity too: 4.5:1 for normal text, and 3:1 for large text (at least 18pt, or 14pt bold) and for UI components. Low-contrast "quiet" microcopy is a common accessibility regression hiding as a design choice. A contrast checker catches these before they ship.
Consistent Help (WCAG 3.2.6): same help, same place
New in WCAG 2.2 at Level A, 3.2.6 Consistent Help addresses a specific cognitive cost: hunting for help. If your site offers a help mechanism, such as a contact link, phone number, live chat, FAQ, or a self-help option, across a set of pages, it must appear in the same relative order and location on each of those pages.
The criterion does not require you to provide help at all. It governs consistency, not existence. So if the support link lives in the footer on your homepage, it should live in the footer on the pricing and checkout pages too, not jump to the header on one and a sidebar on another. The same applies to a chat widget's position. Users who rely on spatial memory, including many people with cognitive disabilities, can then find help without re-scanning each page.
Practical implementation: place the help mechanism in a shared layout component (a global footer or header) rather than per-page templates, so consistency is structural rather than a thing someone has to remember to copy. Context-specific help is still fine, for example a tooltip next to a tricky field, as long as the recurring mechanism keeps its position. This criterion is part of the WCAG 2.2 set the EAA references through EN 301 549.
Redundant Entry (WCAG 3.3.7): stop asking twice
Also new in WCAG 2.2 at Level A, 3.3.7 Redundant Entry targets memory load in multi-step processes. Within a single process, you must not require users to re-enter information they already provided, unless re-entry is essential, the earlier information is no longer valid, or it is needed for security (such as re-confirming a password).
The everyday offenders are forms and checkouts:
- Billing address that repeats the shipping address. Add a 'Same as shipping' checkbox that copies the values.
- An email or name re-requested on a later step of a wizard. Carry it forward and show it, pre-filled, instead of asking again.
- Account details retyped during onboarding that the system already stored. Auto-populate from what you have.
Either auto-populate the field or make the prior value available for the user to select. This pairs naturally with the autocomplete attribute (which supports 1.3.5 Identify Input Purpose, Level AA) so browsers and password managers can fill fields, and with 3.3.8 Accessible Authentication (Minimum, Level AA), which says not to force a cognitive function test like remembering or transcribing a code when an alternative such as password managers, passkeys, or copy-paste would work. Together these criteria make accessible forms far less punishing for everyone, not only users with memory impairments.
Where this fits in your compliance picture
These cognitive criteria are not a separate standard; they are part of WCAG 2.2 Level A and AA, which is the baseline EN 301 549 points to and which the European Accessibility Act enforces for in-scope products from 28 June 2025. They also align with the de-facto WCAG expectations behind the ADA in the US, which names no specific WCAG version, while Section 508 (Revised) and Ontario's AODA both reference WCAG 2.0 Level AA. Canada's federal Accessible Canada Act adds further obligations for federally regulated organisations. For the full set of criteria, see the WCAG reference; for an actionable working list, an accessibility checklist helps you track coverage flow by flow.
A sensible order of operations: run an automated scan to clear mechanical issues like missing labels, absent lang attributes, and inconsistent component markup, then review plain language, help placement, and redundant entry by hand, because those need human judgment. AccessScan is a free checker (with contrast, alt-text, and heading tools, plus a statement generator) that handles the first pass so your team can focus on the judgment calls that automation can't make.