( Operable / WCAG 2.2.4 )
Page uses meta refresh with a time limit
What is this issue?
A <meta http-equiv="refresh" content="N; url=..."> element is present on the page, with any value of N, including a value paired with a working pause or cancel control. This is the same markup pattern flagged by Meta refresh causes automatic page redirect, the WCAG 2.2.1 Timing Adjustable check, but evaluated against a stricter standard: 2.2.4 Interruptions doesn’t ask whether the timing is adjustable; it asks whether the interruption should be happening automatically at all.
WCAG 2.2.4 is not one of the new criteria introduced in WCAG 2.2; it’s a Level AAA criterion that has existed since WCAG 2.0, sitting in the same Timing Adjustable family as its more commonly-required AA sibling. The two rules commonly appear on the same audit because they’re triggered by the identical markup, at two different conformance bars.
Why does this matter?
An automatic page refresh interrupts a task in progress regardless of how considerate its timing controls are: even a refresh with a working “cancel” button still assumes the user will notice the countdown, understand what it does, and act before it fires. WCAG 2.2.4’s stricter standard reflects that an interruption a user didn’t ask for is disruptive by nature, not just when it’s uncontrollable.
For someone who reads slowly, is mid-task on a form, or is listening to a screen reader work through dense content, even a “considerate” refresh with a visible countdown and cancel link still requires noticing that countdown exists in the first place, attention that competes directly with whatever they were actually doing on the page. AAA conformance exists precisely to remove that competing-attention cost entirely, not just make it more survivable.
Who is affected?
- Screen reader users: a countdown notice sitting visually elsewhere on the page may not be announced at the moment it becomes relevant, so even a “controllable” refresh can fire with no effective warning reaching a screen reader user in time to act.
- Low vision users: a small, easily-missed countdown or cancel control is harder to notice and act on before it expires, especially for anyone not actively scanning the whole page for a warning they didn’t expect.
- Cognitive disabilities: noticing, understanding, and acting on a timing control under time pressure adds a secondary task on top of whatever the user was already doing, which is exactly the kind of avoidable interruption AAA conformance is designed to eliminate.
What users experience
Farah uses NVDA on her Windows laptop and is filling out a multi-page government benefits application. A confirmation page includes <meta http-equiv="refresh" content="15; url=/application/next-step"> with a small on-screen note reading “Moving to the next step in 15 seconds. Click here to continue now,” which technically satisfies the AA-level requirement since a link exists. NVDA is reading through the page’s confirmation details when the refresh fires mid-sentence; the note about the 15-second timer was never reached in her reading order before the redirect happened, so from her perspective the page simply changed underneath her with no warning she had any chance to act on.
How do I fix it?
Remove the meta refresh tag entirely and replace timed transitions with content the user actively triggers: a visible link or button they click when they’re ready to move forward. This satisfies 2.2.4 directly, since a fully user-initiated transition isn’t an “interruption” in the criterion’s sense at all: nothing happens until the user decides it should.
If a genuine automatic transition is required by the product (a checkout confirmation, a step in a guided flow), the AAA-level fix isn’t a better-designed countdown; it’s removing the automatic component altogether and requiring an explicit action instead. Reserve any exception to this for content that’s genuinely an emergency under WCAG’s own narrow definition, such as a safety alert requiring immediate attention; a marketing refresh or convenience redirect doesn’t qualify.
Code Examples
<!-- Still fails 2.2.4 even with a working cancel link -->
<meta http-equiv="refresh" content="15;url=/application/next-step">
<p>Moving to the next step in 15 seconds. <a href="/application/next-step">Continue now</a></p><!-- User-initiated transition - no automatic timing at all -->
<p>Your details have been saved.</p>
<a href="/application/next-step" class="button">Continue to the next step</a>The original markup satisfies the AA-level requirement, since a link to cancel or act early exists, but it still fails this stricter AAA check because the page changes automatically without the user asking it to. The fix removes the automatic timing entirely: the user reads the confirmation at their own pace and clicks “Continue” only when they’re ready, which is what 2.2.4 actually requires: no unrequested interruption, not just a well-controlled one.
Common Mistakes
Mistake: “We already fixed this by adding a countdown and a cancel button.” A countdown and cancel control satisfies the AA-level meta-refresh requirement (2.2.1), but this stricter AAA check (2.2.4) flags any automatic refresh regardless of its controls. The two criteria have genuinely different bars: passing one doesn’t mean passing the other.
Mistake: “This only applies to the literal meta refresh tag, so a JavaScript timer sidesteps it.” Like its AA sibling, this criterion is about the underlying behavior (an automatic, user-uninitiated interruption), not the specific mechanism causing it. A setTimeout-driven redirect creates the identical AAA-level failure; it’s simply invisible to this particular automated check, which only parses markup.
Mistake: “AAA conformance isn’t required for our product, so this check doesn’t matter at all.” Even on a product only targeting AA, this rule’s underlying finding (any meta refresh present at all) is worth reviewing, since it’s often trivial to fix by switching to a user-initiated link, and doing so removes the AA-level 2.2.1 concern at the same time by construction.
How RedFlag Detects This
Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s meta-refresh-no-exceptions rule as part of every scan. Because this rule falls outside axe-core’s default WCAG 2.0/2.1/2.2 A/AA tag set on its own (it’s an AAA-level check), RedFlag explicitly force-enables it alongside five other rules so it still runs on every scan. The rule inspects every <meta http-equiv="refresh"> element in the DOM and flags any present at all, with no exception for a nonzero-but-controllable delay.
False negative: the check only parses the literal <meta http-equiv="refresh"> tag; a JavaScript-driven timed redirect using setTimeout and window.location, or a server-sent HTTP Refresh response header, produces the identical interruption but leaves no matching element in the DOM for this check to find. False positive: none typical, since detecting the presence of the tag is a straightforward, binary parse of markup already on the page. Manual step: search the codebase and test the live site for JavaScript-based or server-header-based timed redirects that reproduce this same problem outside a meta tag, since the automated check can’t see those.
Manual Testing
- View the page source (or DevTools Elements panel) and search for
<meta http-equiv="refresh". Confirm none exist at all, regardless of whether a pause or cancel control accompanies them. - Load the live page and wait without interacting. Note whether it automatically reloads or navigates away within the first 30–60 seconds.
- If a timed transition exists anywhere on the page, evaluate whether it qualifies for the emergency exception under WCAG’s own narrow definition; if not, it should be replaced with a user-initiated action instead of a better-controlled timer.
- With NVDA or JAWS running, load the page and let any timer run its course. Confirm the screen reader user received effective, timely notice before any context change, not just a technically-present warning elsewhere on the page.
Related WCAG Success Criteria
2.2.4 Interruptions: Interruptions can be postponed or suppressed by the user, except those involving an emergency. This rule maps directly to that Level AAA requirement, flagging any automatic meta refresh as exactly the kind of unrequested interruption the criterion targets.
2.2.1 Timing Adjustable: The related, more commonly-required Level A criterion requiring only that a time limit be controllable, not eliminated. See Meta refresh causes automatic page redirect for the AA-baseline version of this same underlying markup pattern.
Related Issues
Meta refresh causes automatic page redirect is this rule’s AA-level sibling: the same markup pattern and detection mechanism, evaluated against the more commonly-required “must be controllable” bar instead of “must not happen automatically at all.”
Page contains a blinking or scrolling element shares this rule’s Operable-principle concern with unrequested, uncontrolled changes to the page, though it concerns continuous motion rather than a one-time forced navigation.
Page has no way to bypass repeated content and Page has no descriptive title are foundational navigation checks worth auditing on the same pages that use timed transitions, since both concern giving users reliable orientation and control over how they move through a site.
Context change happens when element receives focus and Context change happens on input without warning cover the same underlying harm (an unexpected, user-uninitiated context change) triggered by interaction instead of a timer.
References
Frequently asked questions
What's the difference between meta-refresh and meta-refresh-no-exceptions?
The AA-level meta-refresh rule (2.2.1 Timing Adjustable) flags a meta refresh whose delay is uncontrollable: no way to pause, extend, or cancel it. This rule, meta-refresh-no-exceptions (2.2.4 Interruptions), is a stricter AAA check that flags any meta refresh at all, even one with a working cancel control, because the criterion bars unrequested interruptions outright rather than just requiring they be controllable.
Is 2.2.4 Interruptions a new criterion in WCAG 2.2?
No. Interruptions has existed since WCAG 2.0 as a Level AAA criterion; it is not one of the criteria WCAG 2.2 introduced. Its number (2.2.4) sits within the Timing Adjustable family of success criteria, but it predates the 2.2 revision by over a decade.
Does an emergency notification get an exception under 2.2.4?
Yes. WCAG 2.2.4 explicitly exempts interruptions involving an emergency: content genuinely requiring immediate attention for safety reasons is allowed to interrupt the user without meeting the rest of the criterion. A routine session-timeout warning or promotional refresh does not qualify as an emergency.
Is meta-refresh-no-exceptions a requirement most organizations need to meet?
Not usually as a hard requirement. This is a Level AAA criterion, above the Level AA baseline most accessibility laws and organizational policies target. Its AA sibling, meta-refresh (2.2.1), covers the more commonly required baseline: any meta refresh must at least be controllable, even if AAA-level "no refresh at all" is out of scope.
Does replacing a meta refresh with a JavaScript setTimeout redirect satisfy this stricter rule?
No. The criterion is about the underlying behavior (an automatic interruption the user did not request or control), not the specific mechanism producing it. A setTimeout-driven redirect creates the identical AAA-level failure as a meta refresh tag, even though this specific automated check, which parses markup, cannot see it.