What does a touch-driven case fail to prove about a flow that also accepts keyboard or pointer input?

## One screen, several delivery paths A handheld screen designed for fingers is rarely driven only by fingers. An attached physical keyboard, an external pointing device, a device-owned voice-control layer and a hardware controller can all drive the same application, and each delivers input through a different mechanism with different semantics. A case written for touch exercises exactly one of them. Whatever the others reach — different handlers, different event shapes, different sequences of focus and commitment — has no evidence behind it at all. Voice deserves a specific note: a voice-control layer generally works by activating the control a person names aloud, so a control whose spoken name does not match what it displays is effectively unreachable on that path, however well it responds to a finger. ## What each path can express | Capability | Touch | Attached keyboard | External pointer | |---|---|---|---| | Point at a target without committing | no | no — focus is the nearest thing | yes, as hover | | Secondary action on an item | press and hold | a modifier or dedicated key | secondary click | | Continuous movement of a target | drag with a contact | rarely expressible | drag with a held button | | Repeat an action while held | rarely | key repeat | no | | Precise caret placement in text | contact plus handles | arrow keys with modifiers | click and drag | | Two-point interaction such as pinch | yes | no | usually no | Read that table for the cells that say *no*. Those are the joints. Hover has no touch equivalent, so hover-dependent behaviour gets zero incidental coverage from a touch suite. Multi-point gestures have no keyboard equivalent, so anything behind a pinch is unreachable from a keyboard unless the product offers another route. Key repeat has no touch equivalent, so a control a person is expected to hold down behaves differently on each path. ## The gesture-only trap The commonest and costliest finding here is not a broken case; it is an action with **no route except a gesture**. Archive by dragging the row. Reorder by holding and dragging. Reveal an option by pressing and holding. Each of those is fine as *a* route. As the *only* route it means the action cannot be performed at all by someone driving the screen another way, and no amount of testing on the touch path will surface it. When you find one, write the case anyway. Its assertion is that a non-gesture route exists and works, and it stays red until one does. A case that states an intended behaviour and fails is more useful than no case, because it names the gap where people are already looking. ## Text entry is where the difference bites Text fields are the richest source of path-specific behaviour, and the one most often assumed covered because contacting the field worked: - **Caret placement**: a contact places the caret and handles refine it; a keyboard moves it by arrow keys and modifiers; a pointer clicks and drags a selection. - **Selection**: extending a selection with held modifiers has no direct touch equivalent, and a field that implements only handle-based selection loses it entirely. - **Key repeat**: a held key deletes repeatedly and can outrun a field's validation or its change notifications in a way a series of contacts never does. - **Commit semantics**: a keyboard commonly commits a field with a dedicated key, which may reach a different handler than the on-screen action key. - **Movement between fields**, which touch skips altogether because every field is contacted directly. One case that fills a form on the alternative path and asserts the same result catches most of this at almost no cost. ## Choosing the handful of cases 1. Inventory the actions reachable **only** through a gesture. Every one is a candidate defect before it is a candidate case. 2. Take **one journey end to end** on the alternative path — reach the form, fill it, submit it, land on the result — rather than sprinkling single-step checks that prove nothing about the sequence. 3. Cover **text entry** on the alternative path, for the reasons above. 4. Add a **hover** case only where hover carries product meaning, such as a preview or a reveal, because that behaviour has no other coverage whatsoever. 5. Keep those cases in **their own named group**, so a run on hardware without those inputs skips them with an explicit reason rather than failing for the wrong cause. Typically that is five to ten cases against a suite of hundreds, and it covers what differs between the delivery paths instead of re-proving everything they share. ## What this is not This is a coverage question about input delivery, and it stops short of two neighbouring disciplines. Whether a control can be operated at all without a pointing device, and how an assistive layer describes and announces a screen to someone who cannot see it, are separate concerns with their own criteria and their own cases. Borrow their vocabulary where it helps, but do not fold their audits into a case whose job is narrower: given that the product accepts more than one input path, which cases exercise the paths a touch case never touches.