Test a new keyboard with a browser event checklist

Originally published on KeyboardTester.click. Adapted by the KeyboardTester.click team from its source-based buying guide; no hands-on 80HE+ test is claimed.

Illustrative stock photo, not the Wooting 80HE+ or a test unit. RDNE Stock project / Pexels.

A keyboard's advertised USB polling frequency and the key events visible to a web page are different observations. A receiving web app needs a repeatable acceptance check, not a polling claim inferred from repeated letters.

The Wooting 80HE+ buying guide prompted this protocol for anyone changing a keyboard or remapping its thumb keys. It applies to other keyboards too. No 80HE+ unit was tested for this note.

Define a small observation sheet

Record the board, firmware/profile, operating system, browser, layout and connection. For each step, note the intended physical action, the event received, and whether the key returns to its released state. Keep the same environment when comparing profiles.

MDN's KeyboardEvent reference distinguishes press/release events. Its code documentation also matters: a physical key-position identifier is not the character expected under every keyboard layout. Record the label and mapping instead of assuming that one identifies the other.

Run three controlled checks

1. Single presses: focus the test surface, press an ordinary letter once and release it fully. Repeat across the keys you use. Log a missing press or a state that fails to clear; do not infer a failed switch from one event.
2. Held keys: hold a letter, then release it. Auto-repeat can produce additional events. The repeat property identifies automatic repetition in supporting browsers; repeat intervals are not direct samples of USB reports.
3. Real combinations: test the combinations used by your application. Record exactly which chord fails and reproduce it with the page focused. OS/browser shortcuts can prevent some inputs reaching your app.

An on-screen registration check is a convenient first observation. For a suspected combination issue, test the actual chord separately. Change one profile setting at a time before rerunning the same steps.

Report the scope of the result

“This chord registered and released in this browser/profile” is a supportable result. It does not certify all chords, hardware scan rate, actuation distance, raw USB polling or game latency. Confirm a game-specific symptom in that game.

The original guide explains the hardware choices and their limits. This checklist describes a method; it contains no fabricated measurements or latency ranking.