Without a cue for the pending dead-key state, people think the key is dead

What it is

After a dead key, the system enters a pending state waiting for the next stroke. If the caret, status area, and keycap show no change, the press looks like hardware failure: the cap moved, no character appeared. Typical next moves are mashing the same dead key, trying another mark, or inspecting the board. Pending is a legal input state; failure is a misread of it. The difference is a cue.

Why it happens

Ordinary keystrokes close a loop: action → character (or caret motion). A dead key deliberately breaks that loop and postpones the result. People detect hardware by “did a character appear,” so a blank result is encoded as a fault. Cues can be light: a ghost accent beside the caret, a candidate strip showing “´ + ?,” a screen reader saying “acute, waiting for a letter.” Without them, even layout-fluent users suspect a break in apps that hide pending state. CJK composition at least shows a pinyin string or underline; dead-key pending is shorter and easier to mistake for a dropped key.

Studying it

Compare the same layout with and without a pending indicator on a task that requires diacritics. Record pause after the dead key, mash count, and spoken “the key is broken.” Eye tracking can show gaze dropping from screen to board. Administer the fault-attribution questions immediately, before post-hoc rationalization. Testing only in the system notepad underestimates the problem, because many custom fields swallow pending state.

Where it stops holding

Daily users of the layout have encoded “this stroke prints nothing,” so the cue's marginal gain shrinks, though it returns when they switch apps. Long-press diacritic popups on soft keyboards have no blank window, so the false-failure is rarer. Mechanical travel and sound confirm that the key actuated, which can soften but not erase “no character appeared.” An in-game chat that clears pending state will fail even when the system-level cue exists.

Applying it

• Custom fields should show the pending accent (ghost character or underline) rather than stay blank.
• Accessibility APIs should announce a dead key as “waiting for the next character,” not as empty input.
• If a product cannot show pending state, do not require dead-key-only characters in that field; offer an insert panel.
• Verify with people who rarely use international layouts: hide existing cues, ask for an accented word, and count how many say the key is broken or mash after the first stroke. Adding a ghost character should drop that rate.

Related

• Same group: C6.21.1 A dead key does not emit a character immediately; it combines with the next key to form a diacritic · C6.21.3 AltGr and other layered layouts put a third symbol on the same physical key, switched by a modifier · C6.21.4 Layered layouts raise per-key information density and the chance of hitting the wrong layer
• Adjacent: C6.25 IME state and switching · C6.31 Key repeat rate and dropped keys
• Search: dead-key feedback · pending compose · mode visibility