Deafblindness

• Screen reader and audio CAPTCHAs: Many CAPTCHAs rely on audio alternatives when visual tests fail. For people who are deafblind, audio CAPTCHAs are inaccessible because they cannot both see and hear the challenge, and some screen readers cannot interact properly with these audio controls.
• Tactile/alternative options lacking: Few sites provide tactile or braille alternatives, leaving users without any usable method to prove they are human.
• Cognitive and time pressure: Navigating complex keyboard-only flows and switching between assistive devices (refreshing, downloading, or playing audio) can be slow and difficult, and CAPTCHAs often impose time limits or require rapid responses.

Hearing impairments

• Audio-only CAPTCHAs: CAPTCHAs that provide only spoken challenges exclude users with severe or total hearing loss. Even partial hearing loss can make understanding distorted audio difficult.
• Poor captioning/transcripts: When an audio alternative is provided, it may lack clear captions or text transcripts, or the on-screen controls are not accessible to assistive tech.
• Reliance on sound cues: Some verification flows use short sound cues or beep-based progress signals; these are meaningless for users who cannot hear them.

Practical implications and fixes

• Provide multiple accessible options: visual, text-based, and accessible keyboard flows; avoid audio-only solutions.
• Use accessible, frictionless alternatives: invisible CAPTCHAs, risk-based detection, device/browser signals, or simple challenge questions that comply with WCAG.
• Ensure compatibility with assistive tech: ARIA labels, keyboard navigation, and clear transcripts/captions for any audio content.

References

• Web Content Accessibility Guidelines (WCAG) 2.1, Success Criterion 1.1.1 and 1.4.2.
• W3C WAI guidance on CAPTCHAs and accessible alternatives.

Image and distorted-text CAPTCHAs (e.g., scrambled letters, click-the-images) are often unreadable or hard to perceive for people with vision impairments, low vision, color blindness, or cognitive and motor disabilities. Screen readers cannot reliably interpret images or embedded text, and audio alternatives are frequently unusable (poor quality, heavy background noise, or require fast processing). CAPTCHAs that require precise mouse clicking or dragging also exclude users who rely on keyboard navigation or switch/scanning devices. These barriers can prevent completion of essential tasks (sign-up, purchases, account recovery) and therefore violate accessibility guidelines such as WCAG and practical recommendations from WebAIM. See WCAG 2.1 success criteria (e.g., 1.1.1 Non-text Content, 2.1.1 Keyboard) and WebAIM resources on CAPTCHA accessibility.

Low lighting, glare, or noisy surroundings can make CAPTCHAs unusable because they rely on senses that those conditions impair. Visual CAPTCHAs (distorted text, images) become hard or impossible to see in dim light or when screen glare washes out contrast. Audio CAPTCHAs become ineffective in noisy places or when a user can’t use headphones. Relying on one sensory channel without alternatives excludes people who are temporarily or situationally disadvantaged (e.g., outdoors in bright sun, commuting in a loud bus), not just those with permanent disabilities. Inclusive verification should offer multiple, accessible options (e.g., device-based attestation, accessible challenge alternatives, or invisible risk-based checks).

References: World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG) 2.1; research on CAPTCHA accessibility (e.g., Bigham et al., 2010).

Complex puzzles, strict time limits, or vague instructions in CAPTCHAs can exceed a user’s working memory, attention span, or processing speed. Solving multi-step problems or remembering patterns under time pressure demands cognitive resources that some people with neurological or psychiatric disabilities (e.g., ADHD, traumatic brain injury, learning disabilities, dementia) have reduced or disrupted. Unclear wording or visual clutter increases cognitive load by forcing repeated re-reads or guesswork. The result is confusion, mistakes, repeated attempts, anxiety, and ultimately exclusion from services.

References:

