Category: WCAG Principles and Conformance

On Focus

Also known as: onfocus, onfocus event, focus event

Simply put

"On focus" refers to the moment an interactive element on a web page, such as a text field, button, or link, receives focus, meaning it becomes the active element ready to accept keyboard input or interaction. This commonly happens when a user clicks an element, tabs to it with the keyboard, or when a screen reader moves to it. In accessibility contexts, what happens when an element receives focus matters because unexpected changes at that moment can disorient users.

Formal definition

"On focus" describes the point at which a user interface element gains focus, corresponding to the DOM 'focus' event exposed in HTML as the 'onfocus' event handler, a DOM Level 2 (2001) feature commonly used on form input elements. Focus can be received through pointer activation, keyboard navigation (for example, via the Tab key), or programmatically. In web accessibility practice, behavior triggered on focus is relevant to WCAG Success Criterion 3.2.1 On Focus (Level A, present since WCAG 2.0), which provides that receiving focus should not initiate an unexpected change of context; note that this evidence packet does not include the WCAG source text, so practitioners should consult the W3C's published WCAG documentation for the authoritative criterion wording. This entry is informational and not legal advice.

Why it matters

What happens the instant an element receives focus can determine whether a page is usable for people who navigate by keyboard or with a screen reader. Because focus can move as a user tabs through a page or as assistive technology advances through interactive elements, any behavior triggered at that moment affects every user who does not rely on a mouse. If receiving focus causes something unexpected to occur, users who cannot easily perceive or predict the change may become disoriented or lose their place.

This concern is reflected in WCAG Success Criterion 3.2.1 On Focus (Level A), which has been present since WCAG 2.0 and addresses the principle that receiving focus should not initiate an unexpected change of context. Because 3.2.1 is a Level A criterion, it sits at the most fundamental conformance tier, and behaviors that violate it can create significant barriers. Note that this evidence packet does not include the WCAG source text; practitioners should consult the W3C's published WCAG documentation for the authoritative wording of the criterion.

Designing and testing focus behavior is a matter of usability as much as conformance. Meeting a single success criterion does not guarantee an accessible experience overall, and automated tools detect only a portion of focus-related issues; manual keyboard testing and testing with assistive technology are generally needed to confirm that focus behaves predictably. This entry is informational and not legal advice.

Who it's relevant to

Front-End Developers

Developers who attach behavior to the onfocus event handler need to ensure that gaining focus does not trigger an unexpected change of context. Because focus can be received through pointer activation, keyboard navigation, or programmatically, scripts that respond to focus should behave predictably across all of these methods.

UX Designers

Designers who specify how forms and interactive controls respond as a user moves through them influence what occurs on focus. Predictable focus behavior supports users who navigate by keyboard or with a screen reader, for whom an unexpected change at the moment of focus can be disorienting.

Accessibility Engineers and QA Testers

Those evaluating a page against WCAG Success Criterion 3.2.1 On Focus (Level A) should verify focus behavior through manual keyboard testing and testing with assistive technology, since automated checks capture only a portion of focus-related issues. Consult the W3C's published WCAG documentation for the authoritative criterion wording.

Users of Keyboards and Assistive Technology

People who tab through a page or rely on a screen reader move focus from element to element as their primary means of interaction. Predictable behavior on focus directly affects their ability to complete tasks without losing their place or being disoriented by unexpected changes.

Inside On Focus

On Focus (WCAG Success Criterion 3.2.1)

A WCAG 2.0 Level A success criterion stating that when any user interface component receives focus, it does not initiate a change of context. This criterion carries forward through WCAG 2.1 and 2.2.

Receiving Focus

The moment a component becomes the active element for user interaction, whether by keyboard navigation (such as tabbing), assistive technology, or other input. Focus can move without the user intending to activate the component.

Change of Context

As defined by WCAG, major changes that, if made without user awareness, can disorient users. Examples commonly cited include changes of user agent (such as opening a new window), changes of viewport, changes of focus, or substantial changes to content that alter the meaning of the page.

Focus vs. Activation

