Don't Surprise Your Users: Predictable Behavior

You're tabbing through a form, reading field labels before you decide what to enter. You tab into a dropdown menu just to see what options are available. The instant it receives focus - before you've even opened it - the page suddenly redirects to a completely different page. You didn't select anything, didn't press Enter, just tabbed through. Now you're disoriented and have to navigate back to find your place.

Or you're using a screen reader to shop online. You select "Sort by Price" from a dropdown to explore your options. Before you can review what you've selected or choose to apply it, the entire page reloads. Your screen reader loses its place, and you have to re-orient yourself to figure out what changed.

These scenarios happen constantly on websites that prioritize perceived convenience over user control. But what feels streamlined to designers creates chaos for many users.

The Standards

WCAG 3.2.1 On Focus (Level A) - When any user interface component receives focus, it does not initiate a change of context.

WCAG 3.2.2 On Input (Level A) - Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior beforehand.

In simple terms: receiving focus shouldn't trigger actions, and changing form values shouldn't automatically submit or navigate. Users need to explicitly confirm their choices.

What Is a "Change of Context"?

Not all changes violate these standards. A "change of context" is a major change that can disorient users:

Opening a new window or tab
Moving focus to a different component
Navigating to a new page
Significantly rearranging content in a way that changes the meaning or overall layout

What Doesn't Count as Context Change

These are normal, expected behaviors that don't violate the standards:

Expanding a dropdown menu when focused
Showing/hiding content (accordions, tabs)
Displaying tooltips or help text
Updating search suggestions as you type
Showing form validation messages
Highlighting or styling focused elements

The key difference: these changes happen within the current context and don't disorient users or move them somewhere unexpected.

On Focus: Don't Trigger on Tab

When users navigate with Tab or click into a form field, nothing should happen automatically. Focus is for navigation and exploration, not for triggering actions.

Common On Focus Violations

Auto-Opening Dialogs

Some forms open help dialogs or tooltips automatically when fields receive focus. This is problematic because keyboard users tabbing through a form don't expect dialogs to pop up just from focusing a field. Help should be available through an explicit button or link, not triggered automatically by focus.

Links That Open on Focus

Links that use onfocus events to open new windows or trigger navigation create confusion for keyboard users who are simply tabbing through the page to explore. Focus should never trigger actions - only explicit activation (clicking or pressing Enter) should.

Forms That Submit on Focus

Some forms attempt to be "smart" by submitting automatically when the last field receives focus, assuming the user is done. This breaks keyboard navigation entirely - users can't explore the form structure or review fields without accidentally submitting.

Why On Focus Violations Are Problematic

Keyboard users explore by tabbing - They need to navigate through all elements to understand options before taking action
Screen reader users navigate sequentially - They often tab through to get an overview before interacting
People using magnifiers have limited view - Sudden context changes are especially disorienting when you can't see the whole page
Touch screen users may accidentally focus elements - A slight touch shouldn't trigger major actions

On Input: Don't Auto-Submit or Navigate

When users interact with form controls - selecting options, checking boxes, typing values - don't automatically submit forms or navigate to new pages. Let users review their choices and explicitly confirm.

Dropdown Navigation Menus

One of the most commonly questioned patterns is the dropdown navigation menu - a select element that navigates to different pages when you choose an option.

Good news: native HTML <select> elements actually handle this reasonably well in modern browsers. When you use arrow keys to navigate through options, the onchange event doesn't fire until you press Enter, click an option, or tab away from the select.

However, there are still issues:

Tabbing away commits the change - If you're exploring options and tab to the next element, the currently highlighted option triggers navigation
Screen reader behavior varies - Some screen readers in forms mode may trigger changes differently
Mobile behavior differs - Mobile browsers often use native pickers with different interaction patterns
Custom select widgets are often worse - Styled dropdowns built with divs and JavaScript frequently trigger on every arrow press

Best practice remains: provide an explicit "Go" button next to the select. This gives users full control to explore options without worrying about accidental navigation. It's one extra button that eliminates all ambiguity.

E-Commerce Filters That Auto-Submit

Many e-commerce sites reload the page every time you check a filter box. The problem: users want to select multiple filters at once - "In Stock" AND "On Sale" AND "Free Shipping" - but the page reloads after each selection, losing their place and requiring screen readers to re-announce everything.

The issue is using onchange events on checkboxes to submit the form immediately. Instead, let users select all the filters they want, then click an "Apply Filters" button to see results.

This same pattern applies to:

Price range sliders that reload on every adjustment
Size/color selectors that refresh immediately
Rating filters that auto-submit

Radio Buttons That Auto-Submit

