We talk a lot about accessibility in web design, but there’s a blind spot that keeps coming up in real projects: what happens when “security” features quietly exclude people with Special Educational Needs (SEN), including dyslexia, ADHD and autistic spectrum conditions.

I’m not talking about edge cases. I’m talking about the everyday friction of logging in, proving you’re human, and getting through sign‑up flows that assume everyone reads, remembers and processes information in the same way.

Neurodivergence and the “Cognitive Tax” of the Web

For dyslexic and neurodivergent users, the web often adds a cognitive tax on top of everything else they’re dealing with.

Common pain points include:

• Dense text blocks, long lines and weak hierarchy that make tracking and comprehension harder.
• Interfaces that rely on short‑term memory (codes, passwords, one‑time phrases) under time pressure.
• “Gotcha” verification steps that punish hesitation, second‑guessing or re‑reading.

Guidance from organisations like the British Dyslexia Association and Scope UK repeatedly stresses the basics: clear headings, short paragraphs, strong visual signposting, and options to consume content in different formats.

Those aren’t just nice‑to‑haves; they’re survival tools in interfaces that already demand a lot of working memory and visual processing.

Dyslexia‑Friendly UX: Beyond Fonts and Colours

There’s a tendency to reduce “dyslexia‑friendly design” to “pick a nice font and avoid pure white.” That’s a start, but it’s nowhere near enough.

Practical, evidence‑backed patterns include:

• Short paragraphs and meaningful headings so users can skim and re‑locate their place quickly.
• Generous line spacing and increased letter spacing, which the British Dyslexia Association notes can improve readability when increased by around a third.
• Allowing users to adjust text size, colours and contrast, rather than locking everything to a brand palette.
• Using visuals—icons, flow diagrams, simple illustrations—to support text, not to replace it.

Scope UK explicitly recommends putting key information up top, using descriptive link text instead of “click here”, and offering audio or video explanations for dense or important content.​

These are low‑cost changes, but they dramatically lower the cognitive overhead of just reading your site.

When “Prove You’re Human” Treats People as Robots

Now for the bit that rarely makes it into design discussions: CAPTCHA and other verification steps.

Traditional CAPTCHAs were built on the idea that humans can do certain cognitive tasks that bots can’t—like reading distorted text, picking out objects in low‑quality images, or following fiddly audio prompts.

The W3C is blunt about the fallout: many common CAPTCHA techniques lock out users who are blind, visually impaired, dyslexic, Deaf or who have other cognitive and learning disabilities.

For dyslexic and neurodivergent users, problems include:

• Distorted letterforms that are deliberately hard to read (exactly what you try to avoid elsewhere).
• Timer‑based challenges that ramp up anxiety and reduce accuracy.​
• Audio CAPTCHAs that are muddy, fast and layered with background noise.

Research cited by accessibility groups notes that traditional CAPTCHAs are solved less reliably by users with learning disabilities and reading difficulties.​

And the kicker? Many of these CAPTCHAs are no longer especially good at stopping modern bots, which means we’re trading usability for security theatre.

WCAG 3.3.8 and 3.3.9: Authentication Without the Puzzle

The newer WCAG criteria on accessible authentication are a quiet revolution that most product teams still haven’t caught up with.

• WCAG 3.3.8 (Accessible Authentication – Minimum) says you must offer at least one login method that doesn’t rely on a cognitive function test like memorising a password or solving a puzzle.
• WCAG 3.3.9 (Accessible Authentication – Enhanced) goes further and removes most of the exceptions—no more relying solely on recognising images, patterns or user‑supplied photos as the main way to log in.​

Plain‑English explainers from AAArdvark Accessibility and others make the intent crystal clear: logging in shouldn’t be a memory or perception challenge, especially for people who struggle with attention, recall or visual processing.

If your authentication flow hinges on “remember which pictures you picked six months ago” or “type this distorted text correctly in 10 seconds,” you’re not just being a bit awkward—you’re out of line with modern accessibility expectations.

Alternatives to CAPTCHA That Still Protect Security

The good news is that we’re no longer limited to “ugly image puzzle or nothing.” There are far better options that respect both security and accessibility.

