Screen recording for accessibility audits in 2026: keyboard nav, screen readers, focus states

Accessibility bugs are the hardest bugs to communicate in text. "The focus ring disappears when you Tab to the third menu item" — fine, but on which Tab, in which order, from which starting point, in which browser, with what assistive technology? Screen recordings collapse the entire diagnostic chain into 15 seconds. The catch is that a11y recordings need things most product recordings don't: audio capture of screen-reader output, frame-accurate cursor and focus capture, and a high enough resolution that focus rings and aria-live region changes are actually visible. This post is the 2026 a11y-audit recording workflow we use — what to capture, what to leave out, and the small set of habits that turn a video into evidence a developer can act on.

TL;DR — the a11y-recording rules

The patterns that separate effective a11y recordings from frustrating ones:

1. Record at 1080p / 60 fps minimum. Focus rings and live-region updates often flash for less than 200ms — at 30 fps you might capture two frames of the focus state and miss the actual transition.
2. Audio on, always. Screen reader output is the audio track. Without it, half the bug is missing.
3. Record only the keyboard path for keyboard bugs. Don't switch to the mouse mid-recording — it breaks the demonstration.
4. Include the assistive technology name and version in the ticket body. A screen reader bug reproduces on VoiceOver but not on JAWS, or vice versa. Tell the reviewer which.
5. Use a real assistive tech, not a developer-tool simulator. Chrome DevTools' "rotor" simulator is helpful for development but doesn't reproduce real screen-reader behavior.
6. Record at the OS level for screen-reader audio. ClearRec's Chrome Tab audio capture works fine for tab-rendered audio, but OS-level recorders like macOS Cmd+Shift+5 or Windows Game Bar are sometimes better for capturing actual VoiceOver/NVDA/JAWS output, which doesn't always route through the tab audio path.

The rest of this post is the why and how for each.

Why a11y bugs need video more than other bugs

A bug-report video closes a ticket faster than text by collapsing the four standard questions (what did you click, what happened, what was expected, is it reproducible) into a single artifact. For accessibility bugs, the gap is even larger because:

• The bug often has no visual signature. "Tab order skips this button" produces no error message, no broken UI, no obvious symptom. Without a recording showing the tab path, the developer is reproducing from prose.
• The reproduction requires specific assistive tech. A bug that fires under VoiceOver on Safari but not under TalkBack on Chrome is two different bugs in a triage queue. A recording captures both the screen and the audio output, eliminating the "we couldn't reproduce" loop.
• The timing matters. Focus rings, live region announcements, and dynamic content updates happen in milliseconds. A recording captures the timing; text descriptions don't.
• Compliance documentation often requires evidence. WCAG audits, Section 508 reviews, and EN 301 549 conformance reports usually require visual evidence of failures. A screen recording is the canonical form.

The QA-engineer post argued that a bug report with a video closes ~2× faster than text-only. For a11y specifically, the multiplier is closer to 3-4× because the bug-pattern-recognition cost is so much higher without the visual.

The five recording targets for a11y work

Each accessibility-bug category benefits from a slightly different recording configuration. Here's the matrix:

The two patterns to note:

• For screen-reader bugs, OS-level capture beats Chrome Tab capture because some screen readers (NVDA, JAWS, VoiceOver) speak through system audio paths that don't always route into Chrome's tab audio. Capture at the OS level to be safe.
• For focus-indicator bugs, the highest resolution available is the right call — focus rings can be 2px wide; downscaling to 720p hides them.

Keyboard navigation: the recording everyone gets wrong

A common a11y testing path: load the page, hit Tab repeatedly, observe whether focus visibly moves through the page in the right order. Recording this correctly requires three small habits.

Habit 1: Move the mouse cursor out of the way before you start

A visible mouse cursor implies "user is clicking" — which contradicts the keyboard-only narrative the recording is supposed to demonstrate. Park the cursor in a corner of the screen before starting the recording. Better: hide the cursor with the OS-level cursor-hide preference if your tool supports it.

Habit 2: Hit Tab slowly enough to be watchable