• World Wide Web Consortium (W3C), Web Content Accessibility Guidelines (WCAG) 2.1 — guidance on accessible authentication and alternatives to CAPTCHA.
• Wentz, B., Jaeger, P. T., & Lazar, J. (2011). “Accessible Peers: Accessibility and Usability Issues with Online Captcha”

CAPTCHAs often block people with disabilities because they assume visual, auditory, motor, or cognitive abilities that not all users have. Common problems:

• Visual CAPTCHAs (distorted text, images) are unreadable for users who are blind, have low vision, or have cognitive processing differences.
• Audio CAPTCHAs can be unusable for users who are deaf or hard of hearing, and noisy audio or speech distortions make them hard for many others.
• Time limits and complex interactions (dragging, clicking small targets) exclude users with motor or cognitive impairments.
• Lack of clear instructions or no text alternatives prevents screen reader users from understanding required tasks.

Selection rationale and required approach Always provide true, tested alternatives that work with assistive technologies and follow WCAG guidance. That means:

• Offer accessible text alternatives and clear instructions that a screen reader can read (WCAG 2.1 SC 1.4.5, 3.3.2).
• Avoid reliance on sensory characteristics alone; provide an alternative that does not require specific visual or auditory skills.
• Allow sufficient time and simple, keyboard-accessible controls for completing verification.
• Test alternatives with real assistive technologies (screen readers, voice control, switch devices) and real users with disabilities.

Practical, tested alternatives

• Use invisible risk-based or behavioral bot detection (server-side heuristics or device fingerprinting) that does not require user interaction.
• Implement simple, accessible challenge alternatives: plain-language questions with text alternatives, or one-click verification links sent via email/SMS.
• Use WCAG-compatible secondary checks: e.g., accessible logic challenges that are keyboard and screen-reader friendly, with clear instructions and no strict time-outs.
• Provide multiple verification channels (email, SMS, authenticator apps) and ensure each channel is accessible.

References

• WCAG 2.1: Success Criterion 1.4.5 Images of Text; Success Criterion 3.3.2 Labels or Instructions. (W3C)
• WebAIM: CAPTCHA and Accessibility guidance and testing resources.

(Short, tested alternatives above should be implemented and validated with assistive technologies and users with disabilities.)

Many services add alternative CAPTCHA options (audio CAPTCHAs, simplified puzzles, or “accessibility” links) intending to help users with disabilities. In practice these workarounds often fail because:

• They assume a single, fixed impairment. Audio CAPTCHAs help people with vision loss but are useless for users who are deaf, hard of hearing, or who have cognitive processing or learning disabilities. Likewise visual alternatives don’t help motor-impaired users who can’t manipulate small controls.
• They create extra complexity and friction. Workarounds frequently require navigating extra links, phone calls, or different flows that are harder to find or operate with assistive technologies (screen readers, switch devices, voice control).
• They are inconsistently implemented and tested. Many alternatives are an afterthought and not tested with real users with disabilities or with common assistive tools, so they introduce new barriers (unlabeled controls, timed tasks, inaccessible audio players).
• They can be insecure or unreliable. Some “human-assisted” bypasses (phone-based verification, third‑party services) expose privacy risks, fail in noisy environments, or are unavailable in certain regions or devices.
• They rely on assumptions about technology and context. Poor internet, older browsers, or corporate firewalls can break alternative flows more easily than the main flow.

Result: instead of removing barriers, ill-designed workarounds often shift them or add new ones. Inclusive design — offering multiple, accessible, and tested verification methods (e.g., passkeys, device-based attestation, account recovery options) — is a more reliable solution.

References: Web Content Accessibility Guidelines (WCAG) 2.1; research on CAPTCHA accessibility (e.g., Bigham et al., 2008; W3C notes on CAPTCHAs).

CAPTCHAs that require reading distorted text, solving puzzles, or selecting images create barriers for people with visual, cognitive, motor, or attention impairments, and for users who rely on screen readers or keyboard-only navigation. These challenges can prevent access to essential services, violate accessibility laws (e.g., ADA, EU Web Accessibility Directive), and exclude older or low-vision users.

