F60: When Text Input Triggers an Unwanted New Window

Launching a new window when a user types in a form field violates WCAG 2.2 Success Criterion 3.2.5 Change on Request (opens in new window). That's the plain statement of Failure F60 (opens in new window). The nuance — and there is real nuance here — is worth understanding before your team writes a single line of remediation code.

The Failure

F60 describes a specific pattern: a new browser window opens in response to a user entering text into an input field, for purposes other than error reporting. The W3C's example is instructive. A user fills in a postal code during checkout. A script detects the value and opens a new window displaying advertisements for local services.

That's the failure. The trigger is passive — the user didn't click a button or submit a form. They typed. The consequence — a new window — was not requested and not anticipated.

The relevant code pattern looks like this:

<!-- FAILURE PATTERN -->
<label for="postal">Postal Code</label>
<input
  type="text"
  id="postal"
  name="postal"
  onchange="openAdWindow(this.value)"
/>
<script>
function openAdWindow(zip) {
  window.open('https://example.com/local-ads?zip=' + zip, '_blank');
}
</script>

The onchange event fires when the user leaves the field after entering a value. A new window opens. The user didn't ask for this. Under SC 3.2.5 (opens in new window), changes of context must be initiated by the user — not triggered automatically by data entry.

Why This Matters

The harm here is not abstract. It lands differently depending on how someone uses the web.

Screen reader users experience a sudden, disorienting context shift. Focus may jump to the new window without warning. The user loses their place in the form. Depending on the assistive technology and browser combination, they may not immediately understand what happened or how to return to the original form.

Keyboard-only users face a similar orientation problem. The new window now holds keyboard focus. Getting back to the original form requires deliberate navigation — Tab, Alt+F4, or window-switching shortcuts — none of which are obvious to users who are still learning keyboard navigation.

Users with cognitive disabilities may find the unexpected window deeply confusing. They were filling out a form. Now something else is on screen. Was the form submitted? Did they do something wrong? The cognitive load of resolving this interruption can cause form abandonment entirely.

Users with attention-related disabilities are similarly disrupted. An unexpected window is an unplanned context switch — exactly the kind of interruption that derails task completion.

The postal code ad scenario from the W3C document isn't hypothetical. Advertising-driven triggers on form fields have appeared in real implementations, particularly in e-commerce and lead-generation flows where marketing and engineering decisions intersect without accessibility review.

The Fix

F60 also documents what an acceptable exception looks like. If a postal code is invalid, opening a helper window with correction instructions is permissible — because the window serves a direct error-correction purpose tied to the user's own action.

<!-- ACCEPTABLE: Error reporting only -->
<label for="postal">Postal Code</label>
<input
  type="text"
  id="postal"
  name="postal"
  onchange="validatePostal(this.value)"
  aria-describedby="postal-hint"
/>
<span id="postal-hint">Enter your 5-digit ZIP code</span>
<script>
function validatePostal(zip) {
  const valid = /^\d{5}$/.test(zip);
  if (!valid) {
    // Error reporting window is acceptable under F60
    window.open('help/postal-format.html', 'postalHelp',
      'width=400,height=300');
  }
  // Do NOT open windows for non-error purposes (e.g., ads, promotions)
}
</script>

Better still: inline error handling eliminates the new-window problem entirely for error cases too.

<!-- PREFERRED: Inline validation, no new window -->
<label for="postal">Postal Code</label>
<input
  type="text"
  id="postal"
  name="postal"
  aria-describedby="postal-error"
  aria-invalid="false"
/>
<span id="postal-error" role="alert" hidden></span>
<script>
document.getElementById('postal').addEventListener('blur', function() {
  const zip = this.value;
  const errorEl = document.getElementById('postal-error');
  const valid = /^\d{5}$/.test(zip);
  if (!valid) {
    this.setAttribute('aria-invalid', 'true');
    errorEl.textContent = 'Please enter a valid 5-digit ZIP code.';
    errorEl.removeAttribute('hidden');
  } else {
    this.setAttribute('aria-invalid', 'false');
    errorEl.setAttribute('hidden', '');
    errorEl.textContent = '';
  }
});
</script>

This pattern satisfies SC 3.2.5, avoids new windows entirely, and also addresses SC 3.3.1 (Error Identification) by surfacing the error inline with role="alert" for screen reader announcement.

Applying This

F60 violations are context-dependent in ways that make automated detection unreliable. A tool can flag window.open() calls, but it cannot determine whether that call is triggered by form input, whether it serves an error-correction purpose, or whether it's part of an advertising or marketing flow.

This is precisely the gap that our research on automated vs. manual testing documents: automated tools cap out at roughly 37% detection of real accessibility barriers. F60 is a strong example of why intent and context require human judgment.

In code review, look for onchange, oninput, onkeyup, and onblur event handlers on <input> and <textarea> elements. Any handler that calls window.open() is a candidate for F60 review. Ask: is this window serving error correction, or something else?

In QA, test form fields manually. Tab through each field, enter values, and observe whether any new windows, tabs, or overlays open without an explicit user action like clicking a button.

In design review, flag any feature request that proposes triggering contextual content (offers, upsells, location-based content) from form field events. These patterns are almost always F60 violations before the first line of code is written. Catching them in design is cheaper than remediating them post-launch.

For teams managing complex compliance environments, the Compliance Framework Paradox research is relevant context: SC 3.2.5 is a Level AAA criterion, which means it applies when organizations are targeting full WCAG 2.2 conformance or when contractual obligations (federal procurement, for example) require it. Know your conformance target before prioritizing remediation.

CORS Perspective

Through the CORS framework, F60 is a clean illustration of how Community and Risk analysis point in the same direction. From a community standpoint, the users most harmed — screen reader users, keyboard navigators, people with cognitive disabilities — are already navigating forms under higher cognitive load than sighted mouse users. An unexpected context shift compounds that load in ways that cause real task abandonment, not just momentary inconvenience. From a risk standpoint, SC 3.2.5 is Level AAA, so it surfaces in federal procurement contexts and in organizations with mature accessibility programs targeting full conformance. Operationally, the fix is low-cost — inline validation is better UX for everyone, not just disabled users — which means the Strategic case writes itself: this is a fix that improves conversion rates, reduces form abandonment, and satisfies a legal standard simultaneously. There's no tradeoff to negotiate.