Unexpected context changes break the user's plan

What it is

Focus lands on an item and a new page opens; finishing a select submits the whole form; a countdown dumps the person somewhere else. Context changed before the user issued a “go.” Unexpected context change breaks the expectation “I am still doing this.” People with cognitive disabilities pay more to pick the intention back up; they often cannot say where they were sent, or whether what they just typed still exists.

Motion that autoplays on the same page and steals attention is a different leaf. A version that relocates navigation wholesale is a different leaf. This one is only in the current session, the interface changing place or submitting data without being asked.

Why it happens

People plan the next move against a stable context: still this form, next control is the next field. Auto-redirect or auto-submit is a forced task switch, plus possible submit or discard of the form state they were modelling. Impaired executive function lets the switch itself squeeze the goal out of working memory; faced with a page that just appeared, they cannot splice “I was filling an address” back on.

Navigation on focus is especially severe for keyboard-only use: Tab was meant to move focus, not to activate. Submit-on-input mistakes “I am comparing options” for “I have decided.” Both violate the same expectation: the action that changes context should be one the user clearly issued (submit, a link), not a side effect of focus or value change.

Studying it

Complete a form that has selects, radios, and date controls with the keyboard only: changing every select and radio must not navigate or submit. Conformance maps onto “no context change on focus” and “no context change on input,” unless the user was warned in advance and can reverse it.

Independent variables: whether onchange / onfocus fires navigation or submit, whether an auto-redirect can be cancelled, whether a pre-redirect message is readable in time. Dependent variables: unexpected submits, off-page events caused by focus movement, ability to return to the original field after the interruption.

A session timeout that kicks people to a login page stacks a time limit with this leaf: silent submit or wipe on timeout fails both.

Where it stops holding

A click on a link or a submit button is an expected change of context. A post-login landing on the original target, if the destination is understandable, is usually acceptable. A single-page app changing route after a nav click is not unexpected if that click caused it. A forced logout for security needs advance warning and a kept draft; it cannot be an unexplained instant page swap. Autosaving a draft without changing page or submitting is not a context change.

Applying it

• Do not navigate or submit on focus or on value change. Bind submit to an explicit submit control.
• When an auto-redirect is unavoidable (a session about to end), give an interruptible warning with remaining time and say what happens to the data; the user must be able to cancel.
• Verify: change every choice control with the keyboard only; the page must not navigate or submit. Then open a delayed-redirect URL; within the countdown the user must cancel and stay. Any onchange submit fails, even if it “speeds the flow.”

Related

• Same group: J4.11.1 Same function, same name and place, lowers learning cost · J4.11.2 Predictable navigation lets users form a stable mental map · J4.11.4 Consistency has to survive version changes; churn costs cognitive-disability users more
• Nearby: J3.06 Time limits · J4.08 Attention and distraction · A5.08 Interruption cost and task resumption
• Search terms: on input context change · on focus · auto submit · auto redirect