The criterion concerns focus alone, not activation. A user moving focus onto a control (for example by tabbing to it) should not trigger a context change; a deliberate activation (such as pressing Enter or clicking) is handled by separate considerations, notably On Input (3.2.2).

Relationship to On Input (3.2.2)

On Focus addresses context changes triggered by focus, while On Input addresses context changes triggered by changing a setting of a component. The two are distinct but complementary predictability criteria within WCAG Guideline 3.2.

Common questions

Answers to the questions practitioners most commonly ask about On Focus.

Does the On Focus success criterion require that nothing change when an element receives focus?

No. The criterion does not prohibit all changes when a component receives focus. It addresses changes of context specifically, such as automatically opening a new window, moving focus to a different component, or otherwise substantially reorganizing the page in a way that could disorient users. Ordinary changes that do not amount to a change of context, such as visible focus indicators or revealing associated help text without moving focus, are generally acceptable.

Is On Focus the same requirement as On Input?

No, they are distinct success criteria that are often confused because both deal with predictable behavior. On Focus concerns what happens when a user interface component simply receives focus, while On Input concerns what happens when a user changes the setting of a component, such as selecting a value or checking a box. They address different triggers, and meeting one does not automatically satisfy the other.

How can I let a component do something useful when it receives focus without failing On Focus?

The general approach is to avoid triggering a change of context on focus alone and instead tie substantive actions to an explicit user action, such as activating a button or confirming a selection. If you want to surface additional information when focus arrives, do so in a way that does not move focus elsewhere or reorganize the page unexpectedly, so the user retains control and orientation.

How do I test whether a page meets On Focus?

Manual keyboard testing is central: move focus through each interactive component using the keyboard alone and observe whether focus arriving on any element causes a change of context, such as a new window opening or focus jumping to another location. Automated tools may flag some patterns but generally cannot reliably detect changes of context, so manual and assistive technology testing are needed to confirm behavior.

What common design patterns tend to fail On Focus?

Patterns that automatically launch a new window or dialog when a field receives focus, automatically submit a form on focus, or programmatically shift focus to another component upon receiving focus can result in failures. Because these behaviors occur without a deliberate activating action from the user, they may constitute an unexpected change of context.

Which WCAG conformance level includes On Focus, and does meeting it ensure my site is accessible or legally compliant?

On Focus is commonly cited at Level A, and AA is the level most frequently referenced as a conformance target, which encompasses Level A criteria. Meeting this individual criterion is one part of broader conformance and does not by itself guarantee an accessible experience for all users or immunity from legal claims. Overall accessibility depends on satisfying the full set of applicable criteria and validating with manual and assistive technology testing; this guidance is not legal advice, and legal requirements evolve through regulation and case law.

Common misconceptions

On Focus prohibits any visible change when an element receives focus.

The criterion prohibits a change of context on focus, not all visual changes. Providing a visible focus indicator or minor styling change is expected practice and does not by itself constitute a change of context as WCAG defines it.

On Focus and On Input are the same requirement.

They are separate success criteria. On Focus (3.2.1) concerns context changes when a component receives focus, whereas On Input (3.2.2) concerns context changes when a user changes a component's setting. Meeting one does not automatically satisfy the other.

Passing On Focus means the interface is fully accessible or legally compliant.

On Focus is one Level A criterion among many. Conformance with a single criterion does not guarantee an accessible experience or immunity from legal claims. Automated tools detect only a portion of related issues, so manual and assistive technology testing are generally required, and this guidance is not legal advice.

Best practices

Ensure that tabbing to or otherwise focusing a control does not automatically open a new window, move focus elsewhere, submit a form, or substantially change page content.

Reserve context changes for deliberate user activation (such as pressing Enter or clicking), and handle input-triggered changes in line with On Input (3.2.2).

Test keyboard navigation by tabbing through all interactive components to confirm that focus changes alone do not produce unexpected shifts in context.

Verify behavior with assistive technologies such as screen readers, since focus can be moved programmatically in ways that differ from mouse interaction.

Provide a clear, visible focus indicator so users can track focus without triggering unintended context changes.

Combine automated checks with manual review, recognizing that automated testing detects only a portion of On Focus issues and cannot confirm the absence of disorienting context changes on its own.