Accessibility Issues You Can Spot in Session Recordings (and the Ones You Cannot)
Session recordings reveal some accessibility barriers, such as small tap targets, zooming, keyboard traps, and low-contrast controls being missed. Learn what behavior to look for, what recordings cannot show, and how to combine them with proper accessibility testing.
Short answer: recordings show the behavior that accessibility barriers cause: pinch-zooming to read, missing a small button several times, tabbing through a page and getting stuck, or ignoring a control that is too faint to notice. They do not show what a screen reader announced, and they cannot confirm compliance with any standard. Use them to find and prioritise barriers real visitors hit, alongside automated checks and manual testing with assistive technology.
Table of Contents
- What Recordings Can Show
- Signals to Look For
- What Recordings Cannot Show
- A Combined Approach
- Privacy and Care
- Key Takeaways
What Recordings Can Show
Accessibility is often treated as a checklist run once. Recordings add something a checklist lacks: evidence of which barriers your actual visitors meet, and how often.
Many barriers also affect people with no disability. Low contrast is a problem in sunlight. Small tap targets are a problem on a bus. A keyboard trap affects anyone who prefers the keyboard. Fixes in this area tend to help everyone.
Signals to Look For
| Behavior in a recording | Likely barrier |
|---|---|
| Pinch-zoom before reading or tapping | Text or controls too small |
| Several taps near a button before one lands | Tap target too small or too close to another |
| Tapping the wrong adjacent link, then going back | Targets too tightly packed |
| No pointer movement, focus moving element by element | A keyboard user |
| Keyboard focus cycling within one area and never leaving | Keyboard trap, often in a modal or widget |
| Many tab presses to reach the main content | No skip link; long navigation first |
| Focus disappearing, then clicks elsewhere | No visible focus indicator |
| A visible control never used, while users hunt for the function | Low contrast, or it does not look interactive |
| Clicking on text that is not a link | Something looks interactive and is not (dead clicks) |
| A form error, then repeated submission with no change | Error shown by colour alone, or not noticed (error messages) |
| Timeout during a slow form | Time limit too short |
| Leaving at a captcha | An inaccessible challenge |
| Horizontal scrolling at zoom | Layout does not reflow |
| Abandoning a carousel or autoplaying section | Motion that cannot be paused |
| Hover-only menus unused on touch devices | Function unavailable without a mouse |
Tap target size is the easiest to confirm. A click heatmap on mobile showing a spread of taps around a small control, not on it, is strong evidence (click heatmaps). Guidance commonly recommends targets of at least 24 by 24 CSS pixels as a minimum, with larger being better for primary actions.
To find keyboard sessions, look for recordings with interactions and focus changes and no pointer movement. Watching one is instructive: you see the order in which your page is actually traversed, which is often not the visual order.
What Recordings Cannot Show
Be clear about the limits.
| Not visible in a recording | Why |
|---|---|
| What a screen reader announced | Replay captures the page, not assistive technology output |
| Missing alternative text | It has no visual effect |
| Incorrect headings, roles, and labels | These are in the markup |
| Whether a user has a disability | Not known, and should not be inferred |
| Users who could not get in at all | A visitor blocked at the first step leaves a short session with no clues |
| Colour contrast ratios | Needs measurement |
| Voice control and switch access problems | Rarely distinguishable |
| Captions and transcripts | Not a behavior signal |
The fifth row is survivorship bias in a serious form: the people most excluded are the least represented in your data (survivorship bias).
So recordings are a supplement. They are not an audit, and a site with no visible struggle in recordings can still be unusable with a screen reader.
A Combined Approach
- Automated checks. Browser tools and linters catch missing labels, contrast failures, and markup errors. They find a minority of real problems, and they find them cheaply.
- Manual keyboard test. Complete your main task with the keyboard alone. Can you see where focus is? Can you reach and operate everything? Can you leave every modal?
- Screen reader test. Go through signup or checkout with VoiceOver, TalkBack, or NVDA. Is each control announced with a name and role? Are errors announced?
- Zoom and reflow. Set the browser to 200% and 400%. Does content reflow without horizontal scrolling?
- Recordings and heatmaps. Look for the signals above on your key flows, to see which problems are frequent among real visitors.
- People. Testing with users who rely on assistive technology finds what nothing else does.
Recordings help most with prioritisation. An audit may list eighty issues. Behavior data shows which of them sit on the path to purchase and are being hit daily (prioritising fixes).
They also help with persuasion. A clip of a visitor missing a 20-pixel close button five times makes the case faster than a guideline number (presenting findings).
Quick fixes that recordings often justify:
- Larger tap targets with more spacing.
- A visible focus outline.
- Real
buttonandaelements in place of clickabledivs. - Labels on every form field (mobile form inputs).
- Errors in text, next to the field, not by colour alone.
- Modals that trap focus correctly and close with Escape.
- Text at a readable size without zooming.
- A pause control on anything that moves.
Privacy and Care
- Do not label individuals. A recording that shows keyboard navigation does not tell you about a person's health or disability. Do not record such inferences against a user.
- Health-related data is sensitive under privacy laws in many jurisdictions. Treat behavior analysis as aggregate, design-focused work.
- Keep masking on. Recordings should not expose what people type (masking).
- Legal obligations. Accessibility is a legal requirement in many places and sectors. Recordings do not demonstrate compliance. This is general information, not legal advice.
Unplug your mouse for ten minutes
Complete a signup or purchase on your own site using only the keyboard. It is the fastest accessibility test there is, and it usually finds something within the first minute.
Key Takeaways
- Recordings show the behavior barriers cause, not the barriers themselves.
- Zooming, missed taps, and stuck focus are the clearest signals.
- They cannot show screen reader experience or people excluded entirely.
- Use them to prioritise and persuade, alongside real accessibility testing.
Conclusion
A recording of someone struggling to tap a button is a small window onto a larger problem. Look through it, then do the proper testing to see the rest.
Frequently Asked Questions
Related articles
Stay in the loop
Get the latest insights on product analytics and user behavior delivered to your inbox.
