WCAG 2.2.1Level ASeriousDocument

How to fix: Page uses meta refresh

Remove timed client-side refreshes set with <meta http-equiv="refresh"> and use a server-side 301 or 302 redirect instead, because an automatic refresh moves content out from under users and can violate WCAG 2.2.1 Timing Adjustable.

What it is

A meta refresh is a <meta http-equiv="refresh"> tag in the document head that tells the browser to reload the current page, or navigate to another URL, after a set number of seconds. It was an early way to build auto-redirects and auto-refreshing pages, but it is a client-side timer the user did not ask for and cannot easily control.

WCAG Success Criterion 2.2.1 Timing Adjustable governs time limits on content. A timed refresh imposes exactly that kind of limit: the page changes on a clock, regardless of whether the user has finished reading, filling in a field, or interacting with what is on screen. There is no built-in way to turn it off, extend it, or pause it, which is the core of why it fails. A page that redirects after, say, five seconds yanks content away from a slow reader or a screen reader user mid-sentence.

The correct replacement depends on intent. If the goal is to send users from an old URL to a new one, do it with a server-side HTTP redirect (301 for permanent moves, 302 for temporary ones); this happens before the page renders, so there is no timed yank and assistive technology lands directly on the destination. If you genuinely need to refresh data on screen, do it with a user-initiated control or a live region you can announce, not a blind page reload on a timer.

Who it affects & why it matters

Screen reader users are disrupted directly. A refresh interrupts the speech they are listening to and resets their position, so they lose their place and have to start over, often without understanding why the page just changed. If the timer is short, they may never finish hearing the content before it disappears.

It also affects people who read slowly, including users with cognitive, learning, or attention disabilities, and anyone navigating with a keyboard or magnifier who needs more time. A surprise reload is disorienting for these users, and because the back button can bounce them right back into the refresh loop, it can even trap them on a page they are trying to leave.

A timed meta refresh is a Level A failure under SC 2.2.1 Timing Adjustable, the most basic conformance tier, and it is easy for an automated tool to spot since it is a single tag in the head. WCAG 2.1 Level AA is the de-facto ADA benchmark courts apply, and because Level AA includes every Level A criterion, a meta refresh is a clear, documentable finding in any accessibility audit.

Accessibility lawsuits continue to rise, with the majority aimed at businesses under $25 million in revenue, so removing easily-detected Level A failures is worthwhile risk reduction. The fix is also a technical upgrade: a server-side 301 or 302 redirect is faster, preserves SEO link equity better than a meta refresh, and avoids the timed-content problem entirely, so you improve accessibility and site quality in one change.

How to fix it

Locate the <meta http-equiv="refresh"> tag in the document head and note whether it reloads the page or redirects to another URL.
If it redirects to a new URL, replace it with a server-side redirect: return a 301 for a permanent move or a 302 for a temporary one.
Configure that redirect at the server, framework, or host level (for example a redirect rule, route handler, or rewrite) instead of in the HTML.
If you actually need to update on-screen data, replace the blind refresh with a user-triggered action or an announced live region rather than a timed reload.
Remove the meta refresh tag entirely and re-scan to confirm no <meta http-equiv="refresh"> remains.

Before

<head>
  <meta http-equiv="refresh" content="5; url=/new-page">
</head>

After

<!-- Server response sends the redirect before the page renders -->
HTTP/1.1 301 Moved Permanently
Location: /new-page

How AccessKnight detects this

AccessKnight scans the document head for a <meta http-equiv="refresh"> element. If one is present, the page is flagged, because a timed client-side refresh or redirect can violate WCAG 2.2.1 Timing Adjustable by moving content out from under the user on a clock they cannot control. The recommended fix is to delete the tag and perform any redirect with a server-side 301 or 302 response instead.

Frequently asked questions

Is meta refresh a Level A or AA issue?

It fails WCAG 2.1 Success Criterion 2.2.1 Timing Adjustable, which is Level A, the minimum conformance tier. AccessKnight treats it as serious severity because a timed refresh interrupts and disorients users, especially screen reader users, without giving them a way to stop or extend the timer.

What should I use instead of meta refresh to redirect?

Use a server-side HTTP redirect: a 301 for a permanent move or a 302 for a temporary one. It happens before the page renders, so assistive technology lands directly on the destination with no timed yank, and it preserves SEO value better than a client-side meta refresh.

Is a meta refresh with a zero-second delay acceptable?

It is still best avoided. Even an instant meta refresh is a client-side redirect that can behave inconsistently, harms SEO compared to a real HTTP redirect, and can create back-button traps. AccessKnight flags the presence of the tag regardless of the delay, so the right fix is a server-side 301 or 302.

What if I genuinely need the page to update on a schedule?

Avoid reloading the whole page on a blind timer. Instead, update just the data that changed and expose it through an ARIA live region so screen readers can announce it, or provide a clear user-controlled refresh button. That keeps the user in place and in control, which is what SC 2.2.1 is about.