Over-aggressive rejection swallows valid edge operations

What it is

Over-aggressive rejection filters large, edge, or slow contact to avoid palm false touches, but also swallows real back gestures, thumb buttons, canvas-edge drags, or assistive input. It trades fewer false acceptances for more false rejections; both harm usability.

Why it happens

Palm rejection relies on thresholds and priority, but what actually keeps "over-aggressive rejection" recurring in engineering practice is a stark asymmetry in visibility between the two error types. A false acceptance is almost always immediately noticeable — the person did not intend to tap anything, yet the screen visibly reacted, and "something happened that shouldn't have" is conspicuous, easy for a user to complain about and for a developer to reproduce and fix. A false rejection is the opposite — it is silent: someone swipes or taps, nothing happens, and all they can sense is "this isn't very responsive," which is hard to describe precisely as "my gesture got mistaken for palm contact and dropped." System logs typically only record accepted contacts, leaving rejected ones with no trace to investigate afterward. This asymmetry in exposure systematically biases long-term tuning toward "reject rather than risk a false touch," because false-acceptance complaints are always louder and easier to pin down, and rejection creeps toward excess one "fix this complaint" cycle at a time.

Studying it

Count false acceptance and rejection together, stratified by edge gesture, thumb tap, pen collaboration, and assistive technology. Test grip, device size, cases, and walking, recording whether people can recover rather than optimizing false-touch rate alone. Measuring a genuine false-rejection rate at all requires the system to specifically log raw contact events that were suppressed, not just the touch points that ultimately got accepted — if rejected contacts leave nothing in the log to begin with, the false-rejection rate is unmeasurable from the start, and tuning can only keep tightening against the false-acceptance side.

Where it stops holding

Loosening rejection cannot let grip randomly fire high-consequence commands. Different risks can require different evidence, and system gesture zones may need a different policy from app edge controls. The goal is predictable balance, not filtering by default.

Applying it

• Give valid edge actions strong intent signals such as trajectory, duration, or explicit handles.
• Provide light feedback or an alternative route for rejected input rather than silently swallowing it.
• How to check: specifically log raw contact events that get suppressed, not just the ones ultimately accepted, and use that log to compute a genuine false-rejection rate to report alongside the false-acceptance rate, so tuning does not keep tightening one-sidedly against whichever error is easier to notice.

Related

• Same group: C2.09.1 Accidental contact from the palm edge and thumb base while holding · C2.09.2 Touches in edge regions need classification rather than direct acceptance
• Nearby: C2.10 Touch latency and directness · C2.02 Edge and corner targets need extra margin
• Search terms: palm rejection · false rejection · edge gesture