Struktur-Check: HTML-Struktur online prüfen

„Ist meine Seite barrierefrei?“ ist die meistgestellte Frage und die am schlechtesten beantwortete. Der Struktur-Check beantwortet einen klar umrissenen Teil davon: Er lädt deine Seite und prüft ihre Auszeichnung gegen zwölf Punkte, die sich ohne Interpretationsspielraum entscheiden lassen – und sagt danach ebenso klar, wie viel er nicht gesehen hat.

Das Wichtigste in Kürze

• Der Check prüft zwölf maschinell entscheidbare Punkte aus vier WCAG-Prinzipien: Sprachauszeichnung, Seitentitel, Überschriften, Landmarks, Sprunglink, Alternativtexte, Formularbeschriftungen, Namen von Bedienelementen, Linktexte, Zoom-Sperre, Sprachwechsel und Untertitel-Spuren.
• Es gibt bewusst keinen Score und keine Prozentzahl. Eine Zahl würde eine Vollständigkeit behaupten, die keine automatische Prüfung hat – gezählt wird „bestanden, Hinweis, Fehler“.
• Automatische Prüfungen decken je nach Erhebung rund ein Drittel der WCAG-Kriterien ab. Tastaturbedienung, Fokusreihenfolge, Verständlichkeit und die Frage, ob ein Alternativtext inhaltlich passt, bleiben Handarbeit.
• Aufgenommen wurde nur, was eindeutig ist. Ein Fehlalarm kostet mehr Vertrauen als eine fehlende Prüfung – deshalb fehlen hier bewusst Prüfungen, die andere Werkzeuge mitliefern.
• Jeder Befund nennt vier Dinge: was gefunden wurde (mit Fundstelle im Code), warum es zählt, welches Kriterium betroffen ist und wo die Lösung steht.
• Die Befunde sind nach den vier Prinzipien (POUR) gruppiert, nicht nach technischem Detail – wer „Wahrnehmbar: 1 Fehler“ liest, versteht die Systematik nebenbei.
• Geprüft wird eine URL, kein Crawl. Weder die Adresse noch das Ergebnis werden gespeichert; ohne JavaScript funktioniert der Check ebenfalls, dann als eigene Ergebnisseite.
• Ein Copy-Button gibt das Ergebnis als Text aus – zum Einfügen in Ticket, Mail oder Briefing, mit allen Links.

Was dieser Check prüft – und was nicht

Der Check holt genau eine URL, wertet das ausgelieferte HTML aus und prüft die Auszeichnung. Das ist eine ehrliche, aber schmale Basis, und die Grenzen sind größer als der Umfang:

• Kein Crawl. Eine Adresse, eine Auswertung. Für eine Website mit fünf Seitentypen sind also fünf Durchläufe fällig – das ist der sinnvollere Weg als ein Sammelbericht, in dem niemand die Fundstellen wiederfindet.
• Kein JavaScript. Geprüft wird, was der Server ausliefert. Was eine Anwendung erst im Browser aufbaut, sieht der Check nicht. Für solche Seiten sind Browser-Erweiterungen wie axe DevTools der richtige Weg.
• Keine Bedienung. Tastaturweg, Fokusreihenfolge, Fokusfallen und Zustände wie Hover oder geöffnete Menüs kann eine Auswertung des Quelltexts grundsätzlich nicht sehen. Dafür gibt es den Durchgang von Hand: Barrierefreiheit selbst testen.
• Keine Inhalte. Ob ein Alternativtext passt, ob eine Fehlermeldung verständlich ist, ob eine Überschrift beschreibt, was unter ihr steht – das sind Urteile, keine Messungen.
• Keine Farben. Kontraste misst der Kontrast-Check, der dieselbe Eingabe versteht. Farbe geprüft, jetzt die Struktur – oder umgekehrt.
• Keine Rechtsaussage. Ob dein Angebot unter das BFSG fällt und wie es dasteht, klären der BFSG-Schnelltest und die BFSG-Prüfung.

Die zwölf Prüfungen im Einzelnen

Jede Prüfung hat dieselbe Struktur: was geprüft wird, warum es zählt, welches Kriterium betroffen ist und welche Seite die Lösung beschreibt. Der Zusatzbefund am Ende ist keine WCAG-Frage, sondern eine Pflicht aus dem BFSG.

1. Sprache der Seite

   Verständlich

   Hat das html-Element ein lang-Attribut, und ist der Sprachcode gültig?

   Ohne gültige Sprachangabe spricht der Screenreader die Seite in der falschen Sprache aus – deutscher Text mit englischer Aussprache ist unverständlich.

   Kriterium WCAG 3.1.1 Sprache der Seite · Lösung Dokument-Metadaten richtig setzen

