How to record accessibility problems in a web interface
Capture a clear browser recording of an accessibility problem, then add steps, expected behavior, and privacy-safe details so a team can reproduce it.
A web page may be hard to use because focus is difficult to see, keyboard navigation gets stuck, text disappears when enlarged, or a screen reader gives confusing information. A short recording can show what happened, but it works best when someone else can repeat the same steps.
Use TooLab's Screen Recorder to capture a screen, window, or browser tab, with optional sound, microphone, and camera. It runs in a desktop browser, not on phones. The recording stays on your device.
Record the problem
- Open the Screen Recorder on the computer where the problem occurs. Choose a browser tab or window if that shows the full issue; choose the screen if you need to show switching between windows or settings.
- Prepare the page before recording. Close unrelated tabs and notifications, and use a test account or example data if possible. Note the page, browser, device, and any settings that might affect the result.
- Start capture with the recorder's controls and choose the source you want to share in the browser's screen-sharing prompt. Enable the microphone if you plan to narrate. Enable sound only if audio is part of the issue, and grant the requested browser permissions.
- Show the starting point, then reproduce the problem at a steady pace. For a keyboard issue, keep your hands on the keyboard and pause briefly after each key press so the focus change is visible. For a visual issue, keep the page at the zoom level and window size where the problem appears.
- Finish the capture and review the recording before sharing it. Check that it includes the beginning of the steps, the problem itself, and enough context to understand what you were trying to do.
A short clip is usually easier to review than a long recording. If the issue takes several minutes to appear, capture the setup and the moment it occurs, then write down how long you waited.
What the recording can show
A visible focus or layout problem
A recording can show a missing focus indicator, text that overlaps at larger zoom, a control that moves off screen, or a menu that covers important content. Include the page width and zoom level in your notes. These conditions can change how the interface looks, so the clip alone may not explain why it happens.
A keyboard navigation problem
Show where you begin and which keys you press. If focus skips a control, moves in an unexpected order, or gets trapped in a section, pause when it happens and continue just enough to show whether you can get out. Avoid using the mouse during this demonstration because it can move focus and make the sequence unclear.
A screen reader or other assistive technology problem
A video may show the page but not the information a screen reader announces. If the selected capture source does not include the screen reader's speech, narrate what you hear or add the exact announcement in the written report. Name the screen reader and its settings when you know them. Do not assume the recording proves what assistive technology announced.
A problem that happens only sometimes
One clip shows one occurrence, not how often it happens. If the issue is intermittent, record each attempt or note the number of attempts and the conditions. Include whether it occurs after a reload, after signing in, or at a particular screen size.
Include enough detail to reproduce it
Send the recording with a short written description. A useful report answers four questions:
- Where did it happen? Give the page or feature name and, if safe, the page address. State the browser and operating system.
- What did you do? List the steps in order, including keys pressed, controls selected, and whether you used a mouse, touch, or assistive technology.
- What did you expect? Describe what you thought should happen, such as focus moving to the next control or a label being announced.
- What happened instead? Describe the visible or spoken result, when it occurred, and whether you could continue.
Include relevant conditions such as browser zoom, window size, page language, or whether a feature was enabled. Keep the report factual. A recording can document a barrier, but it usually cannot identify the code causing it or establish by itself that a specific accessibility standard has been violated.
Protect private information before sharing
A capture can show names, messages, account details, browser bookmarks, or notifications even when they are not part of the problem. Reproduce the issue with sample content where possible, and close private pages before you begin. Do not record passwords, payment details, or another person's information. If the issue requires a real account, check the full clip before sending it and avoid sharing any section that exposes sensitive data.
Keep the original recording somewhere secure, and share it only with people who need it to investigate the interface. If you cannot demonstrate the problem without exposing private information, send a written description and ask for a safe way to report it.