A natural impulse is to tab through 20 items in 3 seconds. The viewer can't see the focus transitions at that pace. Wait ~1 second on each focus state so the reviewer can read each new focus indicator. The recording becomes 20 seconds long; that's the right shape for an a11y audit.

Habit 3: Verbalize (or text-overlay) the expected vs actual focus

The recording shows what happens. It doesn't show what should happen. If the focus skips an item, the reviewer might assume that's the design. Pair the recording with explicit text in the ticket: "At 0:08, focus jumps from the third nav item directly to the search field, skipping the fourth nav item entirely."

If you record with mic-on narration, you can speak this annotation during the recording. For most a11y workflows, leaving the mic off and relying on the ticket body is cleaner.

Step-by-step keyboard recording workflow

The full path:

1. Open the page in ClearRec's Chrome Tab mode.
2. Set quality to High (1080p / 60 fps / 10 Mbps). 60 fps matters here — focus rings can transition in <100ms.
3. Microphone off (unless you're narrating the expected behavior).
4. Tab audio off (this isn't an audio bug).
5. Park the mouse cursor at the bottom of the screen.
6. Start recording.
7. Wait 2 seconds of dead air to give the trim editor a cut point.
8. Hit Tab. Wait ~1 second. Note the focus state visually.
9. Hit Tab again. Wait. Continue through the tab order you're auditing.
10. When you hit the bug (focus skip, focus trap, invisible focus), wait an extra 2 seconds with the broken state visible.
11. Stop.
12. Trim, export MP4 (1080p / 60 fps captures the focus transitions cleanly).

For a focus-trap bug specifically (Tab gets stuck on one element or cycles in a sub-region), record at least three Tab presses after the trap fires so the reviewer can see the looping behavior, not just the trap entry.

Screen reader recordings: the audio is the bug

Screen reader bugs (wrong label announced, missing aria-label, button announced as "button" with no description, live region not announcing) live entirely in the audio. The visual side of the recording is mostly secondary.

The tooling chain by platform

• macOS: VoiceOver (built-in). Activate with Cmd + F5. Output routes through system audio.
• Windows: NVDA (free, nvaccess.org) or JAWS (commercial). Output routes through system audio.
• Linux: Orca (free, built-in on most distros). Output routes through PulseAudio/PipeWire.
• iOS: VoiceOver. Triple-click side button after enabling in Settings → Accessibility.
• Android: TalkBack. Volume-up + volume-down hold after enabling in Settings → Accessibility.

For Chrome desktop recordings of screen-reader behavior, the audio path is the critical decision.

Audio capture for screen-reader bugs

Three options, in order of reliability:

Option A: OS-level recording with system audio capture (most reliable)

• macOS: Cmd + Shift + 5 → Record (full screen or selection). Click Options → Microphone Off → Built-in Output. macOS allows screen recording to capture the system audio, including VoiceOver, but you need to grant the permission under System Settings → Privacy & Security → Screen & System Audio Recording.
• Windows: Game Bar (Win + G) → Capture Widget → Start Recording. Captures system audio including NVDA/JAWS by default.
• Linux: SimpleScreenRecorder or OBS Studio configured to capture from PulseAudio's monitor sink. Captures Orca output.

Option B: ClearRec with Screen capture + system audio (works on supported platforms)

ClearRec's Screen capture mode supports system audio on macOS 14+ and Windows 10/11 where the OS exposes the system-audio toggle. On supported platforms, system audio includes screen reader output. The advantage: you don't switch tools mid-audit.

Option C: Chrome Tab capture (works only for tab-rendered TTS, not for OS screen readers)

If the audio comes from a web-based TTS engine running inside the tab (e.g., a JavaScript text-to-speech library), Chrome Tab capture with Share tab audio works. If the audio comes from a true OS-level screen reader (VoiceOver, NVDA, JAWS), the tab audio path doesn't capture it. This is the #1 source of confusion for first-time a11y recorders.

For most real a11y audits, Option A (OS-level recording) is the right choice because real screen readers don't route through Chrome's tab audio. ClearRec covers the visual part of the recording cleanly via Screen capture, and on supported platforms also captures system audio — but verify with a 10-second test recording before committing to a 30-minute audit.

Verifying the audio is in the file

Critical step that many people skip: after stopping the recording, play it back with headphones on before sharing. If the screen reader audio isn't audible in the playback, you've recorded a silent video of someone tabbing through a page. The video is useless without the audio for a screen-reader bug.

Focus indicator bugs: the resolution argument

A focus ring is often 2-3 pixels wide. At 1080p, a 2px ring is barely visible in the recording; at 720p, it can disappear into the JPEG noise of compression. For focus-indicator bugs, record at the highest resolution your hardware supports.

ClearRec's Ultra tier (1440p / 60 fps / 20 Mbps) or Insane tier (4K / 60 fps / 50 Mbps) is the right choice for these recordings. The file sizes are larger (~150 MB and ~370 MB per minute respectively) but the focus rings are actually visible.

Three patterns specific to focus-indicator captures:

Pattern 1: Capture both the "should have ring" and "shouldn't have ring" states

A focus-indicator bug isn't just "the ring is missing on this button". It's "the ring is missing on this button while it's present on that button". Show both in the same recording — focus the button that does have a ring, then focus the one that doesn't. The contrast is the bug.

Pattern 2: Pair the recording with a still frame

A 60-fps recording of a 200ms focus transition contains the data, but the reviewer has to scrub to find the right frame. Pair the recording with a still-frame screenshot taken at the moment of the bug. Use ClearRec's editor to pause on a specific frame, then screenshot. The pair (video + screenshot) gives the reviewer both timing context and pixel-perfect evidence.

Pattern 3: Include the CSS focus selector in the ticket

The recording shows the bug; the CSS shows the cause. After recording the focus-indicator bug, open DevTools, inspect the broken element, and copy the actual :focus / :focus-visible rules from the Styles panel into the ticket. The developer can fix the issue from the recording + CSS without re-running the entire audit.

Reduced motion: a frame-rate specific case

The prefers-reduced-motion media query is one of the most-violated accessibility features in 2026. Sites that ignore it animate carousels, parallax, transitions, and entrances even when the user has explicitly requested reduced motion at the OS level.

Recording a reduced-motion violation requires:

1. Enable reduced motion at the OS level. macOS: System Settings → Accessibility → Display → Reduce Motion. Windows: Settings → Accessibility → Visual Effects → Animation Effects off.
2. Open the page in Chrome.
3. Verify the OS setting propagated to Chrome: chrome://flags/#enable-experimental-web-platform-features enabled, or open DevTools console and check window.matchMedia('(prefers-reduced-motion: reduce)').matches returns true.
4. Record at 60 fps (ClearRec High or Ultra tier). The bug is animation that shouldn't be playing — you need 60 fps to capture the unwanted motion clearly.
5. Scroll the page slowly. Reduced-motion violations usually fire on scroll-triggered animations.
6. Pair the recording with the OS setting screenshot to prove the setting was actually on.

The OS setting screenshot is critical: developers triaging the bug will check whether the user actually had reduced-motion enabled. Including the screenshot pre-empts the "are you sure it was on" question.

Touch target sizing on mobile

For mobile a11y audits where you're checking touch target sizes (WCAG 2.5.5 requires 24×24 CSS pixels minimum, 44×44 is the recommendation), Chrome DevTools' device emulation gives you the right testing surface but the recording approach is a bit different.

The workflow:

1. Open Chrome → DevTools → Toggle Device Toolbar (Cmd+Shift+M / Ctrl+Shift+M).
2. Pick the device profile (iPhone 15, Pixel 8, etc.).
3. Open the page being audited.
4. Use Chrome's "Show ruler on hover" feature to measure touch targets visually.
5. Record with ClearRec at Ultra tier — the emulated mobile screen is small (typically 390×844 or 412×915), and you want enough resolution that the measurement values in the DevTools rulers are readable.

For real-device mobile recording (the more rigorous a11y approach), record on the device itself: iOS Control Center → Screen Recording, Android Quick Settings → Screen Record. Then transfer the file to your laptop for ticket attachment.

What the developer needs alongside the video

A great a11y bug-report video is paired with a great a11y bug-report body. The template:

**Summary**: <one line — what's broken from an a11y perspective>

**Assistive technology used**:
- Screen reader: <VoiceOver / NVDA 2026.1 / JAWS 2026 / TalkBack / etc.>
- Browser: <Chrome 142 / Safari 17 / Firefox 130>
- OS: <macOS 15.4 / Windows 11 23H2 / iOS 18 / Android 14>
- Other AT: <Switch Control, Voice Control, etc., if applicable>

**OS accessibility settings active**:
- <Reduce Motion: on>
- <Increase Contrast: off>
- <VoiceOver: on>

**Steps to reproduce**:
1. <step>
2. <step>
3. <step>

**Expected** (per WCAG <criterion>): <what should happen>
**Actual** (visible in the attached video): <what happens>

**WCAG criterion**: <e.g., 2.4.7 Focus Visible, 4.1.3 Status Messages, 1.4.13 Content on Hover or Focus>
**Severity**: P0 / P1 / P2 — <one-line justification anchored to user impact>

**CSS focus rules** (for focus bugs):
\`\`\`css
.button:focus { outline: none; }   /* the cause */
\`\`\`

**Video**: see attached `a11y-<feature>-<symptom>-<browser>-<at>.mp4`

The "Assistive technology used" section is the part that's almost always missing from a11y bug reports filed by non-a11y-specialists. Without it, the developer either reproduces with the wrong AT (waste) or asks for clarification (round-trip).

File-size and tracker considerations

A11y recordings are typically longer than bug-report recordings — keyboard-nav audits run 20-60 seconds, screen-reader bug demonstrations can run 60-90 seconds. At ClearRec's High tier (1080p / 60 fps / 10 Mbps), expect:

For Jira Cloud's 10 MB attachment cap, this is going to bounce. Two paths:

• Drop to 1080p / 30 fps / 5 Mbps (Medium) if the bug doesn't depend on >30 fps motion. Halves the file size; for keyboard-nav recordings without time-sensitive focus transitions, this is usually fine.
• Host the recording on a separate tracker that accepts larger attachments (Linear's 100 MB, TestRail's 256 MB) and link from the Jira ticket if your team's process allows it.

For focus-indicator bugs where 60 fps is genuinely necessary, the High-tier file size is the right trade-off; lobby your admin to raise the Jira cap (see the tracker workflow guide).

Tools and the recording chain in 2026

A typical a11y-audit-recording stack:

• Browser: Chrome (Lighthouse + DevTools accessibility panel + axe DevTools extension).
• Assistive technology: VoiceOver (macOS) / NVDA (Windows) / JAWS (Windows) / TalkBack (Android) / VoiceOver (iOS) / Orca (Linux).
• Auditing tool: axe DevTools, Wave, Lighthouse, accessibility-checker — they catch the things a recording would otherwise have to demonstrate.
• Recorder: ClearRec (or OS-level recorder) for the recording layer.

A common workflow: run axe DevTools to identify the categorical issues, use ClearRec to record the specific reproductions, attach the recordings to the bug reports filed against each axe finding. The recordings become the proof for the categorical findings.

Frequently asked questions

Q: What's the best screen recorder for accessibility testing in 2026? For Chrome-tab-based audits without screen-reader audio: ClearRec works fine. For audits that need to capture screen-reader audio: an OS-level recorder is more reliable than a browser-tab recorder, because OS screen readers don't always route through Chrome's tab audio path.

Q: How do I record a screen reader along with the screen? On macOS: Cmd + Shift + 5 → Record → Microphone Off (system audio is captured by default on macOS 14+). On Windows: Game Bar with audio on. Then attach the resulting file to the bug ticket. Verify with playback that the audio actually captured before sharing.

Q: Why can't I hear the screen reader in my Chrome Tab recording? Most screen readers (VoiceOver, NVDA, JAWS) speak through system audio paths that don't route into Chrome's tab audio capture. You're recording the tab visually but the screen reader audio is going to a different audio sink. Switch to Screen capture mode (with system audio enabled) or use an OS-level recorder.

Q: What frame rate do I need for focus-indicator recordings? 60 fps minimum. Focus transitions can happen in 100-200ms; at 30 fps you capture 3-6 frames of the transition, often missing the actual moment. At 60 fps you capture 6-12 frames, which is enough to scrub through and identify the bug.

Q: Is it accessible to send an a11y bug as a video? A video is a visual artifact, which is a fair concern when reporting bugs about visual accessibility. The mitigation: always pair the video with a structured text description (as in the template above) — the text is the accessible alternative, and the video is supplementary evidence for sighted reviewers. The developer is the audience, not an end user.

Q: How do I record keyboard navigation without the mouse cursor distracting? Park the cursor in a corner before starting the recording. On macOS, you can also use the "Hide Cursor" feature in some apps. The cursor's visibility in a keyboard-nav recording undermines the "this is a keyboard-only audit" framing.

Q: Should I narrate the recording with my voice? Usually no, for accessibility audits. Narration competes with screen-reader audio (which is the actual bug subject) and can confuse the playback. Use text in the ticket body for context; let the recording be the evidence. The exception: complex multi-step bugs where narrating "now watch what happens at 0:15" is genuinely useful.

Q: How long should an accessibility recording be? For a single bug: 20-60 seconds. For a flow audit (multiple bugs through a checkout flow, say): up to 5 minutes — but break it into multiple per-bug recordings before filing. A single 5-minute file with 4 bugs in it is harder to triage than 4 separate 20-second files.

Q: What's the WCAG criterion most commonly violated in 2026? In our experience auditing dozens of sites: 1.4.3 Contrast (Minimum) (color contrast failures), 2.4.7 Focus Visible (missing focus rings), 4.1.3 Status Messages (live region failures), and 1.4.13 Content on Hover or Focus (tooltips that can't be dismissed or that disappear on hover). A handful of common issues account for most of the bugs.

Q: Can axe DevTools record a video automatically? No — axe finds the issues; you record the reproductions separately. The combination (axe findings + recorded reproductions) is the canonical a11y bug-report pair.

Q: How do I record on a Chromebook for accessibility? ChromeOS's native screen recorder works. ChromeVox is built into ChromeOS as the system screen reader; system audio capture in the native recorder includes ChromeVox output. See the Chromebook recording guide for details.

The summary

A11y recordings need three things that general product recordings don't: high frame rate (60 fps for focus transitions), audio from the right source (OS-level for screen readers, not tab audio), and a paired ticket body that identifies the assistive technology and WCAG criterion. Get those three right and the recording becomes the canonical evidence form for the bug.

The recording itself is mechanically simple: ClearRec's Screen capture mode at Ultra or High tier, system audio on for screen-reader bugs, microphone off for keyboard-nav bugs. For tab-rendered content, Chrome Tab capture is fine; for real screen-reader output, OS-level recording is more reliable.

If you want the workflow with no friction, install ClearRec from the Chrome Web Store and use it alongside your OS-level recorder for screen-reader audits. The MP4 lands in your Downloads folder; pair it with the ticket template; the bug becomes actionable evidence.

See also

• Screen recording for bug reports: a developer's complete guide — the broader bug-report framework that a11y extends.
• Screen recording for QA engineers — workflows that scale — for QA-side a11y testing within a larger test suite.
• Screen recording for Notion, Linear, and Jira tickets — file-size strategy for the per-tracker caps.
• How to record a Chrome tab with audio in 2026 — the audio-capture mechanics, with the caveat about OS screen readers.
• How to compress a screen recording without losing quality — for fitting 60 fps focus recordings under tight attachment caps.
• Screen recording on Chromebook in 2026 — for ChromeOS-specific a11y workflows with ChromeVox.
• Privacy-first screen recording — what local-first actually means — why a11y recordings of internal tooling shouldn't leave the device.
• The complete guide to ffmpeg.wasm in 2026 — the engine running the local trim/export.
• Quality tiers — the six presets, with High and Ultra being the a11y recommendations.