2. Seitentitel

   Bedienbar

   Gibt es einen title, ist er gefüllt und beschreibt er die Seite statt nur die Marke?

   Der Seitentitel ist das Erste, was ein Screenreader beim Laden vorliest, und der Text im Tab, im Verlauf und im Lesezeichen.

   Kriterium WCAG 2.4.2 Seitentitel · Lösung Title-Tag und Meta-Description schreiben

3. Überschriften-Hierarchie

   Wahrnehmbar

   Genau eine h1, keine übersprungenen Ebenen, keine leeren Überschriften.

   Screenreader-Nutzerinnen springen von Überschrift zu Überschrift. Eine gesprungene Ebene wirkt wie ein fehlendes Kapitel.

   Kriterium WCAG 1.3.1 Info und Beziehungen · Lösung Überschriften-Hierarchie (h1–h6)

4. Landmarks und main

   Wahrnehmbar

   Genau ein main-Element, dazu header, nav und footer als Landmarks.

   Landmarks sind die Abkürzungen der Seite: Ohne main gibt es keinen Sprung zum Inhalt, mit zwei main keine eindeutige Zielmarke.

   Kriterium WCAG 1.3.1 Info und Beziehungen · Lösung Landmarks und Dokument-Outline

5. Sprunglink zum Inhalt

   Bedienbar

   Ist der erste fokussierbare Link ein Sprunglink, und existiert sein Ziel?

   Ohne Sprunglink tabbt man sich bei jedem Seitenaufruf erneut durch die komplette Navigation.

   Kriterium WCAG 2.4.1 Blöcke umgehen · Lösung Skip-Links richtig bauen

6. Alternativtexte für Bilder

   Wahrnehmbar

   Bilder ohne alt-Attribut (Fehler), Bilder mit leerem alt (Hinweis) und alt-Texte, die nach Dateinamen aussehen.

   Fehlt das Attribut ganz, lesen Screenreader die Bildadresse vor. Ein leeres alt ist dagegen oft genau richtig – nämlich bei Dekoration.

   Kriterium WCAG 1.1.1 Nicht-Text-Inhalte · Lösung Alt-Text-Entscheidungshilfe

7. Beschriftung von Formularfeldern

   Verständlich

   Jedes Eingabefeld braucht ein label, ein aria-label oder ein aria-labelledby mit echtem Ziel.

   Ein Feld ohne Beschriftung wird als „Eingabefeld“ angesagt. Was hineingehört, bleibt offen – Platzhaltertext zählt nicht als Beschriftung.

   Kriterium WCAG 3.3.2 Beschriftungen oder Anweisungen · Lösung Labels und Beschriftungen

8. Zugängliche Namen von Bedienelementen

   Robust

   Links und Buttons ohne Text (typisch: Icon-Buttons) sowie iframes ohne title-Attribut.

   Ohne Namen meldet der Screenreader nur „Schaltfläche“ oder „Frame“. Per Sprachsteuerung ist so ein Element gar nicht ansprechbar.

   Kriterium WCAG 4.1.2 Name, Rolle, Wert · Lösung Icons und SVGs zugänglich benennen

9. Aussagekräftige Linktexte

   Bedienbar

   Linktexte wie „hier“, „mehr“ oder „weiterlesen“ und Links, deren Text eine nackte URL ist.

   Screenreader können sich alle Links einer Seite als Liste ausgeben lassen. Zwölfmal „mehr erfahren“ ist dort zwölfmal dasselbe.

   Kriterium WCAG 2.4.4 Linkzweck (im Kontext) · Lösung Buttons und Links unterscheiden

10. Zoom nicht gesperrt

    Wahrnehmbar

    meta viewport mit user-scalable=no oder maximum-scale unter 2.

    Wer die Seite auf dem Telefon nicht vergrößern kann, liest sie nicht. Das ist eine Zeile im head – und ein sicherer Verstoß.

    Kriterium WCAG 1.4.4 Textgröße ändern · Lösung Reflow, Zoom und Textabstände

11. Sprachauszeichnung im Text

    Verständlich

    Sind alle lang-Attribute im Dokument syntaktisch gültig, und gibt es überhaupt welche?

    Ein falscher Sprachcode ist schlimmer als keiner: Der Screenreader wechselt die Stimme und liest den Absatz unverständlich vor.

    Kriterium WCAG 3.1.2 Sprache von Teilen · Lösung Textauszeichnung (strong, time, abbr …)