Use accessible alternatives:

• Invisible or behavior-based risk analysis (reCAPTCHA v3): Evaluates risk in the background based on user behavior, eliminating most user interaction and reducing barriers for assistive-technology users.
• Simple checkbox CAPTCHAs: A single, clearly labeled checkbox (“I’m not a robot”) is easier for keyboard and screen-reader users than complex visual tasks; ensure proper ARIA labeling and focus handling.
• Backend bot-detection (no user interaction): Server-side heuristics (rate limiting, device fingerprinting, IP reputation, challenge throttling) stop bots without any front-end challenge, preserving full accessibility.

Implementation notes: always provide alternatives (e.g., phone/email verification) when automated detection flags a user; ensure ARIA attributes, keyboard focus order, and clear instructions; test with real assistive technologies and users with disabilities. References: W3C Web Accessibility Guidelines (WCAG 2.1), Google reCAPTCHA documentation.

CAPTCHAs often assume a stable baseline of sight, hearing, motor control, attention, or device ability. Temporary or situational disabilities—short-term impairments (e.g., a broken arm, a sprained wrist, a concussion) or situational limits (bright sunlight, noisy public place, tiny screen while walking)—can produce similar barriers to those faced by people with permanent disabilities. Key issues:

• Visual challenges: Image-based or distorted-text CAPTCHAs require fine vision and close focus. Temporary eye strain, vision blur from medication, glare outdoors, or using a small phone can make them unreadable.

• Motor and interaction limits: CAPTCHAs that require precise mouse movement, dragging, clicking small targets, or quickly typing characters are hard with a broken arm, cast, or while holding a child or bag.

• Auditory CAPTCHAs: Audio puzzles are unusable in noisy environments (public transport, a café) or when a user’s temporary hearing impairment (ear infection) limits perception.

• Cognitive load and time pressure: Complex puzzles, sequences, or short time windows worsen problems during concussion, sleep deprivation, or stress—situations that reduce concentration and working memory.

• Device and context mismatch: On mobile devices in motion, or with a one-handed grip, CAPTCHAs that assume a desktop setup become inaccessible.

Consequences: exclusion from services, repeated failures triggering lockouts, added time and stress, and reliance on risky workarounds (sharing accounts, disabling security). Because temporary and situational limitations are common, inaccessible CAPTCHAs create frequent, avoidable barriers for many users.

Better practices: offer multiple workable alternatives (accessible reCAPTCHA, simple behavioral verification, device-based risk signals, or a clearly labeled audio/text alternative), allow generous time, avoid timeouts, and provide an easy, human-accessible fallback (e.g., help link or alternative verification) to accommodate temporary or situational impairments.

References: W3C Web Content Accessibility Guidelines (WCAG) 2.1 (success criteria on timing, input, and alternatives) and WebAIM guidance on CAPTCHA accessibility.

CAPTCHAs often rely on tasks (reading distorted text, solving visual puzzles, following multi-step instructions) that assume certain cognitive skills. For people with cognitive or learning disabilities (e.g., dyslexia, intellectual disability, ADHD, autism spectrum conditions), these features create specific barriers:

• Difficulty decoding distorted text: Dyslexia and other reading difficulties make identifying warped or obscured letters slow or impossible, increasing errors and frustration.
• Working memory and processing demands: Multi-step or time-limited CAPTCHAs overwhelm users who have reduced working memory, slower processing speed, or difficulty maintaining attention.
• Complex instructions and abstract tasks: Nonliteral puzzles (select all images containing X, interpret distorted audio) can be confusing for users who struggle with abstract reasoning or following nuanced directions.
• Audio CAPTCHA limits: Audio alternatives are often noisy, low-quality, or require rapid auditory processing—still inaccessible for many with auditory processing or cognitive challenges.
• Increased anxiety and task abandonment: Repeated failures or unclear feedback can cause stress or discourage continuation, leading to exclusion from services.

