Diagnostic Methodology & Technical Limits

APtester uses standard W3C Web APIs to inspect peripheral behavior directly inside modern browsers. Here is an engineering breakdown of how each test functions, what metrics are measured, and the inherent boundaries of browser-based diagnostics.

1. Keyboard events and rapid-interval flags

APIs: KeyboardEvent.code, KeyboardEvent.key and performance.now(). The code value, such as KeyA or ShiftLeft, is a browser key-position identifier, not an unprocessed hardware scan code. The visual layout maps these identifiers to keycaps; virtual keyboards and OS-reserved shortcuts may not deliver the expected events.

Interval flag: For the same code, the current tester checks the interval from a previous keyup to a new keydown. A non-repeat event below the configured 40 ms threshold is flagged for review. Events marked repeat do not increment the chatter counter. This is a browser-event clue: intentional rapid tapping, OS behavior and browser scheduling can affect it. It cannot diagnose a damaged switch or certify key-to-screen latency.

Rollover: The simultaneous-key count describes keys received by this page in that combination. A missing key may reflect an OS shortcut, focus loss, layout mapping or device limitation. It does not certify universal NKRO.

2. Mouse buttons, intervals and scrolling

APIs: MouseEvent.button and WheelEvent. Button indices represent primary (0), middle (1), secondary (2), back (3) and forward (4) events delivered to the test area. Settings or reserved navigation can change what arrives.

Rapid-click flag: The tester compares successive mousedown timestamps for the same button, not release-to-press time. An interval below the configured 80 ms threshold receives a possible-anomaly flag. A deliberate fast click sequence can also trigger it. Reproduce the symptom slowly, compare another browser or device, and do not replace hardware solely because of the flag.

Scroll: Direction and normalized wheel deltas describe browser events, not physical wheel distance, sensor DPI, USB polling or electrical latency.

3. Screen inspection and animation timing

APIs: Fullscreen API and requestAnimationFrame. Solid colors help you visually inspect possible pixel defects or uneven lighting. Clean the screen gently first and compare colors; the page does not locate or repair physical pixels automatically.

Refresh estimate: The meter samples animation-frame timestamps. Display synchronization, variable refresh, browser load and background-tab throttling can influence the result. It is a browser frame-delivery estimate, not a certified panel refresh measurement or input-latency test.

4. Speaker tones and relative microphone level

Speaker: AudioContext, OscillatorNode and StereoPannerNode generate a selected sine tone locally and route it left, right or center. The frequency slider selects one tone at a time; there is no automatic sweep. Start at low system volume, stop if uncomfortable, and do not use loud or extreme tones to diagnose hearing.

Microphone: After your permission, an AnalyserNode supplies time-domain samples with getByteTimeDomainData. Samples are normalized around 128, their root mean square (RMS) is calculated, and the displayed approximate level uses 20 × log10(RMS), clamped to -60 to 0 dB. This is a relative digital signal level, not calibrated sound pressure (dB SPL). Input gain, automatic gain control and browser processing can change it.

Local monitoring: Microphone samples are processed locally by the tool, not recorded or uploaded by APtester. Loopback may introduce delay and feedback; use headphones and low volume. The meter cannot certify a microphone, measure physical latency or prove hardware clipping.

5. How to interpret and check this guidance

This methodology documents the current event and audio calculations rather than a hardware-health verdict. The technical reference points are the W3C keyboard code specification and the Web Audio time-domain analyser specification. Those standards describe browser interfaces, not an APtester certification.

For a reproducible report, keep the page focused, note the browser version and device settings, repeat the same action, then compare another browser or known-working device before making a repair decision. Report a misleading explanation or a mismatch between the interface and this page through Contact. Page-level advertising and analytics are separate from diagnostic processing; see Privacy.