High precision with low accuracy looks stable but systematically offset

What it is

When precision is good and accuracy is poor, the estimate barely jitters over a short interval, but the whole cloud sits beside the truth. Users report “the cursor is steady, it just always stops at the edge of the button.” That is systematic offset, not random noise. It is easy to misdiagnose as “tracking is great”—because it does not shake—until people start missing. The reverse, low precision and high accuracy, is a cursor hopping around the truth: it feels worse, but the mean landing is actually right.

Why it happens

Systematic offset is leftover constant error after calibration: kappa not fully absorbed, prism from lenses, extrapolation off the validated region, a monocular calibration applied binocularly. Because the term barely changes frame to frame, RMS can be tiny. Eyes and UIs are more forgiving of “steady” than of “biased”: if the cursor sits stably in the gap between two buttons, hit logic keeps hitting the gap, or keeps hitting the wrong one.

Correctability is the signature of this error. Adding a constant compensation (one click to align, one implicit correction) can slide the whole cloud back to truth without touching precision. Random jitter cannot be fixed that way: compensating a mean does not stop frame-to-frame hops. Treating high-precision/low-accuracy as “buy a more expensive tracker” buys the wrong thing—more expensive instruments often improve precision first.

Studying it

On validation points, plot each point’s mean (accuracy) and the ellipse of its sample cloud (precision). A small ellipse whose center is off is this pattern. Inject a known translation into the mapping and confirm RMS barely moves while mean offset grows by the translation—this trains a team to recognize it. In user studies, ask “steady?” and “on target?” separately; many people use “accurate” to mean “steady.” On tasks, look specifically for stable mis-hits on gaps, not only mean error rate.

Where it stops holding

If the offset varies with screen position (center good, corners off), it is not a constant, a single translation will not bring it back, and the fix is calibration-point layout or a distortion model. Offset that is drifting is changing; “the whole cloud is displaced” here applies only on timescales much slower than a fixation. People with nystagmus almost never reach the high-precision end, so this morphology does not appear. Head-controlled rays, through inertia, also often look steady and slightly off; that is the head, not the eye tracker’s systematic bias.

Applying it

• On a cursor that is steady but always biased, do an offset correction or a short calibration before adding smoothing or swapping hardware.
• Do not trust a stable current-frame coordinate alone in hit testing; if many frames sit in a gap, prompt calibration rather than repeatedly selecting the gap.
• Verify by injecting a known translation: the UI should look “steady but off,” one compensation should restore hits, and RMS should barely move.

Related

• Same group: C8.09.1 Accuracy is the mean offset between estimated and true gaze · C8.09.2 Precision is the spread of repeated measures; the two can vary independently · C8.09.4 The lower bound on target size is set by accuracy, not precision
• Adjacent: C8.10 Gaze drift and recalibration · C8.08 Eye-tracking calibration
• Search: systematic error · offset · high precision low accuracy