Design implications: Use accessible alternatives (risk-based invisible verification, single-tap biometric checks, simple checkbox CAPTCHAs with clear labels, or offering human-assisted routes). Provide clear, simple instructions, enough time, and multiple accessible options so verification does not rely on specific cognitive skills.

Sources: Web Content Accessibility Guidelines (WCAG) on CAPTCHA alternatives and accessibility; academic literature on accessibility barriers for people with cognitive disabilities (e.g., Lazar et al., 2015; W3C guidance).

Audio CAPTCHAs are intended as an alternative to visual tests, but they often fail to serve deaf or hard-of-hearing users. Many deaf people have little or no usable hearing—so even a clear audio clip is ineffective. When audio alternatives are provided, they are frequently low quality (distorted, noisy, or mixed with background sounds) or use rapid speech, accents, or overlapping voices that make them hard to parse. Some require fine-grained hearing abilities (distinguishing tones or brief phonemes) that many deaf users do not possess. As a result, audio CAPTCHAs can be as inaccessible as visual ones, blocking equal access to online services.

Sources: World Wide Web Consortium (W3C) Web Accessibility Initiative — Web Content Accessibility Guidelines (WCAG) and related discussions on accessible alternatives to CAPTCHAs.

CAPTCHAs often require precise mouse control, rapid clicking, dragging, or manipulating small targets (e.g., clicking tiny checkboxes, selecting specific images, or solving drag‑and‑drop puzzles). Users with motor disabilities—such as limited hand coordination, tremors, limited range of motion, paralysis, or use of alternative input devices (switches, head pointers, eye trackers)—can struggle or be unable to complete these interactions. Time limits on challenges and repeated attempts increase fatigue and frustration. Some audio alternatives are inadequate because they still require fine controls or present controls that aren’t keyboard accessible. The result is exclusion from website features, services, or transactions.

Mitigations include providing accessible alternatives (robust audio CAPTCHA with clear controls, keyboard‑navigable challenges, “skip” options tied to accessible verification like one‑time codes sent by email/SMS, device‑based risk assessment, or invisible CAPTCHA techniques) and following Web Content Accessibility Guidelines (WCAG) to reduce barriers (WCAG 2.1 success criteria 2.1.1, 2.1.2, 2.4.5). See W3C and accessibility guidance for details.

Explanation: Many sites offer alternatives to visual CAPTCHAs — for example, audio CAPTCHAs, hidden form fields, or other “accessible” options — but these often create new barriers:

• Audio CAPTCHAs can be unintelligible. They commonly use distorted speech, background noise, or rapid timing that is hard to hear or parse for people who are blind, have low hearing, auditory processing disorders, or non-native speakers. They may also be incompatible with screen readers, which can’t mix their synthesized voice with the CAPTCHA audio reliably. (See WebAIM research on CAPTCHA accessibility.)

• Hidden fields and CSS-based tricks (honeypots) can be unreliable. Techniques that hide fields from sighted users but expect bots to fill them may still be detected by assistive technologies as visible form controls, confusing screen reader users or keyboard-only users. Conversely, workarounds that rely on visual-only cues exclude people who can’t see them.

• Alternative flows break assistive tech or workflows. Some “accessible” options trigger pop-ups, new windows, or JavaScript flows that are not announced to screen readers or that change focus unexpectedly, disrupting navigation and form completion for keyboard and screen-reader users.

• Bypasses can worsen privacy and usability. Audio CAPTCHAs and some third-party verification services may require extra bandwidth, cookies, or connections to external domains, which can interfere with privacy tools and constrained devices commonly used by disabled users.

• Reliability and testing gaps. Many implementations are poorly tested with real assistive technology and diverse disabilities, so they fail in real-world use even if they meet basic WCAG checks.