Patterns that reduce the cognitive load include:

• Magic links: Email a single‑use sign‑in link so users don’t have to remember passwords or decipher CAPTCHAs.
• Passwordless login with one‑time codes: Short codes sent via SMS or email can be more manageable than full passwords, especially alongside auto‑fill or copy‑paste.
• Biometric login: Let the browser or device handle fingerprints or face recognition via WebAuthn, rather than reinventing the wheel.
• Third‑party identity providers: “Continue with…” buttons (when implemented accessibly) shift the heavy lifting to providers that already invest heavily in secure, accessible authentication.

Guides from Auth0 and other identity platforms now explicitly call out that authentication flows should avoid cognitive tests and work smoothly with password managers and assistive tech.

And when you really do need bot protection, look at approaches that run invisibly or almost invisibly in the background—risk‑based checks, server‑side analysis, and non‑interactive tokens—rather than forcing every user through a puzzle at the point of maximum friction.

Designing Dyslexia‑Friendly Verification and Forms

Verification isn’t only about CAPTCHA; it also shows up in form validation, error messages and “are you sure?” flows.

Some practical steps that play nicely with dyslexic and neurodivergent users:

• Keep instructions close to the field they relate to, not in a big block of text at the top.
• Use plain language, short sentences and consistent terminology—don’t rename the same concept three times in one flow.
• Avoid forcing users to re‑enter everything if they make one mistake; highlight the specific field and explain clearly what needs changing and why.
• Give people time. If you must time‑limit a step for security reasons, make the limit generous and signal it clearly, with the option to restart without losing all progress.

Local government and charity guidance in the UK, including from Dyslexia Scotland and Croydon Council, emphasises that simple layout, clear labelling and forgiving error handling are often more impactful than any particular font choice.

It’s not about lowering security; it’s about not punishing users for reading differently, processing differently, or needing a moment to double‑check.

Giving Users Control: Modes, Preferences and Choice

One pattern I particularly like is the idea of a “dyslexia‑friendly mode” or broader “reading preferences” panel.

Smashing Magazine has a good case study showing how you can add a mode that changes font, spacing, line length and contrast using CSS alone, without touching the underlying content.​

Combined with the British Dyslexia Association’s guidance, that gives you a practical recipe:

• Increase line height and letter spacing.
• Slightly reduce maximum line length.​
• Soften contrast where pure black on white is hard on the eyes, while still meeting minimum contrast ratios recommended by accessibility standards.

The point isn’t to guess the perfect experience for every neurodivergent user; it’s to offer tools that let them adapt your interface to how their brain works best.

What This Looks Like in Real Projects

If you’re working on UK or EU‑facing products, there’s a growing body of guidance you can lean on rather than starting from scratch.

• The British Dyslexia Association’s style guide offers concrete advice on text, layout and web design that you can translate directly into design tokens and components.​
• Dyslexia Scotland’s formatting guide aligns with WCAG contrast ratios and adds practical tips on structuring content for readability.​
• W3C’s “Inaccessibility of CAPTCHA” note walks through legacy and modern approaches to human verification and makes a strong case for moving away from puzzles entirely.

Treat these as open‑source thinking you can reference in your own design system docs, accessibility statements and internal training.

When stakeholders push back with “but what about bots?” you can point to W3C and modern WCAG criteria and show that the direction of travel is firmly towards secure, low‑friction, cognitively accessible authentication.

A Simple Checklist for Your Next Build

If you want a quick sanity check for neurodivergent‑friendly access, particularly around verification, start here:

• Can someone with dyslexia skim headings and find what they need without reading every word?
• Is there at least one way to log in that doesn’t rely on solving a visual or audio puzzle, or recalling long strings from memory?
• If you use bot protection, can a significant share of users get through it without reading distorted text or picking tiny objects out of noisy images?
• Do your forms forgive mistakes, explain errors clearly, and avoid forcing full re‑entry?
• Can users adjust typography or switch to a dyslexia‑friendly mode without digging through browser settings?

These aren’t edge‑case luxuries. For a sizeable chunk of your audience, they’re the difference between “I can use this” and “I’m locked out of my own data.”

