# Manual testing

Manual testing is where a person drives the product the way a disabled user would, with a keyboard, a screen reader, zoom, and other assistive technology. It is the tier that catches the AI-specific failures, because streaming, focus, and live regions only reveal themselves when something is actually reading the page.

## Key points

- Manual testing catches the AI-specific failures, since streaming, focus, and live regions only reveal themselves when something reads the page.
- Drive a whole task with the keyboard alone, watching for unreachable controls, jumping focus, and fake links.
- Listen with more than one real screen reader, since NVDA, JAWS, and VoiceOver differ.
- Sample across many outputs, including a long answer, an error, a refusal, and one with a table or code.
- Cover the basics too, like zoom, text spacing, reduced motion, and contrast on generated content.

## Drive it with the keyboard alone

Unplug the mouse and complete a whole task. For a chat product that means typing a prompt, sending it, stopping a long answer, moving through the reply, and opening or downloading anything it produced. Watch for controls you cannot reach, focus that jumps to the top when a reply arrives, and results that turn out not to be real links. A sighted mouse user will never notice these, and a keyboard user is blocked by them.

## Listen with a real screen reader

Automated tools cannot tell you how output sounds, so use real screen readers, and use more than one because they differ. NVDA and JAWS with Chrome or Firefox on Windows, and VoiceOver with Safari on macOS, cover most users. Listen to a full streamed answer and check that it is announced in a way you can follow, that it does not repeat or talk over itself, and that focus stays put. This is the behavior a checker [cannot simulate](https://blog.vararu.org/lying-a11y-tools).

## Sample across many outputs

Because the output is generated, test more than one. Try a long answer, a short one, an error, a refusal, and an answer that contains a table or code, since these often render through different paths. One good transcript is not evidence that the next one will work. This is the sampling idea from [Methodology](https://artificia11y.ds.house/testing/methodology/) applied by hand.

## Check the rest of the basics

Manual testing also covers zoom to 200 percent and 400 percent, increased text spacing, reduced motion, and color contrast on generated content such as charts. Walk the page by its headings and landmarks to confirm the generated content is actually navigable, not just visually formatted.

> [!ACCESSIBILITY-SPECIALIST]
>
> Build a small output matrix and walk each cell with a keyboard and a screen reader. The cells that matter most for AI are a long answer, a short answer, an error, a refusal, and an answer with a table or code, because each can render differently. Note how streaming is announced, where focus lands when a reply arrives and finishes, and whether the stop control works mid-stream. Record the model version with your findings, since the next version may behave differently.

> [!SELF-ADVOCATE]
>
> A manual walk with a screen reader surfaces things a checklist never will, like a reply that floods you with announcements, a stop button you cannot reach, or a finished answer that gives no signal it is done. When you report one of these, the most useful details are the screen reader and browser you used, the exact prompt, and what you expected to hear versus what happened.

## Further reading

- Vararu on [why automated checkers miss real assistive-technology behavior](https://blog.vararu.org/lying-a11y-tools).
- Matthew Deeprose on [using AI to assist accessibility work](https://matthewdeeprose.github.io/harnessCopilot__transcript.html), with human review.