Better approaches include using non-interruptive, inclusive verification methods (behavioral risk analysis, server-side bot detection, federated identity, or email/SMS verification used with accessible flows) and testing with assistive technology and users with disabilities. For guidance, see WCAG techniques and accessibility research from organizations like WebAIM and the W3C.

Use of CAPTCHAs that are inaccessible to people with disabilities creates legal and compliance risks for organizations. Laws and regulations in many jurisdictions (e.g., the Americans with Disabilities Act (ADA) in the U.S., the EU Web Accessibility Directive, and various national disability discrimination statutes) require entities to provide equal access to goods and services, including online services. If CAPTCHAs block or significantly burden disabled users (for example, those who are blind, have low vision, cognitive impairments, or motor disabilities), organizations may face:

• Disability discrimination claims and lawsuits: Plaintiffs can argue that inaccessible verification routines deny meaningful access to services, leading to litigation, injunctive relief to change the site, and damages or settlements (see cases involving inaccessible websites under the ADA).
• Regulatory enforcement and fines: Government agencies or accessibility regulators may investigate and impose penalties or corrective orders under accessibility rules or consumer-protection laws.
• Contractual and procurement consequences: Public-sector contracts or grants often require compliance with accessibility standards (WCAG). Noncompliance can disqualify bidders, trigger contract termination, or require remediation at cost.
• Reputational and financial harm: Even absent formal legal action, accessibility failures can lead to negative publicity, loss of customers, and remediation expenses once deficiencies are discovered.

Mitigation: Use accessible alternatives (audio CAPTCHA with robust controls, CAPTCHAs that conform to WCAG 2.1 AA, risk-based invisible verification, or accessible human-assisted options), document accessibility efforts, and perform testing with assistive technologies and users with disabilities. References: WCAG 2.1 (W3C), ADA Title III enforcement guidance and recent case law on web accessibility.

reCAPTCHA v3 attempts invisible risk-scoring instead of presenting a visible challenge, but it still raises accessibility concerns:

• False positives for assistive-technology users: v3 scores behavior (mouse movement, timing, browsing patterns). People who use screen readers, switch controls, or keyboard-only navigation often move and interact differently from typical mouse users, which can produce low trust scores and block or add friction to actions (form submission, account creation).
• Lack of meaningful feedback and remediation: When v3 flags a user as low-risk, sites often fallback to more intrusive challenges (CAPTCHA images or audio) that may be inaccessible. Users receive little explanation or accessible alternatives.
• Privacy and profiling implications: v3 relies on background tracking across pages to build risk signals. Some users with disabilities rely on privacy tools or browser configurations that change fingerprinting signals, increasing misclassification risk.
• Inconsistent cross-device experiences: Assistive-device setups (mobile screen readers, switch devices) vary widely, and v3’s scoring can be uneven across devices, leading to unpredictable access barriers.
• Developer implementation gaps: Accessibility depends on how sites handle low scores. Poorly implemented fallbacks or lack of accessible alternatives (e.g., keyboard-navigable challenges, clear ARIA announcements) compound exclusion.

Relevant guidance: Web Content Accessibility Guidelines (WCAG) require alternatives and robust error prevention; practical accessibility requires providing an accessible verification alternative and clear instructions (see WCAG 2.1 and WAI guidance). For further reading: Google’s reCAPTCHA docs and W3C WAI accessibility guidance on CAPTCHAs.

Behavioral CAPTCHA systems (like reCAPTCHA v3) score users by observing interaction patterns — mouse movement, timing, scrolling, click rhythms, and other heuristics — to estimate whether someone is human. People who rely on assistive technologies (screen readers, switch controls, keyboard-only navigation, voice input) interact with pages in ways that differ from the heuristics these systems expect: they may tab through items quickly, not move a mouse, pause while a screen reader reads content, or trigger actions via keyboard commands or switches. Those legitimate differences can lower a behavior-based trust score, causing the system to flag them as suspicious. The result is higher friction or outright blocking for users with disabilities (extra challenges, forced CAPTCHA challenges, or denied submissions), even though they are genuine users — a classic false positive that disproportionately excludes assistive-technology users.

