Recording a Screen Reader Session — What You Actually Need to Capture

Recording a screen reader accessibility session

A screen recording of a screen reader session that only captures the visual display misses the entire point — the screen reader’s synthesized speech output is what actually needs to be recorded, and capturing that requires explicit setup that a default screen recording doesn’t handle automatically.

Capturing the screen reader’s audio is the entire challenge

Screen readers like NVDA, JAWS, or VoiceOver output synthesized speech as system audio — which means capturing it requires recording system audio alongside your screen, not just your microphone. Most default screen recording setups only capture microphone input, which captures your own voice but silently omits the screen reader’s output entirely.

The macOS system audio problem specifically

On Mac, system audio capture requires an additional audio driver — BlackHole being the most common free solution — since macOS doesn’t expose system audio directly to recording applications the way Windows does. Testing your audio capture before a real session confirms you’re actually getting the screen reader’s voice and not just a silent screen capture.

“A screen recording that only captures the visual display of a screen reader session misses the entire point — the synthesized speech output is the actual content being tested, and that requires explicit system audio capture setup, not just microphone recording.”

Narrate what you’re doing in addition to the screen reader’s output

Having both the screen reader’s audio and your own narration in the recording — “I’m now tabbing through the navigation menu” — gives someone reviewing the recording afterward a way to follow along even if the screen reader’s pronunciation of a specific element is unclear, similar to the dual-narration approach covered in our accessibility testing guide.

Test audio levels before the actual recording session

Screen reader output volume and your own narration microphone level need to be balanced — a screen reader running at full volume can drown out your own commentary, or vice versa. Checking the actual levels in a short test recording before the real session catches this before it ruins a longer capture.

Keep the recording at real navigation speed, don’t slow down for the camera

A screen reader user navigating at their actual normal speed produces more useful accessibility testing data than an artificially slowed-down recording meant to be easier to follow — the real navigation tempo is the point, not a demonstration pace adjusted for a hypothetical viewer.

Frequently asked questions

How do I capture screen reader audio in a screen recording?
Enable system audio capture in your recording software — on Mac this requires an additional audio driver like BlackHole, since macOS doesn’t expose system audio directly to recording applications by default.

Should I narrate during a screen reader recording or let the screen reader speak for itself?
Both — your own narration describing what you’re doing, alongside the screen reader’s output, gives reviewers more context, especially if the screen reader’s pronunciation of specific elements is unclear.