F37: When Selecting a Radio Button Opens a Window Nobody Expected

There are no warnings. No submit button. Just a radio button that, the moment you click it, launches a new window — and leaves screen reader users stranded mid-task, uncertain what happened or where they went.

This is WCAG 2.2 Failure F37 (opens in new window): a pattern where changing the selection of a radio button, checkbox, or select list triggers a new window without any prior warning. The W3C documents it as a failure of Success Criterion 3.2.2 On Input (opens in new window), which requires that changing a UI component's state doesn't trigger a change of context unless the user has been told in advance what will happen. F37 isn't a subtle edge case. It's a direct violation of a predictability principle that exists specifically to protect users who can't easily recover from unexpected context shifts.

The Failure

The W3C's example is a mirror download selector — a form where users pick a download site from a list of radio buttons. The problem: each radio button fires a JavaScript onclick handler that immediately opens a new window. There's no submit button. There's no warning text. Selection is submission, and the user never agreed to that.

<script>
function goToMirror(theInput) {
  var mirrorSite = "https://download." + theInput.value + "/";
  window.open(mirrorSite);
}
</script>
<form name="mirror_form" id="mirror_form" action="" method="get">
  <p>Please select a mirror download site:</p>
  <p>
    <input type="radio" onclick="goToMirror(this);" name="mirror"
      id="mirror_belnet" value="belnet.be" />
    <label for="mirror_belnet">belnet (<abbr>BE</abbr>)</label><br />
    <input type="radio" onclick="goToMirror(this);" name="mirror"
      id="mirror_surfnet" value="surfnet.nl" />
    <label for="mirror_surfnet">surfnet (<abbr>NL</abbr>)</label><br />
    <input type="radio" onclick="goToMirror(this);" name="mirror"
      id="mirror_puzzle" value="puzzle.ch" />
    <label for="mirror_puzzle">puzzle (<abbr>CH</abbr>)</label><br />
    <input type="radio" onclick="goToMirror(this);" name="mirror"
      id="mirror_voxel" value="voxel.com" />
    <label for="mirror_voxel">voxel (<abbr>US</abbr>)</label>
  </p>
</form>

The onclick attribute does the work that a submit button should do — but silently, and without the user's informed consent.

Why This Matters

SC 3.2.2 exists because unexpected context changes are genuinely disorienting, and that disorientation is not evenly distributed. For a sighted mouse user, a new window appearing is surprising but recoverable — you see it, you can close it, you understand what happened. For a screen reader user navigating by keyboard, focus may shift unexpectedly into a new window without clear announcement, or the original window may lose focus in ways that are confusing to navigate back from. For users with cognitive disabilities, an unannounced context change can break the mental model of what the page is doing — was that intentional? Did I do something wrong? Where am I now?

Keyboard users face a specific compounding problem: radio buttons are designed to be navigated with arrow keys. A sighted user might tab into the group and use arrow keys to review options before committing. With this failure pattern, reviewing options triggers the action. There's no safe way to explore the choices.

This isn't a minor inconvenience. It's a structural barrier that makes the form unusable for a meaningful portion of users — which is precisely why W3C classifies it as a failure, not merely a best-practice deviation.

The Fix

The correction is architecturally simple: separate selection from action. Let the radio button do what radio buttons do — record a choice — and let a submit button initiate the consequence.

<form name="mirror_form" id="mirror_form" action="" method="get">
  <p>Please select a mirror download site:</p>
  <fieldset>
    <legend>Mirror download sites</legend>
    <p>
      <input type="radio" name="mirror" id="mirror_belnet" value="belnet.be" />
      <label for="mirror_belnet">belnet (<abbr>BE</abbr>)</label><br />
      <input type="radio" name="mirror" id="mirror_surfnet" value="surfnet.nl" />
      <label for="mirror_surfnet">surfnet (<abbr>NL</abbr>)</label><br />
      <input type="radio" name="mirror" id="mirror_puzzle" value="puzzle.ch" />
      <label for="mirror_puzzle">puzzle (<abbr>CH</abbr>)</label><br />
      <input type="radio" name="mirror" id="mirror_voxel" value="voxel.com" />
      <label for="mirror_voxel">voxel (<abbr>US</abbr>)</label>
    </p>
  </fieldset>
  <p><button type="submit">Go to selected mirror site</button></p>
</form>

If a new window is genuinely necessary for the destination, warn users before they interact — not after. Text like "(opens in a new window)" adjacent to the submit button satisfies the advance notice requirement. The WCAG Understanding document for SC 3.2.2 (opens in new window) is explicit: users must be informed of behavior before the input that triggers it, not simultaneously or after.

The <fieldset> and <legend> addition in the corrected example isn't strictly required by F37, but it addresses a related gap — radio button groups without a group label create their own accessibility problems, and fixing F37 is a natural moment to address both.

Applying This

Automated testing tools will often miss F37 entirely. The failure lives in the interaction between an event handler and the resulting behavior — not in the markup alone. A static analysis tool sees a radio button with an onclick attribute and may flag it as a warning, but it cannot determine whether that handler opens a window, submits a form, or does something harmless. This is exactly the detection gap our research on automated versus manual testing documents: automated tools catch roughly 37% of real accessibility failures at best. F37 is the kind of issue that lives in the other 63%.

In code review, the signal to look for is any event handler (onclick, onchange, onfocus) attached directly to a radio button, checkbox, or select element. The question to ask: does this handler initiate a change of context — navigation, new window, form submission, dynamic page replacement? If yes, it needs either a submit button or documented advance warning.

For QA processes, manual testing with a keyboard alone (no mouse) will surface this quickly. Navigate into a radio group with the Tab key, then use arrow keys to move between options. If anything happens besides the selection state changing, you have a potential F37 violation. Test with a screen reader as well — NVDA or JAWS with Firefox, or VoiceOver with Safari — and listen for unexpected focus shifts or window announcements.

Design-side, the pattern to enforce is this: form controls collect intent; submit buttons execute it. Any design that collapses those two steps into one should trigger an accessibility review before it reaches development.

CORS Perspective

From a risk and legal priority standpoint, F37 sits in a category that compliance programs frequently underestimate: behavioral failures that automated scanning won't surface. Organizations relying on automated tools to demonstrate WCAG conformance — a pattern our research on compliance framework fragmentation identifies as increasingly common — will produce audit reports that miss this failure entirely, creating a documented compliance posture that doesn't reflect actual user experience. Under Title II (opens in new window) and the DOJ's 2024 final rule on web accessibility (opens in new window), WCAG 2.1 AA conformance is now a legal floor for state and local government entities — and F37 is a failure of that floor. The fix is a submit button. The legal exposure from not adding one is disproportionate to the engineering cost of adding it.