References: WCAG guidance and WebAIM discussions on accessibility and CAPTCHA; analyses of behavioral risk scoring (reCAPTCHA documentation).

Risk-based systems like reCAPTCHA v3 rely on signals from a user’s device and interactions to score whether they are human. Assistive-device setups — mobile screen readers, external switches, voice control, alternative input methods — change how users interact with a page and what signals are produced. Because these signals vary across devices, browsers, and assistive technologies, the same legitimate user can receive very different scores depending on their configuration. That unpredictability can cause false positives (a real user flagged as a bot) or false negatives (a bot scored as human), creating intermittent access barriers. In short: scoring that depends on fragile, variable interaction signals produces inconsistent, device-dependent outcomes that disproportionately harm people who rely on assistive technologies.

References: WCAG guidance on providing alternatives and WebAIM resources on CAPTCHA accessibility.

When CAPTCHA systems flag a user as risky, accessibility depends on what the site does next. Many sites treat a low score or failed automated check as an endpoint rather than a signal to offer accessible alternatives. Common implementation gaps that worsen exclusion:

• No accessible fallback: Sites often present only another visual or audio challenge instead of an alternative flow (e.g., help via phone, email verification, or human review) that works with assistive tech.
• Non-keyboard interactions: Fallback challenges require mouse dragging, precise clicks, or gestures that keyboard-only users and many motor-impaired users cannot perform.
• Poor ARIA and semantic support: Dynamic changes (new challenge, error messages) aren’t announced to screen readers because developers omit proper ARIA live regions, roles, or focus management.
• Time-limited flows without extension: Short timers or repeated retries without an option to extend or request help disadvantage users with slower interaction speeds.
• Inaccessible audio alternatives: Audio CAPTCHA options (when provided) are low-quality, unintelligible, or lack controls (play/pause, replay), and their UI isn’t labeled for assistive tech.
• Hidden “accessible” fields that break assistive tech: Invisible or CSS-hidden workarounds intended to help bots instead can confuse screen readers or create unpredictable focus order.
• Lack of human review or support path: No clear route to request manual verification or assistance (with privacy-protecting processes) leaves legitimately blocked users stranded.

Impact: These gaps turn a single verification check into a barrier to essential services (banking, healthcare, voting), increase cognitive and physical burden, and heighten legal risk under WCAG/ADA.

What to do: Implement risk-based, non-interruptive detection; provide multiple tested, assistive-technology-compatible fallbacks (keyboard-navigable flows, clear ARIA announcements, extendable timeouts); and offer a clear, privacy-respecting human support path for users who cannot complete automated challenges. For guidance, consult WCAG 2.1 (esp. 1.4.5, 3.3.2) and WebAIM best practices.

reCAPTCHA v3 and similar invisible, behavior-based systems build a risk score by observing user behavior across pages and sessions — mouse movement, typing timing, browser features, cookies, IP, and other signals. That continuous background tracking creates two problems for users with disabilities:

• Higher misclassification risk. Many assistive technologies (screen readers, alternative input devices, browser privacy extensions) and accessibility-friendly configurations change the usual behavioral and fingerprint signals these systems expect. As a result, legitimate users who rely on such tools are more likely to be flagged as suspicious and blocked or forced into additional, often inaccessible, challenges.

• Privacy and profiling harms. To generate reliable risk scores vendors often aggregate data across sites and sessions, creating detailed profiles of browsing behavior. This cross-site tracking disproportionately affects people who already rely on specialized tech (revealing disability-related patterns) and raises privacy concerns — especially when users must disable privacy protections to avoid misclassification.

