Do not change context when a field loses focus
F9 is a documented failure, which means it describes a way a rule gets broken rather than a way to meet one. Somebody citing F9 at you has found a defect. The pattern is a form that acts when a field is left rather than when a button is pressed. Tab out of the third field and the form submits. Or a window opens. Or the page navigates somewhere else. Three separate behaviors, one trigger, and the trigger is the ordinary act of moving on to the next field. Note what F9 is not about. Receiving focus is a different event with a rule of its own, and this failure is about losing it. There is no published technique that tells you how to pass here, because the fix is not to do it.
How we find it in an audit
Reviewers tab through every form on the site without clicking anything, and watch for three things separately. Does the form submit on the way past. Does a window open. Does the page navigate. Merging those into one question misses the quieter two, which is why we ask them one at a time. Automated tools can find blur handlers and cannot tell you what a handler does, so this ends up being a person pressing Tab and paying attention.
How affected users experience it
Tab is how a keyboard user moves between fields, so this failure fires on the most ordinary action there is. A screen reader user leaves the quantity field to reach the delivery field and the order is placed. Nothing asked. For someone using a switch device or speech input, every field boundary carries the same risk, and there is no way to check the rest of the form without crossing one. What they learn is to distrust your form, which is the correct response and not one that gets anybody to checkout.
Passes vs. fails
Passes
<input id="qty" name="qty">
<button type="submit">Update cart</button>
<!-- Leaving a field does nothing. Pressing the button does the thing. -->Fails
<input id="qty" name="qty" onblur="document.forms[0].submit()">
<!-- Tabbing to the next field places the order. -->How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Meta element has no refresh delayA tool can check this
- Meta element has no refresh delay (no exception)A tool can check this
The other techniques filed under this rule
16 guides on this site are filed under 3.2.5 Change on Request. W3C documents this one as a failure of that rule, so it describes a way the rule gets broken rather than a way to pass it.
- G76sufficientUpdate content only when the user asks
- G110sufficientMake client-side redirects instant, not timed
- H76sufficientMake meta refresh redirects instant, never timed
- H83sufficientWarn users when links open new windows
- SCR19sufficientNever change context when a select changes
- SCR24sufficientOpen new windows only when the user asks
This guide is our interpretation of W3C technique F9: Failure of Success Criterion 3.2.5 due to changing the context when the user removes focus from a form element. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.