Hardware visibility for an accessibility audit

When you audit a website or app for accessibility, the device matters: screen size, scaling, input methods, and connection conditions can all affect what someone experiences. A hardware report can help you record the test setup, but it cannot tell you whether the product is accessible.

Use the report as supporting context, then test the actual interface with the relevant settings and assistive technology. These tips help you collect useful hardware details without treating them as an accessibility verdict.

Tips for documenting hardware in an accessibility audit

1. Capture a baseline on the device being tested. Open System Info on the computer or tablet used for the audit. It reports processor, graphics, screen, battery, and network details available to the browser. Record the date, browser, operating system, and the task you were testing alongside those details, so the report has useful context.
2. Keep browser hints separate from exact specifications. A browser may provide only a rounded hint about RAM, not the exact installed amount. For an exact figure, check Windows 11 at Settings › System › About or Task Manager › Performance › Memory. On a Mac, use Apple menu › About This Mac. Label the source of each value rather than mixing browser estimates with system-reported specifications.
3. Record the display setup, not just the screen size. Note the screen resolution and scaling used during the test, along with whether the person used one display or several. On Windows 11, check Settings › System › Display. On macOS, check System Settings › Displays. Scaling changes how large interface elements appear, so the same resolution can feel different on different screens.
4. Include the input method in your test notes. A keyboard, mouse, touchscreen, trackpad, switch interface, or other device can change how someone reaches controls. A system summary does not confirm that every key, button, touch area, or assistive input device works as expected. Test the controls people will use, and note whether the test was done with a keyboard alone, touch alone, or another input method.
5. Check accessibility settings separately from hardware details. A display specification does not show whether text enlargement, contrast options, captions, or a screen reader are enabled. On Windows 11, review Settings › Accessibility. On macOS, review System Settings › Accessibility. Record the settings relevant to the audit, but avoid changing a participant’s setup without their agreement.
6. Do not infer usability from processor or graphics details. A processor or graphics report can describe part of the test environment, but it cannot prove that a page will work well with a screen reader, keyboard navigation, magnification, or reduced motion. Performance also depends on the browser, open applications, power mode, and the page itself. Measure the actual behavior that matters instead of treating a hardware specification as a pass or fail.
7. Note battery and network conditions when they affect the test. A laptop on battery may use different power settings than it does while plugged in, and a slow or unstable connection can affect loading and interaction. System Info can report battery and network details that the browser can access. Treat those readings as a snapshot, not a full diagnosis of battery health or network quality.
8. Test a representative range of devices. One desktop report cannot represent a phone, tablet, or computer with a different screen and input setup. Choose devices based on who will use the product, then repeat key tasks on each type. Record differences in screen size, scaling, touch availability, and connected peripherals so another tester can understand how the setup changed.
9. Share only the details the audit needs. A screenshot of system information may reveal more than the report values you intend to discuss. Before sending it, review the image and remove unrelated personal or identifying details. In a written report, list only the hardware and settings that help explain a test result, and state when a value came from the browser rather than the operating system.

For repeatable results, keep the browser, display settings, and input method consistent between checks when possible. If you change one of them, note the change and rerun the same task, so you can tell whether the experience changed with the setup.