A change of context is one of four things. The user agent changes, the viewport changes, focus moves, or the content changes in a way that changes the meaning of the page. If what your page just did is not one of those four, it is a change of content, which is a different thing with different rules, and most of a modern interface lives there.
That definition carries more of the standard than any other entry in WCAG's glossary. Three success criteria name it outright and forbid or restrict it. A fourth is scoped by it from the other side, because a status message is defined as a change in content that is not a change of context. So the same four lines decide whether a country selector that reloads your storefront is a failure, and whether a confirmation toast needs a live region at all.
The Four Changes, and What Each One Looks Like
The definition opens with a purpose rather than a list, and the purpose is worth holding in mind while you read the list. A change of context is a major change that, if it happens without the user noticing, can disorient somebody who cannot take in the whole page at once. Every member of the list is an attempt to name that experience.
| What changes | What that means in practice | How you notice it |
|---|---|---|
| The user agent | The content moves into a different piece of software from the one the reader was in | They are now in a PDF viewer or a mail client, and the browser controls they were using no longer apply |
| The viewport | A new window or tab opens, or the frame holding the content is replaced by another one | Something arrived that has to be dealt with before the original task can carry on |
| Focus | Focus lands on a component the reader did not send it to | The next Tab press goes somewhere unexpected, and a screen reader starts reading a different part of the page |
| Content that changes the meaning of the page | The page is significantly rearranged, or it becomes what a reader would take to be a different page | A single-page application routes to a new view, and nothing announced that it had |
The fourth row is the one that reaches modern applications, and it reaches them because of a parenthesis. The definition's own example names going to a new page and then adds including anything that would look to a user as if they had moved to a new page. A client-side route change is exactly that. No document was requested, no load event fired, and the criterion applies anyway, because the test is what the reader experiences rather than what the network did.
Everything outside those four is a change of content, and the standard names three examples of that so nobody has to guess. An expanding outline, a dynamic menu and a tab control are all changes of content. None of them changes context by itself. They only do so if they also move focus, open a window, or rearrange the page around them.
The sentence that clears most of your interface
Both On Focus and On Input carry the same standing note, which is that a change of content is not always a change of context, and that the criterion is automatically met where the changes on a page are not also changes of context. A tooltip appearing on focus is fine. A menu expanding on focus is fine. A panel swapping its contents when somebody picks a radio button is fine. If nothing on your page does one of the four things above, you have already met both rules and there is nothing left to test.
Moving Focus Is Itself a Change of Context
Of the four, focus is the one that catches teams out, because moving focus feels like a courtesy rather than a disruption. It sits in the list on its own terms, which means a component that quietly sends focus somewhere else has changed context whatever else it did or did not do.
That single fact explains three things that otherwise look unrelated. A help panel that opens when a field receives focus, and takes focus with it, is the worked failure published for On Focus. A form that advances focus by itself between the parts of a phone number is allowed under On Input only because the form said so first, and that is the worked pass published for it. And a confirmation that both announces itself through a live region and pulls focus to itself gets read out twice, because the live region fires and then the screen reader reads whatever just took focus.
So the rule for feedback is announce or move, never both. Status messages exist for the case where focus stays where the reader left it. Where focus moves, the move is what tells them, and adding an alert role on top produces the double announcement rather than a safety net. The guidance is explicit about it, and says an alert role is only necessary where a change of context does not take place.
On Focus Forbids a Change of Context, and Offers No Way Out
The rule is one sentence long. When any user interface component receives focus, it does not initiate a change of context. There is no exception clause, no advance-warning escape and no exemption for a component that really needs to behave that way. Telling the user first does not cure a failure here, and that is the sharpest difference between this rule and the one after it.
There are three shapes of failure here. A form that submits itself when a component receives focus. A new window that launches when a component receives focus. And focus that is moved to another component when this one receives focus. All three are the same mistake, which is treating arrival at a control as permission to act on it.
Two things narrow how most teams test this. Focus is not a keyboard-only idea, because focus arrives by mouse click as well, so a text field that fires a context change when somebody clicks into it fails just as squarely as one that fires on Tab. And hovering is not focusing, since moving a pointer over a control does not move focus unless a script makes it, so a hover-triggered panel belongs to Content on Hover or Focus rather than here.
The fix is a single change of trigger, and there is one sufficient technique for it, which is using activation rather than focus as the thing that sets a change off. There is also a failure that runs in the opposite direction and is worth a sweep of its own. Removing focus with a script when focus is received, usually because a designer disliked the outline, fails four criteria at the same time.
On Input Allows One, If You Say So Before They Touch It
This rule reads almost the same and behaves differently. 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 before using the component. So the rule is a disclosure requirement rather than a prohibition, and the timing in it is strict. Before using the component means next to the control, not somewhere on the page and not after the fact.
Changing a Setting Is Not the Same as Activating a Control
This is the first question in any finding under this rule, because it decides whether the rule applies at all. Changing a setting means changing something about the control that persists after the reader stops interacting with it. Ticking a checkbox, typing into a field and picking an option from a list are all setting changes. Activating a link or a button is not.
Buttons are where that line gets tested, so the guidance works through the cases. A button whose own state toggles, through aria-pressed or by becoming disabled once used, is changing a setting. A button that submits a form and sends the reader to a new page is activating a control. A button that moves focus, to a dialog it just opened or to the first item in a list, is activating a control as well. So a modal that opens and takes focus is not a failure of this rule, even though moving focus is a change of context, and teams frequently believe the opposite.
Two Patterns That Look Like Failures and Are Not
The first is a form that grows and shrinks. The worked example is a calendar entry form where choosing meeting reveals fields for participants and choosing reminder reveals different ones. Only parts of the entry change and the overall structure holds, so the context has not changed and no warning is owed. That pattern is on almost every conditional form on the web.
The second is a phone number split into three fields that advances focus by itself as each part is filled. Focus movement is a change of context, so this one does engage the rule, and it passes anyway because the behavior is described to the reader at the start of the form. It is the clearest demonstration that the advance-warning escape works when it is used properly.
Between those two sits the answer for filter dropdowns, which is that an onchange handler is fine as long as what it does is not a change of context. Filtering a list in place is a change of content. Reloading the page is not. The documented routes are pairing the control with a submit button, describing the change before it happens, and keeping the handler while keeping the context. The two named failures are a form that submits itself once the last field has a value and a selection that opens a new window with no warning.
That first failure carries the mechanism behind a complaint most teams have heard and few have diagnosed. Arrowing through a native select changes its value on every keypress, so a handler that acts on change acts once per option the reader passes over, not once when they settle. The symptom is a page that reloads while somebody is still choosing.
Status Messages Use the Same Definition in Reverse
A status message has to clear two tests. It tells the reader about the success or result of an action, the waiting state of an application, the progress of a process, or the existence of errors. And it is not delivered through a change of context. That second condition is the whole scope of the rule, and it is what stops the rule applying to every dynamic update on a page.
Three things fall outside it as a result, and each one is a finding that gets filed under the wrong number when the definition is missing. An error message inside a dialog that takes focus is not a status message, because taking focus is a change of context. Expanding an accordion, opening a menu and switching a tab are not status messages either, because those are user interface components and their states already belong to Name, Role, Value. New form questions appearing in response to an answer are not status messages, and announcing them is good practice rather than a requirement.
The line that keeps the rule usable is the one about search. A list of results is not a status message. The short text that says searching, or 18 results returned, or no results returned is one, provided it does not take focus or reload the page. So the count is in scope and the results underneath it are not.
Change on Request, the Level AAA Version
One more rule uses the term, and it is the strictest of them. Change on Request asks that changes of context are initiated only by user request, or that a mechanism is available to turn such changes off. Both halves are complete answers, and the second one is easy to miss. This is where a timed redirect and a window that opens itself on page load are dealt with, and it sits at Level AAA, so it is outside the target most contracts name.
How to Test for an Unexpected Change of Context
Five passes, and the order matters, because the first two are the ones that produce almost every real finding.
- Tab across everything and press nothing else. Not Enter, not Space. Nothing should navigate, submit, open a window or move focus somewhere you did not send it.
- Change every setting without activating anything. Tick each checkbox, pick each option, type into each field and leave it. Watch for reloads, new windows and focus jumps.
- Where something does change context on purpose, find the warning and check where it sits. The standard wants it before the component is used, so a note in the footer or a message that appears afterwards does not count.
- Do the first two passes again with a mouse. Focus arrives by click, and a page that behaves under Tab can still fire on click into a field.
- Look at your own error handling last. Moving focus to an error summary is a change of context and usually the right design. What it means is that the summary does not also need an alert role, and giving it one is how a page ends up saying everything twice.
What a scanner tells you about any of this
Nothing. There is no published test rule for On Focus, none for On Input and none for Status Messages, so the automated pass of any audit returns silence on all three and a clean report proves only that nobody looked. Every finding here comes from a person driving the interface. Our method sets out how the three passes divide the work, and automated versus manual testing covers where the line falls across the rest of the standard.