For each script that initiates a change of context, is the user warned or in control of it?

A user navigates your website with a screen reader. They select an option from a dropdown menu. The page reloads instantly. Zero warning. Their screen reader starts from the top of the page, and the user has lost their position, their reading flow, their navigation context.

Criterion 7.4 sets a clear rule: any script that triggers a change of context must either warn the user before executing, or be triggered explicitly by a button or a link. The user must be able to anticipate what will happen, or be directly in control of it.

A "change of context" under RGAA goes further than a simple page reload. It covers: opening a new page, a major content update via AJAX, automatic focus movement, automatic launch of a video player upon selection. Conversely, displaying a conditional field or updating a character counter without moving focus is not a change of context.

The most direct fix: replace the automatic event with a <button type="submit">. Five lines of HTML are enough.

Un test to detect unexpected context changes

Warning before context change triggered by script

  1. Identify all scripts that trigger a change of context on the page. Look in particular for:
    • A <select> with an onchange handler that navigates or reloads the page
    • An AJAX update of an essential content area
    • A video or audio player that automatically starts upon playlist selection
    • A focus shift that repositions the user in the page
  2. For each detected change of context, verify that at least one condition is met:
    • The user is informed by visible text of the upcoming change, before it occurs
    • The change is triggered by an explicit button (<button>, <input type="submit">, <input type="button">, <input type="image">)
    • The change is triggered by an explicit link (<a href="...">)
  3. If none of these conditions is met, the test fails.

Examples

❌ Non-compliant : Dropdown menu that automatically navigates when selection changes

<form>
  <label for="categorie">Filter by category</label>
  <select id="categorie" onchange="window.location.href = this.value;">
    <option value="/news">News</option>
    <option value="/events">Events</option>
    <option value="/resources">Resources</option>
  </select>
</form>

Navigation is triggered as soon as the selection changes, without any additional user action. A visitor exploring options with the keyboard using arrow keys is redirected to a new page with each arrow press. This is WCAG Failure F37. Particularly disastrous for screen reader users, who lose their position with each list movement.

✅ Compliant : Dropdown menu with explicit validation button

<form action="/filter" method="get">
  <label for="categorie">Filter by category</label>
  <select id="categorie" name="categorie">
    <option value="news">News</option>
    <option value="events">Events</option>
    <option value="resources">Resources</option>
  </select>
  <button type="submit">Apply filter</button>
</form>

The user chooses their option, then decides for themselves to submit via the button. The <button type="submit"> is the explicit initiator of the change of context. Keyboard-navigable without surprise, compatible with all screen readers.

✅ Compliant : AJAX update with prior text warning

<p id="info-sort">
  The results list updates automatically after your selection.
</p>
<select
  id="sort"
  aria-describedby="info-sort"
  onchange="updateResults(this.value)"
>
  <option value="date">By date</option>
  <option value="relevance">By relevance</option>
</select>

The visible text warning, placed before the <select>, informs the user of the dynamic behavior before they interact. This is the second path to compliance with criterion 7.4: warn before triggering. The aria-describedby strengthens the semantic link for assistive technologies.

Tips and pitfalls

⚠️ onchange on <select> is the most frequent audit failure

Triggering navigation or reload via onchange on a <select> is the most common case of non-compliance with criterion 7.4. Technically simple to fix (add a submit button), it is often left as is in the name of "user comfort." This comfort is an illusion: screen reader users find themselves redirected to a new page with each keyboard movement through the list.

⚠️ OTP form with automatic submission: borderline accepted case

A one-time password form with 6 digits that submits automatically after the last digit is entered is debated. The most widespread RGAA interpretation is that the input context (the user knows they are entering a confirmation code) makes the action sufficiently explicit. A submit button remains the safest and least contestable solution during an audit.

💡 An explicit button resolves nearly all cases

The most direct path to compliance: any change of context must be triggered by a <button> or <input type="submit">. No warning text to write, no additional ARIA. The button itself attests that the user has chosen to act.

⚠️ Focus manipulation also counts as a change of context

If a script moves focus to another area of the page without the user requesting it, it is a change of context under criterion 7.4. Automatic focus shifts after form submission or after a timed delay must be anticipated and communicated to the user.

⚠️ Automatic reload without interaction falls under criterion 13.1

A <meta http-equiv="refresh"> or JavaScript redirect that triggers without any user interaction falls under criterion 13.1 (consultation), not 7.4. Criterion 7.4 applies only to changes of context triggered in response to a user interaction with a script.

Frequently asked questions

How do you distinguish a dynamic change from a change of context according to RGAA?

A change of context is a major change likely to disorient the user: opening a new page, reloading, moving focus, updating an essential area via AJAX, automatically launching a media. Displaying a conditional field, updating a character counter, or refreshing a suggestion list without moving focus does not constitute a change of context under criterion 7.4.

How should a <button type="button"> with onclick that causes navigation be treated in RGAA?

Yes. What matters is that the user deliberately activates an interactive element with button semantics. A <button type="button"> with onclick that triggers navigation is compliant. It is not comparable to an automatic onchange on a <select>, where the change of context occurs without a deliberate submission action.

How do you practically audit criterion 7.4 for changes of context in RGAA?

Navigate the page using only the keyboard. Go through all form elements with Tab, and use arrow keys in dropdown lists. If a change of context occurs without you pressing Enter or activating a button or link, it is likely a failure. Then inspect the source code to identify the triggering event (onchange, onfocus, oninput, etc.).

When should aria-describedby signal a change of context according to RGAA?

RGAA requires that the user be "warned by text" before the change is triggered. This text must be accessible to everyone, not only via assistive technologies. An aria-describedby alone, pointing to visually hidden content, is not enough. The text must be visible in the page flow, placed before the triggering element.

Why does a link opening a new window fall under RGAA criterion 7.4?

Opening a new window via a link is the standard behavior of a link: criterion 7.4 does not apply. However, if a script forces a new window to open outside of any click on an explicit link or button, criterion 7.4 applies. The mention of opening in a new window in the link text is instead handled by criterion 6.1.

References

RGAA 4.1.2: Criterion 7.4
WCAG 2.1:3.2.1 (A)3.2.2 (A)G13G76G80G107H32H84F9F22F36F37F41SCR193.2.1 (A)3.2.2 (A)