Free scan

October 22, 2026

Meta refresh redirect accessibility: why timed reloads can fail WCAG

The meta http-equiv refresh element is often used to reload a page at regular intervals or to redirect users to another page. For accessibility, it is a well-documented trap: in failure technique F41, the W3C describes how using it to reload the page can fail three WCAG success criteria, 2.2.1 (Timing Adjustable), 2.2.4 (Interruptions) and 3.2.5 (Change on Request). In short, F41 describes a page that reloads itself at an interval that is too short, with no way to turn auto-refresh off; its test procedure also checks whether the user can turn off, extend or adjust the timing. The W3C recommends avoiding periodic refresh and letting users choose when they want the latest information. For redirects, our advice is to handle them on the server: the Understanding document for 2.2.1 states that non-timed server redirects, such as 3xx response codes, are not applicable because they work instantly. Below you will find how the problem works, the official test procedure, the special case of a zero delay and the alternatives.

What meta refresh does and why it is an accessibility problem

The number in the content attribute is the delay, in seconds, before the refresh. With content="60", the page reloads every sixty seconds without any action from the person viewing it. The W3C labels this code a deprecated example and tells content developers not to use it to simulate "push" technology.

The issue is reading time. According to the F41 description, if the interval is too short and there is no way to turn auto-refresh off, people who are blind will not have enough time to have their screen readers read the page before it refreshes unexpectedly, which makes the screen reader start reading again at the top. Sighted users may also be disoriented by the unexpected refresh.

The W3C points out that developers cannot predict how much time a user will need to read a page, and that a premature refresh can disorient users. Its recommendation is clear: avoid periodic refresh and let users choose when they want the latest information.

<!-- F41 failure example: the page reloads every 60 seconds -->
<head>
  <title>Dashboard</title>
  <meta http-equiv="refresh" content="60" />
</head>

Why an automatic reload counts as a time limit under 2.2.1

Success Criterion 2.2.1 Timing Adjustable, at Level A, aims to give users adequate time to complete tasks. Its Understanding document says that any process that happens without user initiation after a set time or on a periodic basis is a time limit. Partial or full updates of content, such as a page refresh, are explicitly included.

For each time limit set by the content, at least one of the following must be true:

How to test a page that uses meta refresh

F41 comes with a test procedure for any HTML page that uses meta http-equiv="refresh". It has five checks:

Reading the results criterion by criterion

The expected results do not combine the same checks for all three criteria. For 2.2.1, checks 1 to 5 are involved. For 2.2.4, checks 1, 2, 4 and 5. For 3.2.5, only checks 1 and 4 count. In practice, this means the real-time and essential exceptions (check 3) are only taken into account for 2.2.1, and the delay value (check 2) plays no part for 3.2.5. A page covered by a 2.2.1 exception is therefore not, on that basis alone, safe for 2.2.4 and 3.2.5.

Also keep in mind a general W3C note on failure techniques: they show how content can fail a criterion, but content may still satisfy it if it includes equivalent or alternative content or functionality that does meet the normative requirements.

Finally, for 2.2.1 the W3C lists two approved test rules that deal directly with this topic: "Meta element has no refresh delay" and "Meta element has no refresh delay (no exception)". Using them is not required to check conformance, but they are defined and approved test methods.

The zero-delay case in meta refresh

The second check of the F41 procedure singles out values less than 1, which includes a delay of 0, and values greater than 72,000 seconds. Those 72,000 seconds equal 20 hours, the duration used by the 20-hour exception of 2.2.1. This check is part of the conditions examined for 2.2.1 and 2.2.4.

Note, however, that it is not part of the condition for 3.2.5, which relies only on checks 1 and 4. The delay value alone therefore does not settle the Change on Request question. If the user has a way to turn off, extend or adjust the refresh, the answer to check 4 is yes.

One important clarification: F41 is about reloading the page. For meta redirects with a time limit, the W3C documents a separate failure, F40, which this article does not cover in detail. If all you need is to send users to a new address, our advice is to use a non-timed server redirect, which the 2.2.1 Understanding document says is not applicable.

What to use instead: server redirects and on-demand updates

For redirects, the 2.2.1 Understanding document is explicit: non-timed server redirects, for example 3xx response codes, are not applicable because they work instantly and impose no time limit. An important nuance: doing it on the server is not automatically safe. Failure F58 covers server-side techniques that automatically redirect pages after a time-out, and failure F40 covers meta redirects with a time limit.

For content that must stay current, the W3C advises letting users choose when they get the latest information. Our advice: replace the automatic reload with a user action, such as a button. If a time limit is still needed, the W3C sufficient techniques for 2.2.1 are grouped by situation:

<!-- Instead: no automatic reload, the user decides -->
<head>
  <title>Dashboard</title>
</head>
<body>
  <!-- The script that loads new data still needs to be wired up -->
  <button type="button" id="refresh">Load the latest information</button>
</body>

Who is affected by an uncontrolled reload

The 2.2.1 Understanding document details the people who may need more time. Keep them in mind before imposing a timed refresh:

Frequently asked questions

Is meta refresh forbidden by WCAG?

The W3C sources cited here do not forbid it as such: failure F41 describes the conditions under which using it to reload the page fails 2.2.1, 2.2.4 and 3.2.5, especially when the interval is too short and there is no way to turn auto-refresh off. The W3C also notes that content may still satisfy a criterion despite a failure technique if it provides an equivalent alternative that conforms.

Is a meta refresh with a delay of 0 a problem?

In the F41 procedure, a delay below 1 is singled out by the second check, which counts for 2.2.1 and 2.2.4 but not for 3.2.5. The delay value alone therefore does not settle the question for 3.2.5. For a redirect, our advice: use a non-timed server redirect, which the 2.2.1 Understanding document says is not applicable.

How do I replace a meta refresh redirect with a server redirect?

Have the server respond with a 3xx redirect code pointing to the new address. The W3C states that these non-timed redirects are not applicable to 2.2.1 because they work instantly. However, a server redirect triggered after a time-out is a documented failure (F58).

Does the meta refresh delay matter for accessibility?

The F41 procedure checks whether the value is less than 1 or greater than 72,000 seconds (20 hours), but that check only counts for 2.2.1 and 2.2.4, not for 3.2.5. Success Criterion 2.2.1 requires that any time limit set by the content can be turned off, adjusted or extended, apart from its exceptions.

Which WCAG criteria does meta refresh affect?

Failure F41 relates to three success criteria: 2.2.1 Timing Adjustable, 2.2.4 Interruptions and 3.2.5 Change on Request. It applies to HTML.

Further reading on Conformly

Sources

This article relies on the official sources listed at the end of the page.