Voice-to-keyboard is usually for fine correction; keep that path short

What it is

People switch the channel to a keyboard mostly not to rewrite the whole draft, but to fix one or two misrecognized characters—caret-level fine correction. That path must be short: from noticing the error to a keyboard insertion point on the wrong word should be one or two steps, not dismiss voice, open another editor, and hunt for the sentence. Path length decides whether dictation is still used after it errs.

Why it happens

The locality of recognition errors plus the keyboard’s advantage at character grain together specify the motive for the switch. If the entry is buried in a second toolbar, or the switch drops the selection, people will respeak the whole sentence or abandon voice. A short path means: “fix with keyboard” on the wrong word, tapping the transcript to summon the keyboard with that word selected, and not destroying the session. It runs beside spoken replace: speech is good at whole words and sentences; the keyboard is good at homophone characters, punctuation, and seams. It also meets “correction can cost more than a respeak”: when the keyboard is one step, a local fix is often cheaper than speaking again. In hands-free use the path gets long or vanishes; that is a different constraint, and not a reason to lengthen the dictation UI.

Studying it

Seed local errors in a dictated draft; measure steps and time from noticing to a completed fix, and whether people switch to respeak. Compare “tap word → keyboard with selection” with “first dismiss voice, then open keyboard, then locate.” Gaze shows time spent hunting the entry. Participants must know a keyboard switch exists, or the study measures discoverability rather than path length.

Where it stops holding

Fully hands-free use has no short keyboard path; offer spoken replace or respeak. When a hardware keyboard is already in front of the user, the bottleneck is selection, not summoning a keyboard. Children or people unused to an IME may still stall on the short path. Advertising a switch that takes five steps is worse than no switch: it promised correction and did not deliver.

Applying it

• A tap on the transcript should summon the keyboard with that word selected; do not require dismissing a microphone panel first.
• Put “fix with keyboard” as a first-class action beside the hypothesis, not in settings.
• Accept on a local-error task: from tapping the wrong word to inserting the right character, target two steps or fewer.

Related

• Same group: C7.17.1 Switching from voice to keyboard should keep the caret and existing text, not reset the edit · C7.17.2 Showing the keyboard should pause recognition so key-clicks are not taken as speech · C7.17.3 Undo in mixed input must cover content from both sources
• Adjacent: C7.03 Types of Recognition Errors · C7.13 Voice Editing and Spoken Correction
• Search: fine correction · channel switch · dictation edit