AccessLint Rule: Meta refresh must not redirect or refresh automatically.

About this AccessLint rule

The <meta http-equiv="refresh"> element can automatically redirect users to another page or reload the current page after a set time delay. When this happens without user consent, it disrupts people who are still reading or interacting with the content. The page disappears or reloads underneath them, and they have no way to prevent it.

Screen reader users are especially affected. A screen reader announces content linearly, and a timed redirect can reset the reading position without warning, forcing the user to start over or navigate to an entirely different page mid-sentence. People with cognitive disabilities may need more time to process content, and an automatic refresh removes that content before they finish. Users with motor impairments who interact slowly with a page can lose form input or navigation progress when the page reloads.

Relevant WCAG success criteria

This rule maps to WCAG 2.2.1 Timing Adjustable (Level A), which requires that users can turn off, adjust, or extend any time limit set by the content. A <meta> refresh with a nonzero delay sets a time limit that the user cannot control.

It also relates to two Level AAA criteria:

2.2.4 Interruptions requires that interruptions can be postponed or suppressed by the user.
3.2.5 Change on Request requires that changes of context happen only when the user requests them.

Any page that uses a timed <meta> refresh fails all three of these criteria.

How the rule works

AccessLint flags any <meta> element that has http-equiv="refresh" and a content attribute specifying a delay greater than 0 seconds and less than or equal to 72000 seconds (20 hours). A delay of exactly 0 is treated as an instant redirect and is not flagged by this rule, since the user never sees intermediate content. A delay over 20 hours satisfies the WCAG 2.2.1 exception for very long time limits.

Note that even though an instant redirect (delay of 0) passes this rule, it can still cause a rapid screen flash. Server-side redirects are preferable in all cases.

How to fix it

The fix depends on why the <meta> refresh is there in the first place.

If the goal is to redirect to a new URL, replace the <meta> element with a server-side HTTP redirect (301 or 302 status code). This moves the user to the new page immediately, without displaying intermediate content that vanishes. In Apache, this is done with a Redirect directive or .htaccess rule. In Nginx, use a return 301 directive. Application frameworks like Express, Django, and Rails all have redirect functions.

If the goal is to periodically reload content (such as a live dashboard), remove the <meta> refresh and provide a manual "Refresh" button or use JavaScript that the user can start and stop. This gives the user control over when the content updates.

If you must use a client-side redirect and cannot configure the server, set the delay to 0 so the redirect is instantaneous:

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

This is acceptable under the rule but should be a last resort.

Examples

Timed redirect (fails)

This page redirects to a new URL after 30 seconds. Users have no way to stop it.

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

Timed page reload (fails)

This page reloads itself every 60 seconds. Any content the user is reading or form data they are entering is lost.

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

Instant client-side redirect (passes)

A delay of 0 redirects immediately, so the user never sees content that then disappears. This passes the rule, though a server-side redirect is still better.

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

Server-side redirect (preferred fix)

No <meta> element is needed. The server responds with an HTTP redirect before any HTML is sent to the browser.

Apache .htaccess example:

Redirect 301 /old-page https://example.com/new-page

User controlled refresh (preferred fix for live content)

Instead of auto-refreshing, provide a button that lets the user decide when to reload.

<head>
  <title>Live scores</title>
</head>
<body>
  <h1>Live scores</h1>
  <button type="button" onclick="location.reload()">Refresh scores</button>
  <div id="scores">
    <!-- Score content here -->
  </div>
</body>