Detection failure should actively offer alternatives rather than fail silently
Aliases: fallback notice · alternative path · failure recovery
What it is
When detection shows that the default modality has failed, the system must announce alternatives through a still-perceivable channel. If speech output is broken, use a visible banner or haptic; if the screen is unavailable, use speech or vibration. The notice should include a brief reason, available options, and a path to switch or continue.
Why it happens
Silent failure removes the information needed to interpret the state: users cannot tell whether input was received, recognition failed, the channel is disabled, or the task ended. Active alternatives route control through a working channel and turn waiting into choice. The notice is itself availability-constrained: it cannot use the failed channel to declare failure, nor broadcast sensitive content. A consequence-graded response usually works—automatic second choice with a visible change for low risk; explicit alternatives and confirmation for high risk, because channels change visibility, speed, and privacy.
Studying it
Compare silent failure, error notice, alternative notice, and automatic switching: disable vision, hearing, or touch mid-task and record continuation, time to discovery, repetitions, and abandonment. Variables include failed channel, remaining channels, notice content, and consequence. Outcomes include recovery success, time to switch, wrong actions, and perceived control. Verify notice arrival through a non-failed channel—for example, confirm haptic or speech when the screen is dead.
Where it stops holding
Automatic substitution is not always better. If the fallback exposes content, is much slower, or requires confirmation for a consequential action, list options first. Some combinations lack equivalence: a detailed chart without a screen may support only a summary, and complex voice editing in noise may be infeasible. State what can be completed and what is limited rather than claiming “equivalent availability.” Frequent failures should use persistent state plus salient changes, not repeated interruptions.
Applying it
- Prescribe at least one notice and alternative path per failure class that does not depend on the failed channel.
- Show a reason summary, available channels, a switch entry, and any functional loss.
- Keep confirmation on the alternative channel for consequential or externally visible actions; allow automatic switching with return for low risk.
- Verification: test recovery and repetitions under each failure, then ask users to name alternatives and functional limits.
Related
- Within the group: D5.10.1 The system must detect at runtime whether the environment supports the default modality · D5.10.4 Misjudged availability makes users repeatedly try an unusable channel
- Adjacent: D5.09.2 Hidden automatic switching makes users misjudge the active modality · D5.04.3 Availability changes should prompt alternative paths automatically
- Search terms:
alternative path·failure notice·graceful fallback