Scroll Test
Contents

How the Scroll Test Works

Exactly what the tool records, how it interprets a run, and where the interpretation stops.

What is recorded

After you press Start Test and while the test area holds focus, the page listens for standard browser wheel events as defined in the MDN WheelEvent reference. Each event stores four things: a receipt timestamp, deltaX, deltaY, and deltaMode. Nothing is recorded before Start, after Stop or completion, or while the area is not focused — normal page scrolling outside the active area is never captured and never blocked.

Delta units are never mixed

deltaMode gives the unit: 0 = pixels, 1 = lines, 2 = pages. A pixel and a line are different quantities, so the tool counts events per unit and reports them separately (for example, “140 pixel / 6 line / 0 page”). It never adds them into one number.

Zoom gestures are set aside

Wheel events with the Ctrl key held (trackpad pinch-zoom on many systems) are counted separately and excluded from direction analysis, because they are not scrolling.

The run structure

  1. Input type: Standard wheel, or Touchpad / free-spin for coasting-aware wording.
  2. Direction: Down, Up, or Horizontal. For Horizontal, the dominant sideways direction decides, and minority-side events count as opposite.
  3. Duration: 15, 30, 45, 60, 90, or 120 seconds of steady input. Longer presets provide a larger observation sample; they do not make the result inherently accurate.
  4. Calibration: the timer starts after 3 slow events in the test direction, confirming the pad and direction work.

After a run you can replay the recorded ticks, inspect the timing profile, read the observation / quality / validity cards, open the capped event table, save runs as A and B for comparison, or export the report as JSON. An import accepts only files the tool itself exported. A labelled demonstration with synthetic data is available for exploring the interface without hardware.

How verdicts are worded

  • “No unexpected reversal observed” — every interpreted event went the requested (or dominant sideways) direction.
  • “Possible opposite-direction events observed” — some events opposed it. The result lists count and rate, and names non-hardware causes.
  • “Mixed direction test” — at least 35% of events went each way, which usually means the direction changed mid-run.
  • “Too few events to interpret” — fewer than 8 events.
  • “No input recorded” — zero events, or only zoom gestures. A stopped run is labelled as a partial sample.

The tool computes no health percentage, measures no polling rate, infers no physical wheel notches beyond what the browser delivered, and repairs nothing. Classification algorithm version: st-wheel-1; the version travels inside every exported JSON report.

Synthetic examples

These labelled traces are generated by the tool's own demonstration mode — they illustrate patterns, not real hardware:

  • Normal: 120 synthetic events, all in the requested direction, even spacing. Verdict: no unexpected reversal observed.
  • Intentional reversal: the same stream with 4 events flipped mid-run (a simulated correction). Verdict: possible opposite-direction events observed, low rate.
  • Possible unwanted reversal: scattered opposing events at irregular gaps with no mid-run correction pattern. Verdict: possible opposite-direction events observed — still not a diagnosis; only a repeating real-world pattern across browsers and machines makes hardware suspect.

Limitations — read beside every result

  • Touchpad inertia and free-spin coasting routinely produce trailing or opposite-direction events.
  • Browser smoothing and OS scroll acceleration, speed, and direction settings reshape the event stream.
  • Intentional corrections (you change direction mid-run) count as reverse input — the tool cannot tell intent.
  • A worn or dirty encoder is only one possible cause among several; a single run cannot confirm faulty hardware.
  • Short, interrupted, or unfocused runs produce limited verdicts — by design, not by error.
  • Phones and tablets without a mouse show a notice instead of a result; the tool never invents data.

Change log

  • st-wheel-1 (current): duration presets 15–120 seconds with a neutral “Not tested yet” state; run dashboard with eleven labelled metrics; separate observation, sample-quality, and validity cards; “Mixed direction test” verdict at 35% minority rate; capped on-demand event table; interruption counting; algorithm version embedded in JSON reports.
  • Previous behavior: single directed runs with 5/10/15-second presets, four live counters, monochrome replay, timing profile, Run A/B slots, JSON export/import, and a labelled synthetic demonstration.

Keyboard, screen readers, and motion

  • Everything is keyboard-operable: Tab reaches the pad and every control. Status changes are announced through a polite live region.
  • Replay timelines and the live graph carry direction arrows, labels, and adjacent text summaries, and never rely on color alone.
  • Reduced-motion preferences are respected — replay renders instantly and no decorative animation plays.