3.2.1 On Focus

1. What is the goal of this criterion?

Some websites behave like an overeager hotel concierge: the moment you touch something, something else happens. You tab into an input field and a new window pops open, or you move through a form and suddenly get thrown onto a different page.

People who navigate with a keyboard or assistive technologies are hit hardest by these unpredictable jumps. They lose their bearings, don’t know where they’ve ended up, or have to work their way back step by step.

That’s why the goal of WCAG Success Criterion 3.2.1 is simple: when an element receives focus, that alone must not trigger a change of context. Navigation should stay predictable and under the user’s control.

2. What exactly does it require?

In concrete terms: when a user interface component receives focus – for example via the Tab key or by tapping into an input field – this must not start a change of context.

Not allowed on focus:

• Forms are submitted automatically
• New windows or tabs open
• Modal dialogs open and grab focus
• Focus is moved automatically to another element
• The page changes automatically

Allowed on focus:

• Content expands (e.g. a submenu in the navigation)
• Help text or tooltips appear
• Visual changes such as focus outlines or highlighting

Important: this is about focusing, not activating. When you click an element or activate it with Enter, things are allowed to happen – just not on focus alone.

A practical example: a submenu expands as soon as its top-level menu item receives focus – that’s fine. But it must not pull focus into the submenu items on its own or send you straight to the linked page while you’re tabbing through.

3. Why does it matter for accessibility?

Imagine navigating a website without sight when suddenly everything changes – and you have no idea why or where you are now. Or imagine you have a motor impairment, are working your way through a form with real effort, and end up on a different page you never asked for.

Predictable navigation supports accessibility because it:

• helps people with visual impairments keep their bearings and understand what’s happening
• reduces the load on people with cognitive disabilities who rely on consistent, predictable flows
• protects people with motor impairments who can’t react quickly when something changes unexpectedly
• keeps keyboard users in control of their navigation
• spares screen reader users from confusing jumps

And last but not least: predictability makes websites more pleasant for everyone – including people without disabilities who simply want an interface they can rely on.

4. How to meet the criterion

The good news: meeting this criterion is often a matter of leaving things out – namely unwanted automatic actions. Here are some proven tips:

What to avoid:

• Submitting a form automatically as soon as you leave a field and the next one receives focus
• Automatic redirects when a link or button receives focus
• New windows or modal dialogs that open on focus
• Scripts that immediately take focus away again or move it somewhere else

What to do instead:

• Only trigger changes of context through deliberate activation: click, Enter, Space or a submit button
• For navigation menus: submenus may expand on focus, but the page only changes on activation
• Offer help text that appears on focus without stealing it – and that follows the rules of Content on Hover or Focus
• Make it clear when an action will lead to a change of context

Technical implementation:

• Don’t attach changes of context to focus or focusin events; use click or the form’s submit event instead
• Be careful with change events too: if they trigger a page change, you can easily fail On Input
• Connect help text with aria-describedby rather than opening it as a dialog that pulls focus away
• Build autocomplete so that focus stays in the input field until someone deliberately picks a suggestion

Tools and testing:

• Navigate your entire website with the keyboard – Tab and Shift+Tab through every control
• Test with screen readers such as NVDA or VoiceOver
• Make sure focusing alone never changes the page, the window or the focus position

5. Why this criterion matters for businesses

With Success Criterion 3.2.1, too, accessibility isn’t an end in itself – it brings tangible benefits for your business.

1. Better usability for everyone

Predictable navigation reduces frustration – not only for people with disabilities. When your website feels controllable, people stay on task and are happy to come back.

2. Fewer drop-offs in forms and checkouts

Unexpected actions on focus pull people out of forms and purchase flows. Predictable interactions increase the chance that they complete what they came to do.

3. Stronger trust and brand image

Accessible navigation shows that you respect your users and think of everyone. That builds trust in your brand.

And then there’s the legal side: since 28 June 2025, the European Accessibility Act (Directive (EU) 2019/882) has applied to many consumer-facing digital services, such as online shops and banking services. Germany implements it through the Barrierefreiheitsstärkungsgesetz (BFSG). The technical benchmark is the harmonised standard EN 301 549, which refers to WCAG 2.1 Level AA for web content – and 3.2.1 is part of that. Public sector bodies are covered separately by the Web Accessibility Directive (EU) 2016/2102. This section is general information, not legal advice.

6. The success criterion in the W3C’s words

Success Criterion 3.2.1 On Focus (Level A)

When any user interface component receives focus, it does not initiate a change of context.

In short: a control receiving focus must not, by itself, trigger a change of context such as a new page, a new window or a focus jump.