Interfaces cannot assume touch remains available when sensing fails at scale

What it is

In driving rain, severe cold, a fogged panel, a sheet of water, the capacitive surface is not “a bit worse.” It stops taking valid contacts at scale. A dialog that can only be dismissed by tapping a button, an onboarding that can only be finished by swiping, an emergency call buried behind layers of touch, deadlocks the task when sensing is gone. The interface default that “some finger will always hit” is false under those conditions. That is not one glove missing one small button. The channel itself is temporarily absent.

Why it happens

A water film shorts electrodes into one sheet; the controller either shuts touch off or reports a full-screen ghost. Cold degrades battery, scanning, and skin together until reports are too sparse to complete a swipe. The application still writes its state machine as “touch events will arrive”: a modal eats the back key, a carousel must be swiped, payment wants a long press. No events, no progress. System power, volume, and voice wake travel another sensing path and may still live, but if the foreground UI has not bound critical actions to those paths, live keys equal none. Full-screen apps also often swallow system gestures, so even “escape with system back” is gone when the surface dies.

Studying it

Under repeatable failure (a controlled mist for a water film, a cold box until skin is stiff, a deliberate touch-IC lockout) run core tasks: silence an alarm, hang up, confirm pay, dismiss a blocking dialog. Independent variables are whether a physical key / voice / timeout auto-dismiss remains, and whether the modal allows hardware back. Dependent measures are whether the task completes, which channel completed it, time stuck on a touch latch, and whether people try to smash or power-off the device. Split “small button is hard to hit” from “the whole panel emits no events”; the first is a hot-zone problem, the second is a channel-assumption problem. Simulate high-stakes alarms; do not run this in a real emergency.

Where it stops holding

Indoor office desktop touch with stable power usually deserves the assumption; not every settings page needs a voice twin. If lockout lasts only a few hundred milliseconds, a timeout retry clears it and another channel is unnecessary. Some waterproof phones already switch to force or physical keys underwater, so they do not assume capacitance and this leaf is already satisfied. Voice as the only backup fails again in noise and in private places; redundancy needs at least two principles.

Applying it

• Give blocking modals, emergency, and payment at least one non-touch exit: a physical key, voice, a timeout dismiss, or confirm on an already-connected watch or headset.
• When a full-screen app sees no valid touch for several seconds, surface a system-level exit; do not trap people in a cover that only a swipe can close.
• Rehearse “whole panel, no events” with mist and a glove box, and list the actions that still complete; everything off that list must be abandonable or deferrable in that state.

Related

• Same group: C2.24.1 Glove mode raises detection gain to register thin-glove contacts · C2.24.2 Higher glove-mode gain also amplifies noise into false touches · C2.24.3 Glove and wet-hand modes need a visible system state
• Nearby: C2.13 Touch in extreme conditions · C7.06 Hands-free and eyes-free use
• Search terms: touch unavailability · input redundancy · modal lockout