Radio button groups are particularly problematic for auto-submission because users navigate them with arrow keys. When each arrow press triggers a form submission or page reload, users can't explore their options - the first arrow press commits them to an action.

Common examples:

Quantity selectors in shopping carts
Shipping method options that reload to show updated totals
Survey questions that advance immediately on selection

The issue is using onchange on radio inputs. Always provide an explicit submission button for radio groups.

Language/Currency Switchers

Language and currency switchers often use dropdowns with onchange events that immediately reload the page with the new selection. While native selects handle keyboard navigation reasonably well, users still can't review their selection before the page reloads - and if they accidentally tab away while exploring options, they trigger an unwanted language change.

Better approaches:

Add a "Change Language" button next to the dropdown
Use individual links for each language option instead of a dropdown
For currency switchers on e-commerce sites, let users change it from their account settings rather than on every page

Sort Order Dropdowns

Product listing pages often have dropdowns for sorting (by price, popularity, newest, etc.) that reload the page immediately when you select an option. While you can usually navigate through the options with arrow keys without triggering a reload, the page refreshes as soon as you tab away or press Enter.

This creates problems for screen reader users who lose their place in the results when the page reloads. Adding a "Sort" or "Apply" button gives users explicit control and prevents accidental reloads from tabbing.

The "Unless Warned" Exception

WCAG 3.2.2 includes an important caveat: automatic context changes are allowed "unless the user has been advised of the behavior beforehand."

This means you could technically have a dropdown that auto-submits if you clearly warn users first: "Navigate to page (will load immediately upon selection)."

However, this is still not ideal. Even with a warning:

The behavior still creates problems for keyboard navigation in some browsers
Screen reader users might miss or not fully process the warning
Custom select widgets often behave worse than native selects
Tabbing away still commits changes unexpectedly

Best practice: just add a button. It's clearer, more predictable, and works better for everyone.

What About Real-Time Updates?

Some scenarios genuinely benefit from immediate feedback:

Search Suggestions (OK)

Showing search suggestions as you type doesn't violate these standards - you're updating content within the same context, not navigating or moving focus.

Live Form Validation (OK)

Showing validation messages as users complete fields is fine, as long as it doesn't move focus or navigate. Updating an error message or showing a checkmark next to a valid field is helpful feedback that doesn't violate these standards.

Character Counters (OK)

Showing remaining characters as users type is helpful and doesn't violate these standards.

Price Calculators (OK)

Updating a total as users adjust quantity is fine - it's changing displayed content, not context.

Predictable Behavior in Drupal and WordPress

Drupal

Drupal's Form API doesn't add automatic submission by default, which is good. Watch out for:

Contrib modules - Some add JavaScript that auto-submits filters or options
Views exposed filters - By default require clicking "Apply," but can be configured to auto-submit
Commerce facets - Some faceted search modules auto-reload on selection
Custom JavaScript - Developers might add auto-submit behavior thinking it's helpful

If you're configuring Views or Commerce: resist the temptation to enable "Auto-submit" options. They seem convenient but create accessibility barriers.

WordPress

WordPress core forms don't auto-submit, but watch for:

WooCommerce sorting/filtering - Some themes or plugins add auto-reload on selection
Page builders - Elementor, Divi, and others might include form widgets with auto-submit
Navigation menus - Some themes use dropdown menus that navigate on select
Plugin settings pages - Some auto-save on change without confirmation

Testing Predictable Behavior

Test with keyboard only - Tab through your entire site. Does anything unexpected happen when elements receive focus?
Test all form controls - Change dropdowns, radio buttons, checkboxes. Does anything auto-submit or navigate?
Use arrow keys in dropdowns - Navigate through options. Does it trigger actions before you press Enter?
Test with screen reader - Does the page ever suddenly navigate or reload without your explicit action?
Check for warnings - If anything does auto-submit, is it clearly warned beforehand?
Test filters and sorting - Can you select multiple options before applying changes?

The Bottom Line

Predictable behavior is about user control and respect. Users should be able to explore options, navigate through interfaces, and review their choices before committing to actions. Auto-submission might seem convenient, but it removes this control and creates barriers.

The fix is almost always simple: add a button. "Go," "Apply," "Submit," "Update" - one extra click that gives users the control they need. Yes, it's an extra step. But that step is the difference between a frustrating experience and an accessible one.

Don't surprise your users. Let them explore safely. Give them explicit control over navigation and submission. These are Level A requirements - the most fundamental level of accessibility - because they affect everyone who navigates with a keyboard or uses assistive technology.

Before adding auto-submit behavior to save users one click, ask yourself: who am I really saving time for? Often it's not users - it's designers who want fewer visible buttons. Choose accessibility over aesthetics. Add the button.