AccessLint Rule: Meta refresh must not be used with a delay (no exceptions).

About this AccessLint rule

The <meta http-equiv="refresh"> element with a non-zero delay causes the browser to automatically refresh the current page or redirect to a different URL after a specified number of seconds. This automatic, timed behavior creates problems for many users, and this rule flags any instance where the delay is greater than zero.

Screen reader users may be in the middle of reading page content when the page suddenly refreshes or navigates away, losing their place entirely. Users with cognitive disabilities may not understand what happened or why the content changed. Users who need more time to read or interact with a page — because of motor impairments, learning disabilities, or simply unfamiliarity with the content — get no say in when the transition occurs. Keyboard-only users may lose focus context when the page reloads.

An instant redirect with a delay of 0 is acceptable because it behaves like a standard redirect: the user never sees intermediate content that gets yanked away. Any positive delay, even a short one, means the user begins consuming the page and then has it replaced without their consent.

Related WCAG success criteria

This rule relates to WCAG 2.2.1 Timing Adjustable (Level A), which requires that users can turn off, adjust, or extend time limits. A <meta> refresh with a fixed delay provides none of these options. The rule also connects to WCAG 2.2.4 Interruptions (Level AAA) and 3.2.5 Change on Request (Level AAA), both of which prohibit automatic changes in context that the user did not initiate.

WCAG 2.2.1 does technically allow time limits longer than 20 hours, so a page that refreshes after 20+ hours would still pass that specific criterion. However, this AccessLint rule is stricter: it disallows any positive delay, with no exceptions.

How to fix it

Remove the <meta http-equiv="refresh"> tag with a positive delay and use one of these approaches instead:

Server-side redirect. Return an HTTP 301 or 302 status code from the server. This is the best approach for redirects because it happens before the browser renders any content.
Instant client-side redirect. If a server-side redirect is not possible, set the delay to 0. This is not ideal (it can cause a brief flash), but it does not trap users on a timed page.
Remove the refresh entirely. If the intent is to periodically reload content (such as a news ticker), provide a manual refresh button or use JavaScript that the user can control.

Examples

Delayed redirect (fails)

The page loads, and after 30 seconds the browser navigates to a new URL. Users have no control over this.

<head>
  <meta http-equiv="refresh" content="30; url=https://example.com/new-page">
</head>

Delayed page refresh (fails)

The page reloads itself every 60 seconds. Users reading the page will lose their place.

<head>
  <meta http-equiv="refresh" content="60">
</head>

Short delay redirect (fails)

Even a small delay like 5 seconds is enough for a user to start reading or interacting with the page before it disappears.

<head>
  <meta http-equiv="refresh" content="5; url=https://example.com/other">
</head>

Instant redirect with delay of 0 (passes)

A delay of 0 acts as an immediate redirect. The user never has content taken away mid-read.

<head>
  <meta http-equiv="refresh" content="0; url=https://example.com/new-page">
</head>

Server-side redirect (passes)

The best solution is to handle the redirect on the server. No <meta> tag is needed.

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page

Browser differences

Not all browsers parse the content attribute the same way. Some browsers treat an unparseable value as a 0-second delay and redirect immediately, while others ignore the directive entirely. Relying on browser quirks is not a safe strategy. Always set an explicit, valid value, or better yet, move the redirect to the server.