Design implication: choose anti-bot methods that do not require pervasive cross-site profiling, or ensure options that are privacy-preserving and explicitly tested with assistive technologies so users with disabilities aren’t unfairly penalized. (See WCAG guidance and WebAIM on testing with assistive tech.)

When systems like reCAPTCHA v3 flag a visitor as “low-risk” or uncertain, many sites respond by presenting a secondary challenge (distorted images, timed puzzles, or audio CAPTCHAs). Two problems follow:

1. No clear, accessible feedback

• Users are rarely told why they were flagged or what the site expects them to do next in plain, accessible language. Screen readers and assistive tech often cannot access visual challenge content or the error/help messaging, leaving users confused.

2. Inaccessible remediation options

• The fallback challenges themselves are often unusable for people with visual, cognitive, motor, or hearing impairments (distorted text, precise clicking, poor-quality audio). Because the site treated the risk score as a gate rather than an invitation to offer an accessible path, users get trapped with no viable alternative.

Why this matters

• The combination of opaque risk decisions plus inaccessible fallbacks effectively blocks legitimate users from services (banking, healthcare, government) and can violate WCAG/ADA obligations. Better practice is to provide transparent, assistive-technology-friendly remediation (clear explanations, server-side checks, or non-interactive risk signals) and to test any alternative with real assistive tools (see WCAG 2.1 SCs and WebAIM guidance).

Tasks that require precise mouse clicks, dragging, or quick responses create barriers for users with limited fine motor control (e.g., from cerebral palsy, arthritis, Parkinson’s, stroke, spinal cord injury) because they rely on fast, accurate movements. Precise clicking of small targets, dragging sliders or matching puzzles, and time-limited challenges increase the chance of mistakes and repeated attempts, which can be exhausting, frustrating, and sometimes impossible without assistance. These interactions can also prevent people who use alternative input methods (switches, eye-tracking, head pointers, voice control) from completing the verification. Accessible alternatives include audio CAPTCHAs, longer time limits, keyboard-only controls, and invisible or server-side risk-based verification (e.g., device/browser signals or behavioral analysis) that avoid demanding motor tasks.

References: Web Content Accessibility Guidelines (WCAG) 2.1 (success criteria 2.1.1, 2.2.1) and W3C accessibility guidance on CAPTCHA alternatives.

Disproportionate exclusion

• Many CAPTCHAs rely on visual tasks (distorted text, image selection) or on fine motor/timed interactions that people with visual impairments, low vision, color blindness, motor disabilities, or cognitive impairments cannot reliably complete.
• Audio CAPTCHAs intended as alternatives are often low-quality, hard to parse, or incompatible with screen readers. Tasks that require precise mouse control or quick responses exclude users with tremors, limited dexterity, or assistive switches.
• As a result, affected users are more likely to be blocked from account creation, transactions, or accessing services — a disparity that is “disproportionate” because the barrier falls more heavily on people with disabilities than on the general population. (See WCAG guidance and accessibility research.)

Privacy concerns

• Many modern CAPTCHAs (e.g., reCAPTCHA) use behavioral analysis: they track mouse movement, typing patterns, device and browser signals, and sometimes IP or geolocation to infer humanness. This creates a substantial collection of personal and behavioral data.
• For people with disabilities, behavioral signatures (slower movements, use of assistive tech) can be distinctive and reveal sensitive information about health or disability status. That raises privacy and potential discrimination risks, especially when data are stored, shared, or linked to profiles.
• Users may be forced to disclose disability-related signals or to use third‑party services that log their interactions, undermining their privacy and autonomy.

References

• Web Content Accessibility Guidelines (WCAG) 2.1: guidance on CAPTCHA and alternatives.
• Research on accessibility of CAPTCHAs and reCAPTCHA privacy analyses (e.g., studies in ACM CHI/ASSETS; Google reCAPTCHA documentation).

CAPTCHAs that rely on distorted text, images, or visual puzzles create major barriers for people who are blind or have low vision. Problems include:

