By Aileen Smith

This is a paper replay of a fictional record list. The interface has a list, a note composer, a row action menu, and an optional shortcut: the letter n moves to the next record. The record labels R12 and R13 are invented.

The useful unit of review is a transition: where focus started, what the person did, and where focus and selection ended. A screenshot of the final screen loses most of that information.

The intended route

For this example, n works only while the record list has focus. It remains possible to move through the list with ordinary visible controls. The shortcut can also be switched off. These are deliberate choices for this fictional interface, not a claim about how every list should behave.

Read the trace one row at a time:

Code:
START: selection R12 | focus record list | shortcut ON

1  Press n
   selection R13 | focus record list
   Result: one record forward

2  Open the note composer for R13
   selection R13 | focus note text field
   Result: insertion point in the empty note

3  Type: next review needs a second example
   selection R13 | focus note text field
   Result: the sentence appears in the note

4  Close the composer with its ordinary Close control
   selection R13 | focus the control that opened it
   Result: a usable place to continue

5  Switch character shortcuts OFF, then focus the list
   selection R13 | focus record list | shortcut OFF

6  Press n
   selection R13 | focus record list
   Result: no shortcut action

Two failures that can look like the same bug

In the first failure, the list advances while the person types the sentence in step 3. Selection changes even though focus is in an editable field. The note may still look normal, so a review that checks only whether text was entered can miss the unintended navigation.

In the second failure, selection stays at R13 but focus leaves the text field. Later keystrokes reach a different control or do nothing useful. This is a focus-route failure even if the record counter never changes. Record both focus and selection rather than using either as a substitute for the other.

The missing-return edge case

Now change one condition: a background filter removes R13 while its composer is open. The control that opened the composer no longer exists when the person closes it.

Do not write "return focus" without naming a destination. Choose an appropriate surviving control for the real interface, such as the list heading or the first remaining row action. Then replay the close action and check that the chosen destination is actually available. This example proposes a review question; it does not prescribe a universal focus-recovery rule.

A replay map to fill in

Use ordinary interactions in a test environment and record what actually happens. Do not put customer note text in the trace.

Code:
Action or text entered:
Focus before:
Selection before:
Shortcut setting and scope:
Focus after:
Selection after:
Visible result:
Unexpected side effect:

A useful failure report keeps the smallest sequence that demonstrates the wrong transition. "Typing advances the list" is more useful when it names the focused field, shortcut setting, and first character that changes selection.

Read the underlying guidance

W3C's explanation of character-only shortcuts describes ways to reduce unintended activation: provide an off switch, let people change the shortcut to include a non-character key, or limit the shortcut to the focused component. See Understanding Character Key Shortcuts. This short replay is one design-review aid, not a full accessibility assessment.

Finish the review when the intended route and the changed-condition route are understood, with remaining unknowns written down. The result to protect is the person's ability to complete a note and continue from a predictable place.