We talk a lot about accessibility in web design, but there’s a blind spot that keeps coming up in real projects: what happens when “security” features quietly exclude people with Special Educational Needs (SEN), including dyslexia, ADHD and autistic spectrum conditions.

I’m not talking about edge cases. I’m talking about the everyday friction of logging in, proving you’re human, and getting through sign‑up flows that assume everyone reads, remembers and processes information in the same way.

Neurodivergence and the “Cognitive Tax” of the Web

For dyslexic and neurodivergent users, the web often adds a cognitive tax on top of everything else they’re dealing with.

Common pain points include:

• Dense text blocks, long lines and weak hierarchy that make tracking and comprehension harder.
• Interfaces that rely on short‑term memory (codes, passwords, one‑time phrases) under time pressure.
• “Gotcha” verification steps that punish hesitation, second‑guessing or re‑reading.

Guidance from organisations like the British Dyslexia Association and Scope UK repeatedly stresses the basics: clear headings, short paragraphs, strong visual signposting, and options to consume content in different formats.

Those aren’t just nice‑to‑haves; they’re survival tools in interfaces that already demand a lot of working memory and visual processing.

Dyslexia‑Friendly UX: Beyond Fonts and Colours

There’s a tendency to reduce “dyslexia‑friendly design” to “pick a nice font and avoid pure white.” That’s a start, but it’s nowhere near enough.

Practical, evidence‑backed patterns include:

• Short paragraphs and meaningful headings so users can skim and re‑locate their place quickly.
• Generous line spacing and increased letter spacing, which the British Dyslexia Association notes can improve readability when increased by around a third.
• Allowing users to adjust text size, colours and contrast, rather than locking everything to a brand palette.
• Using visuals—icons, flow diagrams, simple illustrations—to support text, not to replace it.

Scope UK explicitly recommends putting key information up top, using descriptive link text instead of “click here”, and offering audio or video explanations for dense or important content.​

These are low‑cost changes, but they dramatically lower the cognitive overhead of just reading your site.

When “Prove You’re Human” Treats People as Robots

Now for the bit that rarely makes it into design discussions: CAPTCHA and other verification steps.

Traditional CAPTCHAs were built on the idea that humans can do certain cognitive tasks that bots can’t—like reading distorted text, picking out objects in low‑quality images, or following fiddly audio prompts.

The W3C is blunt about the fallout: many common CAPTCHA techniques lock out users who are blind, visually impaired, dyslexic, Deaf or who have other cognitive and learning disabilities.

For dyslexic and neurodivergent users, problems include:

• Distorted letterforms that are deliberately hard to read (exactly what you try to avoid elsewhere).
• Timer‑based challenges that ramp up anxiety and reduce accuracy.​
• Audio CAPTCHAs that are muddy, fast and layered with background noise.

Research cited by accessibility groups notes that traditional CAPTCHAs are solved less reliably by users with learning disabilities and reading difficulties.​

And the kicker? Many of these CAPTCHAs are no longer especially good at stopping modern bots, which means we’re trading usability for security theatre.

WCAG 3.3.8 and 3.3.9: Authentication Without the Puzzle

The newer WCAG criteria on accessible authentication are a quiet revolution that most product teams still haven’t caught up with.

• WCAG 3.3.8 (Accessible Authentication – Minimum) says you must offer at least one login method that doesn’t rely on a cognitive function test like memorising a password or solving a puzzle.
• WCAG 3.3.9 (Accessible Authentication – Enhanced) goes further and removes most of the exceptions—no more relying solely on recognising images, patterns or user‑supplied photos as the main way to log in.​

Plain‑English explainers from AAArdvark Accessibility and others make the intent crystal clear: logging in shouldn’t be a memory or perception challenge, especially for people who struggle with attention, recall or visual processing.

If your authentication flow hinges on “remember which pictures you picked six months ago” or “type this distorted text correctly in 10 seconds,” you’re not just being a bit awkward—you’re out of line with modern accessibility expectations.

Alternatives to CAPTCHA That Still Protect Security

The good news is that we’re no longer limited to “ugly image puzzle or nothing.” There are far better options that respect both security and accessibility.

Patterns that reduce the cognitive load include:

