Controls that act on change and the ADA

Changing a setting should not take you somewhere

Picking an option from a list, ticking a box or typing in a field are settings changes. WCAG 2.1 success criterion 3.2.2 says that changing the setting of any user interface component must not automatically cause a change of context (a new page, a new window, a form submitted, focus moved) unless the user was told about the behavior before using the component.

This protects people who cannot see the whole screen at once, such as screen reader users and people using magnification, and people with cognitive disabilities who need predictable results. It also protects keyboard users: in some browsers, arrowing through a select list fires a change event on every option, so an auto-navigating select can make the later options unreachable.

What is not covered

• Links and buttons that submit a form or move focus are activations, not settings changes, so this criterion does not govern them.
• Content changes that do not change context, such as an expanding menu, a tab panel or results that refresh in place inside the same page, are not violations of this criterion.

Public forms and the ADA angle

Government pages love shortcuts: choose a clinic location from a drop-down and the page jumps to that location, tick "Receive reminders" and the form submits, enter the fifth ZIP digit and the page reloads. A keyboard user who presses the Down arrow in such a select may land on the next option's page and never get to the rest. The DOJ guidance on web accessibility lists inaccessible forms among common barriers; see common barriers.

Web code: location pickers, auto-submit, checkboxes

Clinic location select

<select onchange="location.href = this.value">
  <option value="/clinics/north">North clinic</option>
  <option value="/clinics/south">South clinic</option>
</select>

<label for="clinic">Clinic</label>
<select id="clinic" name="clinic">
  <option value="/clinics/north">North clinic</option>
  <option value="/clinics/south">South clinic</option>
</select>
<button type="button" id="go-clinic">Show clinic</button>
<script>
  document.getElementById("go-clinic").onclick =
    () => location.href = document.getElementById("clinic").value;
</script>

ZIP code that submits itself

zip.addEventListener("input", () => {
  if (zip.value.length === 5) form.submit();
});

<label for="zip">ZIP code</label>
<input id="zip" name="zip" inputmode="numeric" autocomplete="postal-code">
<button type="submit">Find offices</button>

A change that reloads, announced in advance

<select name="cycle" onchange="this.form.submit()">
  <option>Monthly</option><option>Quarterly</option>
</select>

<p id="cycle-note">Changing this reloads the page with new totals.</p>
<label for="cycle">Billing cycle</label>
<!-- Advance notice makes this permitted; a button is still safer for
     keyboard users who arrow through the options. -->
<select id="cycle" name="cycle" aria-describedby="cycle-note"
        onchange="this.form.submit()">
  <option>Monthly</option><option>Quarterly</option>
</select>

Mobile code: SwiftUI and Jetpack Compose

// SwiftUI
Picker("Clinic", selection: $clinic) {
  ForEach(clinics) { Text($0.name).tag($0) }
}
.onChange(of: clinic) { _ in navigateToClinic(clinic) }

// SwiftUI
Picker("Clinic", selection: $clinic) {
  ForEach(clinics) { Text($0.name).tag($0) }
}
Button("Show clinic") { navigateToClinic(clinic) }

// Jetpack Compose
Checkbox(
  checked = remind,
  onCheckedChange = { remind = it; submitPreferences() }  // a violation if this submits or navigates
)

// Jetpack Compose
Row(verticalAlignment = Alignment.CenterVertically) {
  Checkbox(checked = remind, onCheckedChange = { remind = it })
  Text("Send me reminders")
}
Button(onClick = { submitPreferences() }) { Text("Save preferences") }

Test pass for auto-acting controls

1. Use only the keyboard: Tab to each select, radio group, checkbox and text field and change its value. Note anything that navigates, submits, opens a window or moves focus.
2. For selects, use the arrow keys, not the mouse. Browsers differ, so test the ones your audience uses.
3. Check whether a visible instruction before the control says what will happen. If the behavior is announced up front, it is allowed.
4. Code search: onchange, oninput, change and input listeners that call submit, location or window.open.
5. Tools do not understand intent. A checker can find the handler but a person decides if it changes context.

Known traps

• Relying on a tiny line of gray text under the field as "advance notice".
• Auto-submitting on the last character because the format is "known".
• Filtering that rebuilds the whole page and resets focus to the top.
• Radio buttons that open pop-ups when selected.
• Auto-advancing focus between split fields (date, phone, card number) after a set number of characters.

Ship it when

• Every control that leads to a new page, window or submission is activated by an explicit button or link.
• Where a setting does change context, users are told before they reach the control.
• In-page updates keep focus where the user left it.

Sources

• Understanding SC 3.2.2: On Input (W3C), opens in a new tab
• 28 CFR Part 35, Subpart H: Accessibility of Web Information and Services (eCFR), opens in a new tab

Standard version: WCAG 2.1 (W3C Recommendation, 5 June 2018), as named in the Title II web rule. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official ADA statute and regulations, and ask a lawyer how they apply to you.