12. Eingebettete Medien

    Wahrnehmbar

    video-Elemente ohne track-Element für Untertitel.

    Ohne Untertitel-Spur ist ein Video für gehörlose und schwerhörige Menschen stumm – und für alle, die ohne Ton schauen.

    Kriterium WCAG 1.2.2 Untertitel (aufgezeichnet) · Lösung Untertitel, Transkripte und Audiodeskription

13. Barrierefreiheitserklärung verlinkt

    Zusatzbefund

    Führt von dieser Seite ein Link zu einer Barrierefreiheitserklärung?

    Das ist keine WCAG-Frage, sondern eine Pflicht aus dem BFSG beziehungsweise der BITV – und sie wird beim Blick von außen als Erstes geprüft.

    Rechtsgrundlage Barrierefreiheitserklärung erstellen · Lösung Muster-Barrierefreiheitserklärung

Warum es hier keinen Score gibt

Ein Wert wie „98 von 100“ ist das erfolgreichste Format der Branche und zugleich ihr größtes Missverständnis. Er suggeriert drei Dinge, die nicht stimmen: dass alle Kriterien geprüft wurden, dass sie sich gegeneinander verrechnen lassen und dass ein hoher Wert Konformität bedeutet.

Keines davon trifft zu. Eine Seite mit einem einzigen Fehler – Zoom gesperrt – ist für Menschen mit Sehbehinderung praktisch unbrauchbar und bekäme trotzdem 97 Punkte. Eine andere mit zwölf schwachen Linktexten ist mühsam, aber benutzbar, und stünde schlechter da. Der Score behandelt beide gleich, weil er zählt statt zu gewichten.

Deshalb nennt dieser Check die Zahlen getrennt: bestanden, Hinweise, Fehler. Drei Zahlen sind unbequemer als eine – aber sie behaupten nichts, was sie nicht wissen. Und direkt unter der Zusammenfassung steht, wie viele Kriterien der Check überhaupt betrachtet hat. Der Kasten lässt sich nicht wegklicken; er ist Teil des Ergebnisses, nicht das Kleingedruckte darunter.

Befunde priorisieren: erst Blocker, dann Volumen

Ein Ergebnis mit zwanzig Fundstellen wirkt erdrückend, ist es aber meistens nicht. In der Praxis hat sich diese Reihenfolge bewährt:

Zuerst die Blocker. Gesperrter Zoom, ein fehlendes main, ein Sprunglink ins Leere, Formularfelder ohne Beschriftung: Das sind einzelne Zeilen, die für einzelne Gruppen alles entscheiden. Sie kosten Minuten und wirken sofort.

Dann das Volumen. Fünfzig Bilder ohne alt sind ein Datenpflege-Thema, kein Entwicklungsthema. Hier lohnt der Blick ins CMS: Meist erzeugt eine einzige Template-Zeile oder ein Feld ohne Pflichtprüfung alle fünfzig Fälle auf einmal. Welchen Wert die einzelnen Bilder brauchen, klärt die Alt-Text-Entscheidungshilfe.

Zuletzt die Struktur. Übersprungene Überschriftenebenen und fehlende Landmarks sind selten dringend, aber sie sind der Unterbau: Wer sie beim Relaunch mitnimmt, spart sich die Nacharbeit an fünfzig Einzelseiten. Der systematische Weg dorthin steht unter Landmarks und Dokument-Outline und Überschriften-Hierarchie.

So gehst du nach dem Check weiter

1. Ergebnis sichern. Der Copy-Button gibt alles als Text aus – inklusive Fundstellen und Links. Das ist der Stand, gegen den du später vergleichst.
2. Fehler von Hinweisen trennen. Fehler sind eindeutige Verstöße. Hinweise sind Stellen, an denen ein Mensch entscheiden muss, ob es eines ist.
3. Blocker sofort beheben. Zoom, main, Sprunglink, Formularbeschriftungen – meist eine Stunde Arbeit für den größten Teil der Wirkung.
4. Ursache statt Symptom suchen. Tritt ein Befund mehrfach auf, liegt er fast immer im Template, nicht auf der Seite.
5. Farbe nachziehen. Dieselbe URL durch den Kontrast-Check schicken – zusammen decken beide Werkzeuge den maschinell prüfbaren Teil weitgehend ab.
6. Von Hand weiterprüfen. Der Durchgang mit Tab, Umschalt+Tab, Enter und Leertaste findet in fünf Minuten mehr als jeder Scanner. Die Anleitung dazu steht unter Barrierefreiheit selbst testen.
7. Nachprüfen und dokumentieren. Nach der Korrektur denselben Check erneut laufen lassen und den Stand in die Barrierefreiheitserklärung übernehmen – eine Erklärung, die vorhandene Lücken benennt, steht besser da als eine, die pauschal Konformität behauptet.

