Support diagnostics for an accessibility audit

You have found an accessibility problem, but support asks for more details. A useful report needs more than a device model: it should say what you were trying to do, which browser and assistive settings were in use, and what the hardware test showed.

TooLab's browser tests can help check a keyboard, screen, touchscreen, camera, or other device. They do not grade accessibility or replace testing with your screen reader, magnifier, captions, or other assistive technology. Use them as focused evidence alongside your own observations.

Collect useful diagnostics

1. Write down the task and the exact failure. For example: “With VoiceOver on, pressing Tab moves past the Save button without announcing it.” Note what you expected, what happened, and whether it happens every time. Avoid including names, account details, or private page content.
2. Open System Info on the device where the problem occurs. Note the relevant processor, graphics, screen, battery, or network details shown. The tool reports what the browser can access, so some fields may be missing or approximate.
3. Check the browser environment with Browser Info. Note the browser version and engine, plus any permission or feature information that relates to the problem. A browser may limit what it can report.
4. Run the specific hardware check that matches the symptom. Use Keyboard Test for missed key input, Display Test for visible screen issues, or Touch Screen Test for missed or merged touches. For a broader hardware check, Test Everything runs tests step by step and gives a report.
5. Repeat the original task with the same browser, assistive technology, and settings. Record whether the problem still occurs and whether the hardware test changes your understanding of it. A passing hardware test does not rule out an accessibility or software problem.

Test the device that shows the issue, not a different computer with similar specifications. If it happens only with a particular keyboard, headset, monitor, or connection, leave that device connected during the check and include it in your notes.

What the results mean

The relevant hardware test shows the expected input or output

If every key registers, the display patterns look correct, or touch points appear where you tap, the tested hardware path is responding in the browser. The issue may still be in the website, application, browser, operating system, or assistive technology. Include the test result, but keep the original task description at the center of your report.

The test misses an input or shows an unexpected result

This is useful evidence of a possible hardware, connection, or browser-input problem. Repeat the test once, then reconnect the device or try another port if practical. Note the exact key, screen area, or action that failed rather than reporting only that the test did not work.

A test or feature is unavailable

That does not prove the hardware is broken. Browser permissions, the device, or the browser itself can limit access. Some features work only in certain browsers, and camera or microphone tests ask for permission before use. Record the browser and the message shown, then check permissions or try a supported browser if appropriate.

The hardware check passes, but the accessibility problem remains

Keep investigating the software path. A keyboard test can confirm that keys register, for example, but it cannot confirm that a website's focus order is sensible or that a screen reader announces each control correctly. Share a short, privacy-safe reproduction and the assistive technology settings used.

Make the report easier to act on

1. Separate facts from guesses. State the action and observed result first. Say “the screen reader did not announce the button” rather than assuming the browser or screen reader is at fault.
2. Record the assistive setup. Note the screen reader, magnification, speech, captions, keyboard navigation, or other setting relevant to the task. On Windows 11, review Settings › Accessibility and the relevant page, such as Narrator or Magnifier. On macOS, review System Settings › Accessibility, such as VoiceOver or Zoom. Do not change settings just to create a report unless support asks you to.
3. Include only relevant system details. Add the operating system, browser version, connected device, and test result that help reproduce the issue. Skip unrelated hardware details and identifiers.
4. Describe repeatability. Say whether the problem happens every time, only after a certain action, or only on one device. If it changes, note the conditions rather than averaging the outcomes.
5. Protect private information. Before sharing a screenshot or diagnostic report, check it for names, email addresses, open tabs, network details, or other information the recipient does not need. Share it through the support channel you trust.

Know what a browser test cannot confirm

A browser-based hardware check can show whether the browser receives keyboard, touch, camera, or display information. It cannot determine whether a website follows accessibility guidelines, whether every control works with a screen reader, whether captions are accurate, or whether content is understandable. Those checks require using the relevant assistive technology and evaluating the actual page or app.

Keep the task description and the user's experience in the report, even when a hardware test finds a fault. That gives support both the symptom and a focused clue about where to investigate next.