In short and in plain language
Many shops have pick lists. For example: sort by price. Some lists load a new page as soon as you pick something else.
People who do not use a mouse move through the list with the arrow keys. Then the page loads again after the first key press. They cannot reach the choice they want.
The rule for this is called WCAG 3.2.2. It says: a choice in a list must not just change the page. The page may only do this if it tells you first.
A good fix is a button next to the list. First you choose, then you press the button. Then the page loads just once.
Test your lists with the keyboard. Test them with a screen reader too. A test tool alone will rarely find this problem.
A customer opens the “Desk lamps” category, tabs to the “Sort by” menu and presses the down arrow once to look at the options. Before she reaches “Price: high to low”, the page reloads, focus is back at the top of the page, and the sort order now reads “Newest”, a choice she did not mean to make. This exact sequence is what WCAG success criterion 3.2.2 On Input addresses: changing the value of a control must not send people into a different context without warning (W3C, Understanding SC 3.2.2). The criterion sits at the lowest conformance level, A, and in online stores it mostly concerns select menus: sorting, language and country selection, variants and quantity fields. This article explains what counts as a change of context, walks through four typical store patterns and three clean fixes, and shows how to test the criterion with keyboard and screen reader.
Key takeaways
- SC 3.2.2 On Input (Level A) requires that changing a control does not trigger a change of context without prior notice, which means no new page, no new window and no focus jump (W3C, Understanding SC 3.2.2).
- In a survey of 1,539 screen reader users, screens that change unexpectedly rank fourth of 12 among the most problematic barriers (WebAIM Screen Reader User Survey #10).
- Typical store patterns that fail: a sort menu reloads on the first arrow key, a language menu redirects at once, a variant menu loads a new URL, the last field submits the form by itself (W3C, F36, F37).
- A proven fix is an Apply button next to the menu (W3C, H84, G80); alternatives are announcing the behavior in advance (W3C, G13) or updating content only, without changing the context (W3C, SCR19).
- Tools alone fall short: of 143 built-in barriers, ten testing tools combined missed 42 (GDS 2017). You test 3.2.2 with keyboard and screen reader, one arrow key at a time.
- Online stores selling to consumers have been covered by the BFSG since June 28, 2025, micro-enterprises excepted; EN 301 549 V3.2.1, currently the reference standard, requires SC 3.2.2 in clause 9.3.2.2 (ETSI, EN 301 549 V3.2.1).
What On Input requires
The wording of the criterion is short: changing the setting of any user interface component must not automatically cause a change of context unless the user has been advised of the behavior before using the component (W3C, Understanding SC 3.2.2). SC 3.2.2 is Level A. A website that is meant to meet WCAG 2.2 at Level AA therefore has to satisfy it, because AA includes every Level A criterion. Its sibling is SC 3.2.1 On Focus, also Level A: merely moving focus to a component must not initiate a change of context either (W3C, Understanding SC 3.2.1).
The key distinction is between “changing a setting” and “activating”. Checking a checkbox, typing into a text field or choosing another option in a list changes a setting; activating a link or a button does not (W3C, Understanding SC 3.2.2). A button that submits a form and takes the user to a new page is therefore not a 3.2.2 case. A select menu that does the same thing as soon as the option changes is. According to the Understanding document, toggle buttons with aria-pressed also count as settings, because they keep a state.
The WCAG glossary defines a change of context as a major change that can disorient users who cannot view the entire page at once if it happens without their awareness. It covers changes of user agent, viewport, focus, or content that changes the meaning of the page. The definition lists opening a new window, moving focus to a different component, going to a new page, including anything that would look to a user as if they had moved to a new page, and significantly re-arranging the content of a page as examples (W3C, Understanding SC 3.2.2).
A change of content is not automatically a change of context
Why unexpected changes hurt so much
Anyone who can see the page notices a reload immediately. People who use a screen reader or heavy magnification often only notice that something different is suddenly being read out, or that the visible section has moved. The Understanding document for 3.2.2 states that unexpected changes of context can be so disorienting for users with visual disabilities or cognitive limitations that they may be unable to use the content (W3C, Understanding SC 3.2.2).
The people affected see it the same way. WebAIM ran its tenth screen reader user survey in December 2023 and January 2024 (WebAIM Screen Reader User Survey #10) and received 1,539 (WebAIM Screen Reader User Survey #10) valid responses. “Screens or parts of screens that change unexpectedly” rank fourth of 12 (WebAIM Screen Reader User Survey #10) among the most problematic items. Second place (WebAIM Screen Reader User Survey #10) goes to interactive elements like menus, tabs and dialogs that do not behave as expected, which is exactly the category custom dropdowns fall into. According to WebAIM, the order of the list has stayed largely unchanged for 14 years (WebAIM Screen Reader User Survey #10). The sample was not controlled and does not represent all screen reader users, but the ranking shows where everyday use breaks down.
For people who work with the keyboard, a select menu that acts immediately becomes a trap. With some form elements, the value already changes while the user moves through the options with the keyboard (W3C, F36). Technique H84 therefore stresses that a separate trigger is particularly important for people who choose the value of a select element via the keyboard (W3C, H84). Failure F36 describes the consequence for a select menu that submits the form on change: keyboard users cannot get past the first item, and blind users or users with hand tremors easily end up at the wrong destination before they can correct the mistake (W3C, F36).
How many people this affects can only be estimated. At the end of 2025, a little over 7.8 million (Destatis) people with severe disabilities lived in Germany. For 10 percent (Destatis) of them, the function of arms or legs was impaired, 4 percent (Destatis) were blind or had a visual impairment, and 16 percent (Destatis) had intellectual or mental disabilities. The statistics only cover officially recognized severe disabilities and say nothing about who uses which input aid. They do show, however, that the groups 3.2.2 was written for are not a fringe audience.
Then there is the sheer number of form controls. The WebAIM Million 2026 analyzes the home pages of the top one million websites (WebAIM Million 2026) and counts an average of 6.9 (WebAIM Million 2026) form inputs per page, 36 percent (WebAIM Million 2026) more than three years earlier. Home pages in the Shopping category show 71.0 (WebAIM Million 2026) automatically detected errors, 26.6 percent (WebAIM Million 2026) above the average for all home pages. The study does not measure category or product pages, and that is exactly where sorting, filters and variant selection live.
Four store patterns that fail 3.2.2
The following four patterns typically come up in online store audits. What they share is a change or input event that triggers more than a content change: a new page, a new URL, a new window or a focus jump.
The sort menu reloads on the first arrow key
The most common pattern is the sort menu on the category page that immediately loads a new URL with a sort parameter via onchange="this.form.submit()" or a script. With a mouse, nobody notices: open the list, click an option, done. With the keyboard, the step from “Relevance” to “Newest” can already trigger the page change, and after the reload focus is back at the top of the page. Anyone who wants to go three options further needs three attempts and three reloads, as the mockup above shows. This exact combination, submitting on an option change without warning, is the failure example in F36 (W3C, F36).
Language or country selection redirects at once
A select menu in the header or footer that immediately redirects to the English version or the Austrian store when changed is a classic change of context: a new page, often a new language, sometimes new prices. Technique G13 uses exactly this example, a menu with German, French and Spanish, and considers it acceptable if instructions before the menu announce that the language changes when an option is selected (W3C, G13). Without that notice, the pattern fails. With the notice, it remains tedious for keyboard users, because depending on the browser even moving through the options switches the page.
The variant menu changes the URL
Many product pages offer color or size as a select menu and load the variant URL when it changes, with a new image, a new price and a new history entry. On screen this is a small change; for the browser it is a page change: focus starts at the top again, and the back button leads to the previous variant instead of the category. If variants are built as radio buttons that reload on change, a second problem appears. F37 notes that in current user agents a group of radio buttons cannot be navigated with the keyboard without triggering a change event at every step, and that such a pattern would still likely fail SC 2.1.1 Keyboard even with a warning (W3C, F37). How to make variant selection accessible as a whole is covered in the article on the accessible product page.
The quantity field or last field submits
In the cart, some quantity fields refresh the whole page on blur or even on input, and multi-part entries such as a phone number split across three fields submit the form as soon as the last field is filled. F36 describes exactly that: a form that submits when the user leaves the last field, even when just tabbing backward. It recommends a submit button or the standard behavior of submitting with the Enter key instead (W3C, F36). An automatic move to the next field, on the other hand, is acceptable if the behavior is described at the beginning of the form. That is the second example in the Understanding document (W3C, Understanding SC 3.2.2). Error handling in forms like these is covered in the article on accessible forms.
| Pattern | What happens | Change of context? | Clean fix |
|---|---|---|---|
Sort menu with onchange submit | new page on every option change | yes, a failure without warning (F36) | Apply button (H84, G80) |
| Language menu with instant redirect | new language version, focus at top | included | button, list of links or a notice before the menu (G13) |
| Variant menu loads variant URL | new page, focus at top, new history entry | included | update image and price in place, keep focus in the menu |
| Radio buttons open a window | new window on every arrow key | yes, a failure without warning (F37) | button, no new window |
| Last field submits the form | submit on leaving the field | yes, a failure without warning (F36) | submit button and Enter key |
| Shipping country fills shipping methods | second menu gets new options | no, if that menu follows (SCR19) | keep it, announce the result via status message |
Fix 1: the Apply button
A simple fix has proven itself: the select menu only changes its value, and a separate button triggers the action. Technique G80 recommends a submit button for every change of context, because its intended purpose is to send a request with the form data and it therefore does not confuse anyone (W3C, G80). Technique H84 applies that to select menus: users can inspect the different values or accidentally choose the wrong one without anything happening, and they trigger the action once they are satisfied with their choice (W3C, H84).
<!-- Change on input: every option change reloads the page -->
<form action="/lamps/" method="get">
<label for="sort-bad">Sort by</label>
<select id="sort-bad" name="sort" onchange="this.form.submit()">
<option value="relevance">Relevance</option>
<option value="newest">Newest</option>
<option value="price-asc">Price: low to high</option>
<option value="price-desc">Price: high to low</option>
</select>
</form>
<!-- Change on request: choose first, then apply -->
<form action="/lamps/" method="get">
<label for="sort">Sort by</label>
<select id="sort" name="sort">
<option value="relevance">Relevance</option>
<option value="newest">Newest</option>
<option value="price-asc">Price: low to high</option>
<option value="price-desc">Price: high to low</option>
</select>
<button type="submit">Apply</button>
</form>The pattern has side effects that benefit everyone. Without JavaScript it works as a plain GET form, the sort order ends up as a parameter in the URL and can be shared, and mouse users also choose first and load once. The button needs a visible, unambiguous label such as “Apply” or “Apply sorting”; a bare arrow icon without an accessible name creates the next problem. Showing the button only to keyboard users is not a good idea: people with hand tremors, who easily hit the wrong option with a mouse, also benefit when a choice takes effect only after confirmation (W3C, F36).
The test procedure of the technique is correspondingly simple: focus on an option, including keyboard focus, must not trigger any action, and the button must perform the action for the currently selected value (W3C, H84). Build the pattern once as a component, and the topic is settled for every sort, quantity and filter bar in the store.
Fix 2: announce the behavior in advance
Where a button is not an option, the criterion allows a second route: announcing the behavior in advance. Technique G13 expects the explanation to precede the control in reading order and advises associating it with the control programmatically where possible (W3C, G13). In HTML this is done with aria-describedby; the screen reader then typically reads the notice together with the name and role of the menu.
<!-- The hint comes before the menu and is associated with it -->
<p id="lang-hint">The page switches to the selected language immediately.</p>
<label for="lang">Language</label>
<select id="lang" aria-describedby="lang-hint">
<option value="/de/">Deutsch</option>
<option value="/en/" selected>English</option>
<option value="/fr/">Français</option>
</select>A line of small print at the bottom of the page, a tooltip that only appears on mouse hover, or a sentence in the accessibility statement do not do the job: the explanation has to be available before the control is used (W3C, G13). The announcement makes a pattern conform; it does not make it more convenient. A keyboard user moving through a language list with an instant redirect will, depending on the browser, still be taken off the page after the first arrow key, only now with advance notice. For language and country selection we therefore also recommend a button or a list of real links in which each language is its own link. Activating a link does not change a setting and therefore does not fall under 3.2.2 (W3C, Understanding SC 3.2.2).
Fix 3: update content, keep the context
Not every reaction to a selection has to wait for a button. Technique SCR19 shows two connected select menus: choosing a continent in the first fills the second with matching countries, and explicitly does not cause a change of context (W3C, SCR19). SCR19 highlights one condition: the modified menu comes after the triggering menu in reading order, so that assistive technologies pick up the new data when the menu receives focus (W3C, SCR19). In a store, this corresponds to the shipping country filling the list of shipping methods, or the customer type revealing a field for the company name.
<!-- Content changes, context stays: the second menu follows in reading order -->
<label for="country">Shipping country</label>
<select id="country" name="country">
<option value="DE">Germany</option>
<option value="AT">Austria</option>
<option value="CH">Switzerland</option>
</select>
<label for="shipping">Shipping method</label>
<select id="shipping" name="shipping">
<!-- repopulated when the shipping country changes -->
</select>
<p role="status" id="shipping-status"></p>
<!-- after repopulating, the script sets e.g. "Shipping methods for Austria loaded" -->Sorting without a reload is trickier. If a script reloads the product list in the background and keeps focus in the menu, the URL stays the same and no window opens. But the WCAG definition also counts significantly re-arranging the content of a page as a change of context (W3C, Understanding SC 3.2.2), and a completely re-sorted result list is hardly anything else. There is also the practical effect: every arrow key rebuilds the list, and screen readers may announce new content each time. Even for sorting without a reload, the Apply button is therefore the more reliable choice.
If you update content without moving focus, announce the result. Success criterion SC 4.1.3 Status Messages (Level AA) lists short texts such as “18 results returned” or “No results returned” as examples that count as status updates as long as they do not take focus or cause a page refresh (W3C, Understanding SC 4.1.3). An element with role="status" that reports “Shipping methods for Austria loaded” or the new result count after the update meets that requirement. How live regions work in detail is covered in the article on ARIA roles, states and live regions; filters and result announcements on the category page are covered in the article on accessible product search.
Custom dropdowns: when selection follows focus
Many stores replace the native select with custom components: a button that opens a list with role="listbox", or a combobox with a search field. That does not change the principle of 3.2.2, but it does change the pitfalls. For single-select listboxes, the ARIA Authoring Practices Guide describes the model known as “selection follows focus”: when focus moves to an option with the arrow key, that option is selected as well. According to the APG, this can be very helpful in some circumstances and can severely degrade accessibility in others (W3C, ARIA Authoring Practices Guide).
For sort and language lists, this means: arrow keys only move the highlight, Enter or Space puts the option into the field, and only the button triggers the page change. The Understanding document for SC 3.2.1 draws the same line for leaving a jump menu: if the user presses Escape or Tab to move out of the list, it does not jump to a new page, focus simply leaves the menu (W3C, Understanding SC 3.2.1). Which keys a custom listbox has to support overall is described in the article on keyboard navigation; how to build such components cleanly once and reuse them across the store is covered in the article on the accessible design system.
Testing with keyboard and screen reader
Automated testing tools barely detect 3.2.2, because whether a change event loads a new page only shows when the control is operated. The WebAIM Million points out that all automated tools have limitations and that not all conformance failures can be detected automatically (WebAIM Million 2026). When the UK Government Digital Service ran ten tools against a test page with 143 (GDS 2017) built-in barriers, the tools combined missed 42 (GDS 2017) of them, which is 29 percent (GDS 2017). The W3C puts it in principle: evaluation tools cannot determine accessibility, they can only assist in doing so (W3C WAI). For 3.2.2, manual testing remains, template by template.
- Collect the controls: on every template, meaning category, product, cart, checkout as well as header and footer, note all select menus, radio buttons, checkboxes and multi-part inputs.
- Tab in: focus the control with the Tab key without opening the list. No change of context may occur at this point, otherwise SC 3.2.1 fails.
- Press an arrow key once: in the closed menu, press the down arrow once. If the page loads, the URL changes, focus jumps or a window opens, that is a change of context.
- Browse the open list: open the list (on Windows usually with Alt and the down arrow), move through several options and close it with Escape. The context must not change here either.
- Look for a notice: if the context changes on purpose, a notice must precede the control and be read out as well, ideally associated via
aria-describedby. - Repeat with a screen reader: listen to the name, role and current value, choose an option and check whether the result is announced without focus moving.
- Cross-check on mobile: on a smartphone the options usually appear in a system view; check whether scrolling through the options or only confirming the choice triggers the action.
If you first want an overview of your own website without special tools, the BFSG self-check offers more checks of this kind. Which testing methods exist and how they work together is covered in the article on accessibility testing. To check what your select menus pass on to screen readers in the desktop and smartphone layouts, we offer a dedicated screen reader test.
The test question for every select menu
3.2.2 in the BFSG context
The German Accessibility Strengthening Act (BFSG) applies to services provided to consumers after June 28, 2025, including services in electronic commerce (BFSG). The ordinance under the act requires websites, including the related online applications, to be perceivable, operable, understandable and robust in a consistent and adequate way (BFSGV, § 12). Micro-enterprises that offer or provide services are exempt from this obligation (BFSG, § 3). If you want to go through the requirements for your own store systematically, our page on the BFSG requirements covers the basics.
Harmonized standards describe how to meet the requirements technically: services that conform to harmonized standards whose references have been published in the Official Journal of the EU are presumed to meet the requirements of the ordinance to the extent the standard covers them (BFSG, § 4). The EU center AccessibleEU names EN 301 549 V3.2.1 from 2021 as the current reference until the Commission cites version V4.1.1, published in September 2026, in the Official Journal (AccessibleEU). V3.2.1 requires in clause 9.3.2.2 that web pages satisfy success criterion 3.2.2 of WCAG 2.1 (ETSI, EN 301 549 V3.2.1); the new version moves to WCAG 2.2 (AccessibleEU). Anyone who offers or provides a service contrary to § 14 (1) BFSG commits an administrative offense (BFSG, § 37), which can be punished with a fine of up to 100,000 euros (BFSG, § 37). A single select menu looks small, but it sits on every category page.
SC 3.2.5 Change on Request at Level AAA goes beyond 3.2.2: changes of context are initiated only by user request, or a mechanism is available to turn them off (W3C, Understanding SC 3.2.5). Conformance with WCAG 2.2 AA does not require AAA. If you build select menus with a button anyway, you reach that goal for these controls along the way, and SCR19 is explicitly listed as a sufficient technique for 3.2.5 as well (W3C, SCR19).
From single finding to component rule
In an audit, 3.2.2 rarely shows up as a single finding. Usually the behavior lives in a shared component or a theme script that binds every select menu to a page change via change, and then every category, search and brand page is affected. The fix therefore belongs in the component: a select menu with a button as the default, a documented exception for dependent menus under SCR19 and a status message for every update without a reload. The same applies to checkout, where shipping country, shipping method and payment method often depend on each other; what else matters there is covered in the article on accessible checkout.
The rule also belongs in the acceptance criteria: which keys do what, when an action fires and which text is announced. With external vendors it also goes into the contract. In the WCAG audit we map every finding to the criterion and the template, in accessible web development we rebuild the component in your existing code, and in training we pass the test steps on to your team. For an overview of everything a store has to provide for customers with disabilities, see our page on the accessible shop.
Sources
onchange event on a select menu that repopulates a second menu following it in reading order, without causing a change of context (W3C, SCR19). It only becomes a problem when the script loads a new page, opens a window, moves focus or significantly re-arranges the page content. Updates without a focus change are announced with a status message (W3C, Understanding SC 4.1.3).Related Articles
BFSG Self-Check: What Site Owners Can Test Without Tools
Eight browser checks with no extra software: keyboard, zoom, images, title, headings, contrast, forms and video, plus where a self-check reaches its limit.
Accessible Promo Banners: Keep Text Out of the Image
Promo banners with discount text baked into the image fail WCAG 1.4.5. How shops build banners as HTML text, apply the exceptions and test before Black Week.
AI-Generated Code: What Accessibility Testing Finds
What accessibility testing finds in AI-generated code: four typical patterns, from div buttons to removed focus outlines, and how testing fits the workflow.