Using it as an accessibility tool, and its blind spots

Two different subjects hide under "AI and accessibility", and this page covers both because they meet in one person: whether the product itself works with assistive technology, and what happens when the model becomes the assistive technology: describing images, simplifying documents, drafting for someone whose disability makes drafting expensive.

The first has documentation. The second has a structural catch that deserves to be stated plainly.

What the product documents

Claude Code ships a screen reader mode that "replaces its visual terminal interface with plain, linear text". Boxes, progress animations and in-place redraws become labelled lines that VoiceOver or NVDA read in order. "You can hold a full conversation, approve tool permissions, and review output end to end".

The details are considered rather than token: every message carries a searchable label (you:, claude:, tool:, Permission Required:), menus become numbered lists answered by typing a number, deleted words are announced, and a terminal bell rings when Claude needs you. Beyond screen readers, CLAUDE_CODE_ACCESSIBILITY keeps a visible cursor for magnifiers, prefersReducedMotion calms the animations, and dark-daltonized / light-daltonized themes exist for colour vision.

Two limitations the docs state themselves: the mode "doesn't turn on automatically when a screen reader is running"; it is opt-in via a flag, an environment variable or a setting. And some surfaces (attached background sessions) are not adapted. The accessibility page is the reference and it is current.

Where the model-as-aid genuinely helps

Real capabilities, not aspirations: describing an image or a chart, reading a PDF aloud in effect by extracting and restructuring it, simplifying dense text to a register that works for you, drafting when motor or cognitive load makes drafting the expensive part, and holding a conversation at whatever pace works.

For many people this is the difference between a task being possible and not. Nothing below argues otherwise.

The blind spot, stated honestly

Every verification technique this site teaches assumes you can check the output somehow — against the source, against the original image, against your own reading. The person using AI as an accessibility aid is often, by definition, the person who cannot.

A blind user cannot compare the image description against the image. That is why the description was needed. And the model cannot tell you how confident it is: a correct description and a plausible invention arrive in the same fluent voice. The usual advice — verify before relying — collapses precisely where reliance is the use case.

Two facts sharpen it. Vision has documented edges: what gets read from a file depends on format and page count, and nothing announces when visual content was skipped. And errors here are not uniform in cost. A wrongly described chart in a news article wastes a minute; a wrongly read medication label or dosage table is a different category, and the model does not know which one it is looking at.

Working with the blind spot

Not solutions, since the structural fact does not dissolve, but real mitigations.

Route by stakes. Fluid, low-cost material through the model; anything where an error harms (medication, finance, legal, safety instructions) through a verified channel — a human, or purpose-built assistive tooling with known failure modes.

Use redundancy where it exists. Asking twice in fresh conversations and comparing is a weak check, but it is a check available without sight of the original, and divergence is a real warning.

Ask for the seams. "Describe only what is legible and say what you cannot make out" produces more honest output than a bare "describe this", because it gives permission for the uncertainty the model otherwise papers over.

Keep the trusted channel warm. The failure mode of a good aid is that the human fallback quietly stops being available — automation bias with higher stakes.

What goes wrong

Treating the description as the image. It is a sample from a model, with everything that implies.

Uniform trust across non-uniform stakes. The convenience that is fine for a menu is not fine for a prescription, and the interface looks identical.

Assuming the product mode is on. Screen reader mode is opt-in. If the terminal output sounds like chaos, the mode is off, and turning it on is one flag.

Nobody reporting the gaps. The docs ask for exactly this: issues naming the assistive technology, OS and terminal. Assistive-tech users are a small share of testers, so each report carries unusual weight.

How to check it worked

For the product: turn on screen reader mode and confirm the first line announces it. For the aid: take one image or document you can verify (with a sighted colleague, a known original, purpose-built tooling) and compare the model's description against ground truth. That one calibration tells you what this model misses on your material, which is the only version of "verify before relying" available here, and worth repeating when models change.