F22: When Windows Open Without Warning

For most users, an unexpected pop-up window is a minor annoyance — a flicker, a quick close, back to work. For a screen reader user, that same window is a context collapse. Focus jumps without warning. The user's position in the original page is lost. The new window may have no discernible title, no clear relationship to what came before, and no obvious way back. What took the sighted user two seconds to dismiss may take the screen reader user two minutes to untangle — if they can at all.

This is the failure that WCAG 2.2 Technique F22 (opens in new window) documents. It's one of the cleaner entries in W3C's failure catalog: a specific, avoidable pattern that violates Success Criterion 3.2.5 Change on Request (opens in new window). The rule is straightforward — context changes should only happen when users initiate them and understand what they're initiating. Opening windows without that understanding fails the rule.

The Failure

F22 covers four distinct patterns, all sharing the same root problem: a window opens that the user didn't meaningfully request.

• Page load pop-ups: A new window appears over the existing browser window the moment a user navigates to a page. Focus moves to the new window without any user action.
• Unlabeled link targets: A user clicks a link, a new window opens, but the link contained no indication that this would happen.
• Invisible click targets: A user clicks the body of a page — not a link, not a button — and a new window appears. No visual affordance suggested the area was interactive.
• Undecorated text triggers: A user clicks what appears to be plain text, and a new window opens. No underline, no color change, no cursor shift — nothing signaled interactivity.

The common thread is the absence of informed consent. The user didn't know the action would open a window, so the window opening represents an unexpected context change — a direct violation of SC 3.2.5.

It's worth noting that SC 3.2.5 is a Level AAA criterion. Organizations targeting WCAG Level AA conformance are not strictly required to meet it. But that framing undersells the real-world impact. The behaviors F22 describes cause genuine harm to users with disabilities well before you reach AAA territory — and some of these patterns create secondary failures against lower-level criteria around focus management and consistent navigation.

Why This Matters

The W3C's description cuts to it directly: "New windows take the focus away from what the user is reading or doing."

For keyboard-only users, unexpected focus movement means losing their place in a complex navigation flow. For screen reader users, a new window that opens without announcement can be genuinely disorienting — they may not realize a new context has loaded, may attempt to continue interacting with the original page, and may hear confusing or contradictory output from their assistive technology as it tries to reconcile two active windows.

Users with cognitive disabilities face a different version of the same problem. Unexpected context changes interrupt working memory. A user who was mid-task — filling out a form, reading a multi-step process, following a set of instructions — now has to rebuild their mental model of where they are and what they were doing. For users with attention-related disabilities, this interruption may not be recoverable.

The invisible click target patterns (Examples 3 and 4 in F22) add a layer of confusion that extends to all users but hits hardest for those relying on assistive technology. Undecorated text that triggers window opens violates user expectations at a fundamental level — it's the digital equivalent of a door that looks like a wall.

This connects to a broader testing gap that our research on automated vs. manual audits documents: automated tools can flag some unexpected window behaviors, but contextual judgment — "does this user have any reason to expect this window?" — requires human evaluation. A tool can detect that a new window opened on page load. It cannot always determine whether that was appropriate given the interaction context.

The Fix

The corrected patterns all share the same logic: if a window will open, tell the user before they commit to the action.

For links that open new windows, the minimum fix is explicit text in the link itself:

<!-- Failure pattern -->
<a href="terms.html" target="_blank">Terms of Service</a>
<!-- Fixed pattern -->
<a href="terms.html" target="_blank">
  Terms of Service (opens in new window)
</a>

If you prefer not to add visible text — for design reasons — an aria-label or visually hidden span can carry the warning to screen reader users, though visible text is always preferable because it benefits all users, including those with cognitive disabilities:

<a href="terms.html" target="_blank">
  Terms of Service
  <span class="visually-hidden">(opens in new window)</span>
</a>

For page load pop-ups, the fix is architectural: don't open windows on page load without explicit user initiation. If a dialog or overlay is needed, use an in-page modal with proper focus management rather than a new browser window.

For click targets that appear non-interactive, the fix is to make interactivity visible. If an element triggers behavior, it must look like it triggers behavior — appropriate cursor styles, visual affordances, and semantic HTML (<button> or <a>, not <div> or <span>).

The underlying standard is SC 3.2.5, which requires that changes of context be initiated only by user request. The WCAG Understanding document for 3.2.5 (opens in new window) clarifies what qualifies as a "change of context" — it includes changes to the user agent (opening a new window), changes of focus, and significant changes to page content.

Applying This

F22 failures are partially detectable by automated tools, but the full picture requires manual review. Here's what to look for in practice:

In code review:

• Flag any target="_blank" usage and verify the link text includes a new-window warning
• Search for window.open() calls and trace when they fire — page load triggers are almost always failures
• Look for click handlers on non-semantic elements (div, span, p) that open windows

In automated testing:

• Tools like axe and Lighthouse can detect some instances of new windows opening on page load
• They cannot reliably detect whether link text adequately warns users — that requires human judgment
• The gap between automated detection and full audit coverage is real here: this is a category where manual review is essential

In design review:

• Establish a team convention: any link opening a new tab/window gets a standard warning pattern, defined in your design system
• Treat invisible click targets as a design bug, not just an accessibility bug — they fail all users
• Consider whether new windows are necessary at all. Many cases where developers reach for target="_blank" could be handled with in-page navigation or modals

Quick audit step: Search your codebase for target="_blank" and window.open. For each instance, answer two questions: Does the user know this will open a new window before they click? Did the user take an action that reasonably implies they want a new window? If either answer is no, you have an F22 failure.

The language access dimension matters here too. Warning text like "opens in new window" must be translated when your interface serves multilingual users. A screen reader user who reads Vietnamese encounters the same disorientation from an unexpected window as an English-speaking user — but if the warning text exists only in English, it fails them twice. idioma.chat (opens in new window) addresses this by translating the full accessibility layer — ARIA labels, alt text, form validation messages, and dynamically loaded content — not just visible page text. A "opens in new window" warning that exists only in English is not a complete fix for a multilingual audience.

CORS Perspective

From a strategic alignment lens, F22 is a low-cost fix with outsized community impact. The operational lift — adding warning text to links, removing page-load pop-ups, making click targets visually identifiable — is minimal compared to the barriers these patterns create for screen reader users, keyboard navigators, and users with cognitive disabilities. The risk calculus is straightforward: organizations targeting WCAG conformance should treat unexpected window behavior as a systematic code review item, not a one-off fix. The compliance framework research shows that teams often over-invest in complex remediations while leaving high-impact, low-effort failures like F22 unaddressed — a prioritization problem that design systems and code review checklists can directly solve.