• Inaccessibility of visual challenges: Distorted text and image-selection tasks are unreadable or unrecognizable using screen readers or magnifiers.
• Poor or absent alternatives: Audio CAPTCHAs are often low-quality, brief, or heavily distorted and can be unusable for screen-reader users; some sites offer no alternative at all.
• Incompatibility with assistive technology: CAPTCHAs embedded in complex widgets or relying on mouse/touch interactions prevent keyboard navigation and screen-reader access.
• Usability and time costs: Solving accessible alternatives (when present) can require extra time, repeated attempts, or switching devices, creating frustration and exclusion.
• False accessibility assumptions: Automated “invisible” CAPTCHAs can still trigger visual challenges unpredictably, leading to inconsistent access for disabled users.

Design solutions: provide accessible alternatives (simple logical challenges, phone/SMS verification, accessible web authentication like WebAuthn), ensure CAPTCHA controls are keyboard- and screen-reader-compatible, and follow WCAG guidance (WCAG 2.1 Success Criterion 1.1.1 and 3.3.2, plus ARIA practices). References: WCAG 2.1 (W3C); WebAIM guidance on CAPTCHAs.

Using CAPTCHAs that are inaccessible to people with disabilities — such as visual CAPTCHAs without audio alternatives, time-limited puzzles, or controls that require fine motor skills — can effectively block equal access to websites and services. This exclusion can breach legal and standards-based obligations:

• ADA (Americans with Disabilities Act): Public-facing websites and digital services are increasingly interpreted by courts and regulators as places of public accommodation; inaccessible verification steps that deny service may constitute discrimination. See DOJ guidance and case law trends on web accessibility.
• WCAG 2.1 (Web Content Accessibility Guidelines) AA: WCAG requires alternatives for time-based, sensory, and motor-dependent tasks (e.g., 2.2.1 Timing Adjustable, 1.1.1 Non-text Content, 2.1.1 Keyboard). Requiring a CAPTCHA that cannot be completed via keyboard, screen reader, or without precise pointing can fail these criteria.
• Other laws/standards: Similar obligations appear in the EU Accessibility Act, UK Equality Act, and national regulations that adopt WCAG as the technical baseline.

Practical consequence: Users with blindness, low vision, deafness, cognitive impairments, motor impairments, or who use assistive technologies may be unable to verify and thus denied access to accounts, purchases, or information. To comply and be inclusive, provide accessible alternatives (e.g., accessible audio or logic puzzles, phone/SMS verification, risk-based invisible CAPTCHA, or pass-through authentication) and test with assistive technologies.

References: ADA guidance on web accessibility; WCAG 2.1 success criteria (1.1.1, 2.1.1, 2.2.1, and related).

CAPTCHAs can block essential services

• When CAPTCHAs are required to access banking, healthcare, government, or other critical services, people with disabilities (e.g., visual, cognitive, motor impairments) may be unable to complete them and thus be effectively denied access to important resources and time‑sensitive information. This creates a digital barrier to basic rights and necessities.

Audio CAPTCHAs and privacy risks in public

• Audio alternatives intended for blind or low‑vision users can expose sensitive information if they must be solved in public (e.g., on transit, in waiting rooms). The spoken challenge can be overheard, revealing private account or identity details or enabling others to complete the challenge fraudulently.

Biometric and behavioral data collection creates privacy risks

• Some modern verification systems record voice, face, typing patterns, mouse movement, or device sensors to distinguish humans from bots. Collecting and storing such biometric or behavioral data raises privacy and surveillance concerns: data breaches can expose sensitive identifiers, and continuous profiling can enable tracking, discrimination, or function creep beyond the original security purpose.

References for further reading

• W3C Web Accessibility Initiative: CAPTCHA and Accessibility Considerations
• Electronic Frontier Foundation: Privacy issues with biometric/behavioral tracking
• World Wide Web Consortium: Accessible Authentication techniques