Cognitive Accessibility in WCAG 2.2: Beyond Perceivable and Operable

The Cognitive Accessibility Gap

WCAG has historically prioritized sensory disabilities (vision, hearing) and motor disabilities over cognitive ones. Users with cognitive and learning disabilities represent the largest disability group — an estimated 15-20% of the global population — yet received limited attention in WCAG 2.0 and 2.1.

WCAG 2.2 begins to address this gap with criteria specifically targeting cognitive load, memory requirements, and consistency. Three new criteria directly serve users with cognitive disabilities: Consistent Help (3.2.6), Redundant Entry (3.3.7), and Accessible Authentication (3.3.8).

Consistent Help (3.2.6) — Level A

Users with cognitive disabilities rely on consistent patterns to navigate. If help is available on some pages but not others, or moves between the header and footer unpredictably, users who need it most can't find it.

The requirement: if help mechanisms exist (contact info, chat widgets, FAQ links, phone numbers), they must appear in the same relative order on every page. The help doesn't need to be on every page — but wherever it appears, it must be in the same position within the page structure.

// Good: Help mechanism in consistent position
// Layout component ensures help is always in the same spot
function AppLayout({ children }) {
  return (
    <div>
      <Header /> {/* Nav always has Help link in position 5 */}
      <main>{children}</main>
      <Footer>
        {/* Help contact always: Phone → Email → Chat → FAQ */}
        <HelpSection>
          <PhoneNumber />
          <EmailLink />
          <ChatWidget />
          <FAQLink />
        </HelpSection>
      </Footer>
    </div>
  );
}

Redundant Entry (3.3.7) — Level A

Users with cognitive disabilities struggle with short-term memory. Re-entering information they've already provided (address on shipping page, then again on billing; email during signup, then again on the next step) creates unnecessary cognitive burden and increases error rates.

The requirement: information previously entered by or provided to the user that is required on the same or subsequent steps must be either auto-populated or available for the user to select. Exceptions: re-entering a password for security confirmation, and when the previously entered information is no longer valid.

• Auto-populate billing address from shipping address (with option to change)
• Pre-fill email in confirmation steps — don't ask users to re-type it
• Use session storage to persist form data across multi-step flows
• Provide 'Same as above' checkboxes for repeated information groups
• Use autocomplete attributes to leverage browser-stored data
• Never require re-entering information that's visible elsewhere on the page

Accessible Authentication (3.3.8) — Level AA

Cognitive function tests — CAPTCHAs, math puzzles, remembering passwords, transcribing codes — create barriers for users with cognitive disabilities. WCAG 2.2 requires that authentication flows don't rely on cognitive tests unless alternatives are provided.

What passes: paste-able password fields (users can paste from password managers), passkeys/biometrics, magic links sent to email, OAuth/SSO with identity providers, and any method that doesn't require memorization, transcription, or puzzle-solving.

What fails: CAPTCHAs without audio/accessible alternatives, password fields that block paste (why do sites still do this?), SMS codes that must be memorized and typed (clipboard access helps), and 'select all images with traffic lights' challenges.

// Good: Allow paste, support password managers, offer alternatives
<input
  type="password"
  autoComplete="current-password"  // Enables password manager
  // Do NOT add onPaste={(e) => e.preventDefault()} 
/>

// Good: Passkey / biometric option
<button onClick={startWebAuthn}>
  Sign in with passkey
</button>

// Good: Magic link alternative
<button onClick={sendMagicLink}>
  Email me a login link
</button>

Implementing Without Breaking UX

The good news: cognitive accessibility improvements almost always improve UX for everyone. Consistent help placement helps all users find support. Pre-populated forms save everyone time. Authentication without CAPTCHAs increases conversion rates.

Practical implementation steps: 1) Audit your help mechanisms — are they in the same position on every page template? If not, standardize in your layout component. 2) Map your multi-step forms — identify every field that repeats between steps and add auto-population. 3) Check your authentication flow — can a user with a password manager log in without memorizing anything? Remove paste blockers and add passkey support.

• Add help mechanisms to your global layout (not individual pages) — guarantees consistency
• Use React Context or similar to pass form data between multi-step components
• Add autocomplete attributes to ALL form fields — browsers do the memory work
• Implement WebAuthn for passwordless authentication (navigator.credentials API)
• Remove all onPaste preventDefault() handlers from input fields immediately
• Test with a 'fresh brain' — can a user who forgot everything still complete the flow?