Struktur-Check, Selbsttest oder BITV-Test?

Die drei Wege beantworten verschiedene Fragen, und die Reihenfolge ist keine Frage des Budgets, sondern der Logik.

Der Struktur-Check beantwortet: Ist die Auszeichnung technisch in Ordnung? Er dauert Sekunden, kostet nichts und findet die Fehler, die sich ohne Urteil erkennen lassen. Als Erstdiagnose und als Kontrolle nach jeder Korrektur.

Der Selbsttest beantwortet: Lässt sich die Seite bedienen? Tastatur, Zoom auf 200 Prozent, ein Durchgang mit dem Screenreader. Dafür braucht es kein Zertifikat, nur eine Stunde und die Anleitung. Hier liegt der größere Teil der Befunde.

Der BITV-Test oder ein Audit beantwortet: Ist die Konformität belastbar nachgewiesen? Ein geprüftes Verfahren mit 98 Prüfschritten, durchgeführt von Menschen, mit einem Bericht, der vor Behörden und im Vergabeverfahren trägt. Was das umfasst, steht unter BITV-Test, Audit und VPAT; wie sich die verfügbaren Werkzeuge unterscheiden, zeigt der Werkzeugvergleich.

Kurz: Der Struktur-Check ersetzt keinen der beiden anderen Wege. Er sorgt dafür, dass man sie nicht mit Fehlern beginnt, die eine Maschine in Sekunden findet.

Häufige Fragen

Warum weicht das Ergebnis von axe oder Lighthouse ab?

Weil andere Dinge geprüft werden. axe und Lighthouse laufen im Browser und sehen auch, was JavaScript nachlädt; dieser Check bewertet das ausgelieferte HTML. Außerdem ist der Prüfumfang hier bewusst schmaler: Aufgenommen wurde nur, was ohne Interpretationsspielraum entscheidbar ist. Weniger Befunde bedeuten hier also nicht „besser“, sondern „strenger ausgewählt“.

Werden die geprüfte URL oder das Ergebnis gespeichert?

Nein. Die Adresse wird verwendet, um die Seite einmalig abzurufen, danach nicht mehr. Gespeichert wird ausschließlich ein anonymer Zähler für die Ratenbegrenzung – ohne URL, ohne IP-Adresse im Klartext.

Warum lässt sich meine Seite nicht prüfen?

Drei Ursachen kommen praktisch immer infrage: Ein Bot-Schutz blockiert den Abruf, die Seite liegt hinter einer Anmeldung, oder der Inhalt entsteht komplett im Browser. In allen drei Fällen hilft eine Browser-Erweiterung, die direkt auf der geöffneten Seite läuft. Interne Adressen wie localhost werden aus Sicherheitsgründen abgelehnt.

Reicht ein bestandener Struktur-Check für die BFSG-Konformität?

Nein, und das ist keine Bescheidenheit. Zwölf maschinell prüfbare Punkte sind ein Bruchteil der 55 A- und AA-Kriterien, die die EN 301 549 in Bezug nimmt. Ein sauberes Ergebnis heißt: Die geprüften Punkte stimmen. Es heißt nicht, dass die Seite barrierefrei ist.

Funktioniert der Check ohne JavaScript?

Ja. Ohne JavaScript sendet das Formular die Adresse an den Server, und du bekommst dieselbe Auswertung als eigene HTML-Seite zurück – mit denselben Befunden, Fundstellen und Links.

Verwandte Themen

• Kontrast-Check – dieselbe Eingabe, die andere Hälfte der maschinell prüfbaren Kriterien
• Barrierefreiheit selbst testen – der manuelle Durchgang, der die anderen zwei Drittel abdeckt
• Prüfwerkzeuge im Vergleich – was axe, WAVE, Lighthouse und dieser Check jeweils finden
• Die vier Prinzipien (POUR) – die Systematik, nach der die Befunde gruppiert sind
• BFSG-Checkliste für Websites – der technische Teil lässt sich mit dem Check vorprüfen

Quellen

• Understanding WCAG 2.2 – Normtext und Auslegung zu jedem der geprüften Kriterien
• W3C WAI: Evaluating Web Accessibility Overview – Einordnung, welchen Anteil automatische Prüfung abdecken kann
• EN 301 549 – die europäische Norm, über die WCAG 2.2 auf Stufe AA für BFSG und BITV verbindlich wird