The switch entry point should be reachable at any time, not only on particular screens

What it is

The modality switch must be reachable from any task state, not only from settings, a start page, or an idle screen in a particular mode. Users often discover a channel problem mid-task: a screen is unreadable while driving, speech is inappropriate in a meeting, or touch is impossible while carrying something. Leaving the task to open settings creates interruption or abandonment.

Why it happens

Reachability determines whether control actually exists. If the entry appears only in low-risk idle states, a failure during a step forces users to complete or leave that step first; that path may itself depend on the failed channel, producing a control dead end. A global entry also supports recovery after accidental switching, recognition failure, or environmental change. For assistive-technology users, placement and actuation are especially important because reaching settings can cost more than the task itself.

Studying it

Inject channel loss or recognition failure during multi-step tasks and compare local with global entries: measure time to find the control, forced exits, data loss, and repetition of completed steps. Variables include step count, hand/eye/speech constraints, entry form (physical button, floating control, system menu, voice phrase), and actuation route. Outcomes include recovery success, abandonment, and perceived control. Assistive-technology walkthroughs should cover screen readers, switch access, and voice commands reaching the entry.

Where it stops holding

Reachable at any time does not require a large always-visible widget. Driving, surgery, immersive work, and children's interfaces need protection against accidental activation and attention capture; system gestures, physical buttons, spoken safety phrases, lock-screen shortcuts, or external controllers can provide the path. The entry itself needs redundant modalities: a visual control is useless to a blind user, and a spoken phrase may be inappropriate in public. The requirement is a stable route that does not depend on the failed channel, not a permanently on-screen widget.

Applying it

• Define a global switching path for every task state, including modal dialogs, alarms, immersive mode, and external displays.
• Provide at least two actuation routes per device class, none depending on the channel that has failed.
• When opened, show the current channel, available channels, and whether switching loses state.
• Verification: inject channel loss at each step and check that users can switch without leaving the task and continue.

Related

• Within the group: D5.09.1 Users need to be able to actively choose the current input or output modality · D5.09.2 Hidden automatic switching makes users misjudge the active modality
• Adjacent: D5.04.3 Availability changes should prompt alternative paths automatically · D5.10.4 Misjudged availability makes users repeatedly try an unusable channel
• Search terms: reachable control · global entry point · modality switch