Kostenloser Scan

22. Oktober 2026

Meta Refresh, Weiterleitung und Barrierefreiheit: warum zeitgesteuertes Neuladen gegen WCAG verstoßen kann

Das Element meta http-equiv refresh wird oft eingesetzt, um eine Seite in regelmäßigen Abständen neu zu laden oder Nutzer auf eine andere Seite weiterzuleiten. Für die Barrierefreiheit ist das eine gut dokumentierte Falle: In der Fehlertechnik F41 beschreibt das W3C, wie der Einsatz zum Neuladen der Seite drei WCAG-Erfolgskriterien verletzen kann, 2.2.1 (Zeitlimits anpassbar), 2.2.4 (Unterbrechungen) und 3.2.5 (Änderung auf Anfrage). Kurz gesagt: F41 beschreibt eine Seite, die sich in zu kurzem Abstand selbst neu lädt, ohne dass Nutzer die automatische Aktualisierung abschalten können; das Prüfverfahren prüft außerdem, ob Nutzer das Timing abschalten, verlängern oder anpassen können. Das W3C empfiehlt, auf periodisches Aktualisieren zu verzichten und Nutzer selbst entscheiden zu lassen, wann sie die neuesten Informationen sehen wollen. Für eine Weiterleitung raten wir, sie auf dem Server umzusetzen: Das Verständnisdokument zu 2.2.1 hält fest, dass nicht zeitgesteuerte Server-Weiterleitungen, etwa mit 3xx-Statuscodes, nicht betroffen sind, weil sie sofort wirken. Im Folgenden erfahren Sie, wie das Problem entsteht, wie das offizielle Prüfverfahren aussieht, was beim Wert 0 gilt und welche Alternativen es gibt.

Was Meta Refresh macht und warum es die Barrierefreiheit stört

Die Zahl im Attribut content gibt die Verzögerung bis zur Aktualisierung in Sekunden an. Mit content="60" lädt die Seite alle sechzig Sekunden neu, ohne dass die Person, die sie liest, etwas tut. Das W3C bezeichnet diesen Code als veraltetes Beispiel und fordert Entwickler auf, damit keine „Push“-Technik zu simulieren.

Das Problem ist die Lesezeit. Laut der Beschreibung von F41 haben blinde Menschen bei zu kurzem Intervall und ohne Möglichkeit, die automatische Aktualisierung abzuschalten, nicht genug Zeit, sich die Seite vom Screenreader vorlesen zu lassen, bevor sie unerwartet neu lädt und der Screenreader wieder oben zu lesen beginnt. Auch sehende Nutzer können durch das unerwartete Neuladen die Orientierung verlieren.

Das W3C weist darauf hin, dass Entwickler nicht vorhersagen können, wie viel Zeit jemand zum Lesen einer Seite braucht, und dass ein verfrühtes Neuladen Nutzer desorientieren kann. Die Empfehlung ist eindeutig: periodisches Aktualisieren vermeiden und Nutzer selbst wählen lassen, wann sie die neuesten Informationen abrufen.

<!-- Beispiel für Fehler F41: die Seite lädt alle 60 Sekunden neu -->
<head>
  <title>Dashboard</title>
  <meta http-equiv="refresh" content="60" />
</head>

Warum automatisches Neuladen ein Zeitlimit im Sinne von 2.2.1 ist

Das Erfolgskriterium 2.2.1 Zeitlimits anpassbar (Stufe A) soll sicherstellen, dass Nutzer genug Zeit haben, ihre Aufgaben zu erledigen. Laut dem Verständnisdokument ist jeder Vorgang, der ohne Zutun des Nutzers nach einer festgelegten Zeit oder periodisch abläuft, ein Zeitlimit. Teilweise oder vollständige Aktualisierungen des Inhalts, etwa das Neuladen einer Seite, sind ausdrücklich eingeschlossen.

Für jedes vom Inhalt gesetzte Zeitlimit muss mindestens eine der folgenden Bedingungen erfüllt sein:

So prüfen Sie eine Seite mit Meta Refresh

F41 enthält ein Prüfverfahren für jede HTML-Seite, die meta http-equiv="refresh" verwendet. Es umfasst fünf Prüfschritte:

Die Ergebnisse Kriterium für Kriterium lesen

Die erwarteten Ergebnisse kombinieren nicht für alle drei Kriterien dieselben Prüfschritte. Für 2.2.1 spielen die Schritte 1 bis 5 eine Rolle, für 2.2.4 die Schritte 1, 2, 4 und 5, für 3.2.5 nur die Schritte 1 und 4. Praktisch heißt das: Die Echtzeit-Ausnahme und die Ausnahme „wesentlich“ (Schritt 3) werden nur für 2.2.1 berücksichtigt, und der Wert der Verzögerung (Schritt 2) spielt für 3.2.5 keine Rolle. Eine Seite, die unter eine Ausnahme von 2.2.1 fällt, ist damit allein deshalb nicht für 2.2.4 und 3.2.5 abgesichert.

Beachten Sie außerdem einen allgemeinen Hinweis des W3C zu Fehlertechniken: Sie zeigen, wie Inhalte ein Kriterium verfehlen können, doch die Inhalte können es trotzdem erfüllen, wenn sie gleichwertige oder alternative Inhalte oder Funktionen bieten, die die normativen Anforderungen einhalten.

Schließlich nennt das W3C für 2.2.1 zwei genehmigte Testregeln, die sich direkt mit diesem Thema befassen: „Meta element has no refresh delay“ und „Meta element has no refresh delay (no exception)“. Sie sind für die Konformitätsprüfung nicht vorgeschrieben, aber definierte und genehmigte Testmethoden.

Der Wert 0 bei Meta Refresh

