Moving keyboard focus to a Help or Preview control is navigation, not activation; it should not submit a form, open a receipt, or move the reader to a different screen. This distinction matters in a fictional feedback form where someone is reviewing a note before deliberately sending it.
What focus should do
In this hypothetical example, the form contains a Note field, a Preview button, a Help control, and a Send feedback button. The user tabs from Note to Preview. The button receives focus, its name can be read, and the user remains on the same form. Nothing is submitted merely because the control is reached through keyboard navigation.
This matches the verified guidance for WCAG 2.2 Success Criterion 3.2.1: receiving focus must not by itself trigger a context change such as automatic submission, opening a new window, or moving focus elsewhere. See the W3C explanation of changes on focus.
Worked action timeline
| Step | Keyboard action | Expected result |
|---|---|---|
| 1 | Tab from Note | Preview receives focus; no submission |
| 2 | Read the control name | The user reviews its purpose |
| 3 | Press Enter or Space deliberately | Preview opens or updates the review |
| 4 | Return to Send feedback | Submission occurs only after deliberate activation |
The receipt in this fictional sequence must not appear at step one. It may follow an intentional Send feedback action, but not focus alone. Previewing content is also different from submitting real feedback. Use a harmless demonstration form, not an actual account or payment form.
Why the distinction helps
Focus is a navigation state, not the same as hovering over, clicking, or activating a button. If reaching Preview immediately submitted the form, a keyboard user could be taken away before reading the label or checking the proposed content. A predictable interface lets the person choose when the review action and final submission happen, without treating tabbing as consent.