• Magic links: Email a single‑use sign‑in link so users don’t have to remember passwords or decipher CAPTCHAs.
• Passwordless login with one‑time codes: Short codes sent via SMS or email can be more manageable than full passwords, especially alongside auto‑fill or copy‑paste.
• Biometric login: Let the browser or device handle fingerprints or face recognition via WebAuthn, rather than reinventing the wheel.
• Third‑party identity providers: “Continue with…” buttons (when implemented accessibly) shift the heavy lifting to providers that already invest heavily in secure, accessible authentication.

Guides from Auth0 and other identity platforms now explicitly call out that authentication flows should avoid cognitive tests and work smoothly with password managers and assistive tech.

And when you really do need bot protection, look at approaches that run invisibly or almost invisibly in the background—risk‑based checks, server‑side analysis, and non‑interactive tokens—rather than forcing every user through a puzzle at the point of maximum friction.

Designing Dyslexia‑Friendly Verification and Forms

Verification isn’t only about CAPTCHA; it also shows up in form validation, error messages and “are you sure?” flows.

Some practical steps that play nicely with dyslexic and neurodivergent users:

• Keep instructions close to the field they relate to, not in a big block of text at the top.
• Use plain language, short sentences and consistent terminology—don’t rename the same concept three times in one flow.
• Avoid forcing users to re‑enter everything if they make one mistake; highlight the specific field and explain clearly what needs changing and why.
• Give people time. If you must time‑limit a step for security reasons, make the limit generous and signal it clearly, with the option to restart without losing all progress.

Local government and charity guidance in the UK, including from Dyslexia Scotland and Croydon Council, emphasises that simple layout, clear labelling and forgiving error handling are often more impactful than any particular font choice.

It’s not about lowering security; it’s about not punishing users for reading differently, processing differently, or needing a moment to double‑check.

Giving Users Control: Modes, Preferences and Choice

One pattern I particularly like is the idea of a “dyslexia‑friendly mode” or broader “reading preferences” panel.

Smashing Magazine has a good case study showing how you can add a mode that changes font, spacing, line length and contrast using CSS alone, without touching the underlying content.​

Combined with the British Dyslexia Association’s guidance, that gives you a practical recipe:

• Increase line height and letter spacing.
• Slightly reduce maximum line length.​
• Soften contrast where pure black on white is hard on the eyes, while still meeting minimum contrast ratios recommended by accessibility standards.

The point isn’t to guess the perfect experience for every neurodivergent user; it’s to offer tools that let them adapt your interface to how their brain works best.

What This Looks Like in Real Projects

If you’re working on UK or EU‑facing products, there’s a growing body of guidance you can lean on rather than starting from scratch.

• The British Dyslexia Association’s style guide offers concrete advice on text, layout and web design that you can translate directly into design tokens and components.​
• Dyslexia Scotland’s formatting guide aligns with WCAG contrast ratios and adds practical tips on structuring content for readability.​
• W3C’s “Inaccessibility of CAPTCHA” note walks through legacy and modern approaches to human verification and makes a strong case for moving away from puzzles entirely.

Treat these as open‑source thinking you can reference in your own design system docs, accessibility statements and internal training.

When stakeholders push back with “but what about bots?” you can point to W3C and modern WCAG criteria and show that the direction of travel is firmly towards secure, low‑friction, cognitively accessible authentication.

A Simple Checklist for Your Next Build

If you want a quick sanity check for neurodivergent‑friendly access, particularly around verification, start here:

• Can someone with dyslexia skim headings and find what they need without reading every word?
• Is there at least one way to log in that doesn’t rely on solving a visual or audio puzzle, or recalling long strings from memory?
• If you use bot protection, can a significant share of users get through it without reading distorted text or picking tiny objects out of noisy images?
• Do your forms forgive mistakes, explain errors clearly, and avoid forcing full re‑entry?
• Can users adjust typography or switch to a dyslexia‑friendly mode without digging through browser settings?

These aren’t edge‑case luxuries. For a sizeable chunk of your audience, they’re the difference between “I can use this” and “I’m locked out of my own data.”

At Acquire Commerce we are happy to help you plan, adapt and hone any project to ensure maximum accessibility for all.,