Have you ever clicked on a text field and suddenly found yourself whisked away to a new page without warning? Or maybe you saw a form error message pop up out of nowhere, but your cursor stayed right where it was? These two situations hint at the difference between a “change of context” and a “change of content.”

If you’re trying to make your website accessible, it’s important to know which is which because the Web Content Accessibility Guidelines (WCAG) treat them very differently. In this post, we’ll explore both terms, share some real-life examples, and give you tips on how to keep your site friendly and easy to use. By the end, you’ll have a stronger grasp of WCAG best practices and the confidence to apply them to your site.

Why These Terms Matter

People who rely on screen readers or keyboard navigation often can’t see or skim an entire page at once. Sudden or unexpected changes—like being redirected to a new tab—can be disorienting for them. That’s why WCAG sets clear rules to help you avoid making people feel lost.

However, understanding “change of context” and “change of content” also helps with other accessibility concepts. For example, clarifying how your content updates ties right in with “Alternative for Time-based Media” or “Media Alternative for Text“—two other areas covered under WCAG. The more you know about these related topics, the better your site will serve all kinds of users.

“Change of Context” in Plain Terms

A “change of context” is a big shift in what a user sees or how they interact with the page. Under WCAG, it can include:

• Opening a new window or tab without telling the user.
• Moving the focus to another section of the page unexpectedly.
• Redesigning the layout in a way that confuses users.

For example, imagine you click into a text field, and suddenly, your screen shifts to another form altogether. That’s a huge jump! WCAG 3.2.1 (On Focus) says you shouldn’t trigger this kind of shift just because the user’s focus landed on an element. If the user ends up somewhere new, or a new window appears without their Input, you’re dealing with a “change of context.”

“Change of Content” in Action

Now, let’s say you click a menu button, and the menu expands without moving your cursor or launching a new page. That’s a “change of content.” You’re still in the same place—you can just see more information. This kind of change is usually okay as long as it doesn’t confuse or mislead.

WCAG makes the point that not every content update equals a context change. You can display a tooltip, expand a dropdown, or show an inline error message without violating rules. As an example, if you’re filtering products on an eCommerce site and the list of items refreshes while your focus stays put, you’re likely good to go. The user expects new content to appear, so it’s not disorienting.

When It Becomes an Accessibility Issue

Mixing up these concepts can cause problems for people who rely on assistive technologies. For instance, if your site changes context every time someone selects a checkbox, they might lose track of where they were. WCAG 3.2.2 (On Input) warns against automatically triggering a big context shift unless you clearly warn the user or let them choose when it happens.

At higher levels of WCAG (like AAA), 3.2.5 (Change on Request) says that major shifts should happen only when the user deliberately starts them—or they should be easy to dismiss. That means you can’t force a pop-up window to stay on screen with no way to close it. People need control over how they explore your site.

Status Messages and Alerts

Some sites show status messages—like “Item added to your cart”—that don’t move focus but do tell assistive tech users what’s happening. That’s allowed under WCAG 4.1.3 (Status Messages) because the screen reader can announce the alert without taking the user away from what they were doing.

Things get trickier when an alert moves focus to itself. Sometimes, that’s necessary (say, with a big error), and if the user’s action triggers it, it can still meet WCAG standards. But if your site automatically shifts focus to a timeout warning with no user action, that can become a disorienting change of context—especially at the AAA level of WCAG compliance.

Tips for Making It Work

Keep People Where They Are

Unless there’s a solid reason for moving focus or opening a new page, don’t do it. A small update to the same page is usually a “change of content,” which is less disruptive.

Give Users a Heads-Up

If you need to make a “change of context,” warn the user first. For example, say, “Selecting this option opens a new window.” This aligns with WCAG recommendations, especially 3.2.2.

Test with Assistive Tech

The best way to find out if your site is user-friendly is to try it with screen readers, keyboard-only navigation, or other assistive tools. You’ll quickly spot if something is shifting unexpectedly.

Use ARIA Properly

If you have alerts or status messages, use ARIA roles like role= “alert” or aria-live so screen readers can announce them without moving focus. This follows WCAG 4.1.3 guidelines for status updates.

Think About Your Audience

Some changes of context, like a security timeout, might be needed. Just remember to give the user control whenever possible.

Wrapping It Up

Understanding when something is a “change of context” rather than just a “change of content” is a big part of complying with WCAG. When you keep these definitions clear, you’ll avoid creating barriers that leave users confused and frustrated. It also ties back to important concepts like “Alternative for Time-based Media” and “Media Alternative for Text,” which help make websites more inclusive overall.

Remember, WCAG doesn’t just set rules—it helps us create better experiences for everyone. If you need extra guidance, 216digital is here to help. We can perform an Accessibility Audit to see where your site stands, offer advice on meeting WCAG success criteria like 3.2.1, 3.2.2, 3.2.5, and 4.1.3, and suggest ways to make your site easier for all. 

Ready to get started? Schedule a consultation with 216digital today and make sure you’re on the path to a more inclusive, user-friendly website!