Learning Disability Week runs from June 15 to 21 this year. Mencap leads the campaign under the theme “Do You See Me?” The message is simple. Stop treating people with learning disability as invisible in spaces built for everyone else. This is where the importance of cognitive accessibility is highlighted.
As Mencap notes, people with a learning disability are often “overlooked, underestimated and invisible in society.” Digital products are one such space. Cognitive accessibility is where that invisibility shows up most often, and most quietly.
A site can clear every automated WCAG scan and still exhaust the working memory of someone trying to complete a loan application or renew a benefit online.
Digital products are one such space. Cognitive accessibility is where that invisibility shows up most often, and most quietly. A site can clear every automated WCAG scan and still exhaust the working memory of someone trying to complete a loan application or renew a benefit online. The standard isn’t the problem. How it gets audited is.
What Cognitive Load Actually Means
Cognitive load theory comes from educational psychologist John Sweller. He studied how working memory limits affect learning. Working memory holds only a small number of items at once. Anything that competes for that limited space slows comprehension or breaks it.
Sweller split cognitive load into three types. Intrinsic load comes from the inherent difficulty of a task. Filing taxes is harder than checking a weather app, no matter how clean the design is. Extraneous load comes from how information gets presented. A cluttered form adds friction unrelated to the task itself. Cognitive load is the effort that builds real understanding. It’s the productive kind of mental work, the kind worth protecting.
Good design cannot remove intrinsic load. It can and should remove extraneous load. That distinction matters. Most complaints about cognitive accessibility are really complaints about extraneous load. Unnecessary jargon. Inconsistent navigation. Unclear error states. Walls of text where a short instruction would do the job better.
WCAG Already Addresses This
A common misconception treats WCAG as a standard only for screen readers and color contrast. Several success criteria exist specifically to reduce extraneous cognitive load. They’ve been part of WCAG for years, not bolted on as an afterthought.
W3C’s own guidance on cognitive accessibility maps several WCAG guidelines directly to cognitive and learning disabilities. Predictable. Readable. Input Assistance. These guidelines sit inside the core conformance model. Every WCAG 2.1 and 2.2 AA audit is supposed to test against them already.
The criteria that do the heaviest lifting for cognitive load include:
- 3.2.3 Consistent Navigation and 3.2.4 Consistent Identification, requiring the same labels and layout across pages
- 3.3.2 Labels or Instructions, requiring clear guidance wherever a user has to provide input
- 3.3.4 Error Prevention, requiring confirmation or correction steps before financial, legal, or data-altering actions
- 3.1.5 Reading Level, addressing plain language and comprehension
- 2.2.1 Timing Adjustable, requiring users to get enough time to read and act
A criterion can be technically present and still functionally useless. That gap, not the standard itself, is where cognitive accessibility breaks down.
Predictable Navigation and Consistent Identification
Success criteria 3.2.3 and 3.2.4 require that navigation and labeling stay consistent across a site. A button labeled “Submit” on one screen shouldn’t turn into “Confirm” on the next screen if it performs the same action. This sounds minor. It isn’t, once you watch someone with a learning disability or a short-term memory impairment relearn an interface on every new page.
Take a banking KYC flow. The upload step says “Upload Document” on page two. It says “Attach File” on page four. A user without a cognitive disability barely notices the shift. A user managing limited working memory has to stop. They reread both labels. They confirm these are the same actions before continuing. That stop-and-reread cycle is extraneous load. It’s exactly what 3.2.3 and 3.2.4 exist to prevent.
Labels, Instructions, and Error Prevention
Success criterion 3.3.2 requires labels or instructions wherever content asks for user input. Success criterion 3.3.4 requires error prevention for legal, financial, or data-altering actions. That usually means confirmation steps, or a clear way to review and correct entries before final submission.
Government benefit portals fail here often. Picture a multi-step application that drops a user back to a blank form after a validation error. No message explains what went wrong. No indicator shows which fields need fixing. This might still pass an automated scan, since a label technically exists somewhere in the page code. It still fails the person filling it out. The actual cognitive task, figuring out what broke and where, gets left entirely to them. COGA’s own guidance on multi-step processes points at the same failure, asking that completed steps, the current step, and pending steps all stay visible so a user doesn’t have to reconstruct progress from memory.
Reading Level and Adjustable Timing
Success criterion 3.1.5 addresses reading level. Success criterion 2.2.1 addresses adjustable timing. Both matter constantly inside enterprise SaaS dashboards, where dense terminology and short session timeouts are the default setting, not the exception.
A user with dyslexia or a processing difference often needs more time to read a data table. This isn’t about comprehension ability. Decoding text itself consumes working memory, memory that should go toward the actual decision the table is meant to support.
Why Audits Miss It Anyway
None of this sits hidden inside WCAG. So why do audited, technically compliant products still feel cognitively brutal to use day to day?
Because most audits check for presence, not function. An automated scanner confirms a label exists. It cannot confirm the label is clear enough to prevent confusion. A manual auditor working through a checklist confirms a confirmation step exists before a financial transaction goes through. They rarely test whether a first-time user, under time pressure, actually understands what they’re confirming.
That gap shows up the same way across most compliance work:
- A label exists, but nobody has tested whether it reduces confusion
- A confirmation step exists, but nobody has tested whether users understand what they’re confirming
- A reading-level note exists, but nobody tested actual comprehension against it
- A timeout extension exists, but nobody has tested whether users notice it in time to use it
Closing that gap means testing intent, not just structure. That’s a different discipline from running an automated crawler against a sitemap and calling the job finished. This is why a push for digital accessibility must rely on systems and not just empathy. As the W3C Cognitive and Learning Disabilities Accessibility Task Force notes,
“People with cognitive and learning disabilities can be helped by support for language, memory, focus, and attention, and by reducing unnecessary complexity.” — W3C Cognitive and Learning Disabilities Accessibility Task Force (COGA)
The Limits of Checklist-Based Testing
W3C’s COGA task force builds its supplemental guidance around real personas, a retired lawyer with dementia, a yoga teacher with ADHD, and a librarian recovering from a brain injury, rather than abstract success criteria. The task force frames its own work as guidance for people with cognitive disabilities, learning disabilities, and neurodivergent profiles, built specifically to go beyond what a normative checklist can capture. That’s the right instinct for testing, even outside COGA’s own scope. A scanner cannot tell you whether a fourteen-step form would defeat someone managing short-term memory loss. A tester walking through that same form as that persona can.
Procurement processes make this worse. Many government and enterprise RFQs ask vendors to confirm WCAG conformance through a single automated report. The report shows pass rates per criterion. It says nothing about whether a real user with a cognitive or learning disability could finish a real task. A vendor can hand over a green report and still ship something that fails the exact population the audit was meant to protect. Buyers rarely know to ask for anything more, because the checklist looks complete on its face.
This pattern repeats across sectors. Accessibility debt builds the same way technical debt does, through shortcuts that pass a scan today and compound into real usability failures later. Cognitive load is one of the most common forms of that debt. It stays invisible to automated tools, so it’s easy to defer and easy to forget until users start dropping out of a flow. By the time drop-off rates get noticed, fixing the underlying cognitive accessibility gaps costs far more than catching them during the original audit would have.
What Auditing for Cognitive Load Actually Looks Like
Testing for learning disabilities digital accessibility support means moving past the checklist and into task-based evaluation. Does a first-time user finish a multi-step form without outside help? Does an error message say exactly what to fix, in plain language, right where the mistake happened?
This is where manual expertise earns its place over automated scanning alone. A tool can verify that alt text exists somewhere in the markup. It cannot tell you whether a fourteen-step government application overwhelms a first-time applicant with a learning disability. It cannot flag whether jargon-heavy instructions on a BFSI dashboard quietly exclude the exact users that WCAG’s Readable guideline was written to protect.
Frameworks like the ADA, the EAA, EN 301 549, and India’s RPwD Act 2016 all point back to WCAG as the underlying technical standard. GIGW 3.0 builds directly on it for government platforms. None of these frameworks asks for cognitive load testing as a separate checkbox, because WCAG already contains the relevant criteria. What’s missing in most compliance work isn’t a new rule to add. It’s the discipline of testing against what the existing rules were written to achieve in the first place.
Being Seen Means Testing for the Right Thing
“Do You See Me?” is a fair question to put to any digital product built for public use. A user who clears every WCAG checkpoint and still can’t finish a form hasn’t been seen by the process that certified the product as accessible. Compliance on paper and usability in practice are not automatically the same thing. The distance between them is exactly where people with learning and cognitive disabilities fall through.
That distance is also where real risk sits for the organizations that commission these audits. A product that technically conforms but functionally excludes a known user group is still exposed, whether the exposure shows up as legal risk, reputational damage, or simply a support queue full of people who couldn’t complete a task they had every right to complete. Cognitive accessibility isn’t a soft add-on to a compliance program. It’s the part of the program that determines whether the rest of the work actually reaches the people it was built for.
Closing that distance doesn’t call for rewriting the standard. It calls for auditing for what the standard was always meant to protect, and for treating cognitive load as seriously as any other axis of accessibility testing.
If your last audit only checked whether the criteria existed, it’s worth asking what would happen if someone actually tested against them. Talk to Pivotal Accessibility about an audit that does.