Der zweite Prüfschritt von F41 grenzt Werte kleiner als 1, also auch die Verzögerung 0, und Werte größer als 72.000 Sekunden ab. Diese 72.000 Sekunden entsprechen 20 Stunden, der Dauer der 20-Stunden-Ausnahme von 2.2.1. Dieser Schritt gehört zu den Bedingungen, die für 2.2.1 und 2.2.4 geprüft werden.

Aber Vorsicht: Er gehört nicht zur Bedingung für 3.2.5, die sich nur auf die Schritte 1 und 4 stützt. Der Wert der Verzögerung allein entscheidet die Frage der Änderung auf Anfrage also nicht. Hat der Nutzer eine Möglichkeit, die Aktualisierung abzuschalten, zu verlängern oder anzupassen, ist die Antwort auf Schritt 4 positiv.

Wichtig zur Einordnung: F41 betrifft das Neuladen der Seite. Für Meta-Weiterleitungen mit Zeitlimit dokumentiert das W3C einen eigenen Fehler, F40, den dieser Artikel nicht im Detail behandelt. Wenn Sie Nutzer nur an eine neue Adresse schicken wollen, raten wir zu einer nicht zeitgesteuerten Server-Weiterleitung, die laut Verständnisdokument zu 2.2.1 nicht betroffen ist.

Was Sie stattdessen nutzen: Server-Weiterleitung und Aktualisierung auf Wunsch

Für Weiterleitungen ist das Verständnisdokument zu 2.2.1 eindeutig: Nicht zeitgesteuerte Server-Weiterleitungen, zum Beispiel mit 3xx-Statuscodes, sind nicht betroffen, weil sie sofort wirken und kein Zeitlimit setzen. Eine wichtige Einschränkung: Die Server-Seite ist kein Freibrief. Fehler F58 betrifft gerade serverseitige Techniken, die Seiten nach einem Timeout automatisch weiterleiten, und Fehler F40 betrifft Meta-Weiterleitungen mit Zeitlimit.

Für Inhalte, die aktuell bleiben müssen, rät das W3C, Nutzer selbst wählen zu lassen, wann sie die neuesten Informationen abrufen. Unser Rat: Ersetzen Sie das automatische Neuladen durch eine Nutzeraktion, etwa eine Schaltfläche. Ist ein Zeitlimit dennoch nötig, sind die hinreichenden Techniken des W3C für Kriterium 2.2.1 nach Situation gegliedert:

<!-- Stattdessen: kein automatisches Neuladen, der Nutzer entscheidet -->
<head>
  <title>Dashboard</title>
</head>
<body>
  <!-- Das Skript, das neue Daten lädt, muss noch angebunden werden -->
  <button type="button" id="aktualisieren">Neueste Informationen laden</button>
</body>

Wen unkontrolliertes Neuladen behindert

Das Verständnisdokument zu 2.2.1 beschreibt die Gruppen, die mehr Zeit brauchen können. Behalten Sie sie im Blick, bevor Sie eine zeitgesteuerte Aktualisierung einsetzen:

Häufige Fragen

Ist Meta Refresh nach WCAG verboten?

Die hier zitierten W3C-Quellen verbieten es nicht als solches: Fehler F41 beschreibt die Bedingungen, unter denen der Einsatz zum Neuladen der Seite gegen 2.2.1, 2.2.4 und 3.2.5 verstößt, vor allem wenn das Intervall zu kurz ist und es keine Möglichkeit gibt, die automatische Aktualisierung abzuschalten. Das W3C weist zudem darauf hin, dass Inhalte ein Kriterium trotz einer Fehlertechnik erfüllen können, wenn sie eine gleichwertige konforme Alternative bieten.

Ist ein Meta Refresh mit Verzögerung 0 ein Problem?

Im Prüfverfahren F41 wird eine Verzögerung kleiner als 1 durch den zweiten Prüfschritt abgegrenzt, der für 2.2.1 und 2.2.4 zählt, nicht aber für 3.2.5. Der Wert der Verzögerung allein entscheidet die Frage für 3.2.5 also nicht. Für eine Weiterleitung raten wir zu einer nicht zeitgesteuerten Server-Weiterleitung, die laut Verständnisdokument zu 2.2.1 nicht betroffen ist.

Wie ersetze ich eine Meta-Refresh-Weiterleitung durch eine Server-Weiterleitung?

Lassen Sie den Server mit einem 3xx-Weiterleitungscode auf die neue Adresse antworten. Laut W3C sind solche nicht zeitgesteuerten Weiterleitungen von 2.2.1 nicht betroffen, weil sie sofort wirken. Eine Server-Weiterleitung, die erst nach einem Timeout auslöst, ist dagegen ein dokumentierter Fehler (F58).

Spielt die Verzögerung eines Meta Refresh für die Barrierefreiheit eine Rolle?

Das Prüfverfahren F41 prüft, ob der Wert kleiner als 1 oder größer als 72.000 Sekunden (20 Stunden) ist, doch dieser Schritt zählt nur für 2.2.1 und 2.2.4, nicht für 3.2.5. Kriterium 2.2.1 verlangt, dass jedes vom Inhalt gesetzte Zeitlimit abgeschaltet, angepasst oder verlängert werden kann, abgesehen von seinen Ausnahmen.

Welche WCAG-Kriterien betrifft Meta Refresh?

Fehler F41 bezieht sich auf drei Erfolgskriterien: 2.2.1 Zeitlimits anpassbar, 2.2.4 Unterbrechungen und 3.2.5 Änderung auf Anfrage. Er gilt für HTML.

Weiterlesen bei Conformly

Quellen

Dieser Artikel stützt sich auf die am Seitenende genannten offiziellen Quellen.