WCAG Überschriften-Prüfer

Was ist ein WCAG-Überschriftenprüfer?

Ein WCAG-Überschriftenprüfer validiert, dass die Überschriftenelemente auf einer Webseite (h1, h2, h3, h4, h5, h6) eine logische Hierarchie bilden, durch die Screenreader und andere Hilfstechnologien navigieren können. Überschriften sind die Art, wie blinde und sehbehinderte Nutzer eine Seite überfliegen: Sie verwenden eine Screenreader-Tastenkombination, um von Überschrift zu Überschrift zu springen und in Sekunden ein mentales Inhaltsverzeichnis aufzubauen. Wenn Überschriften fehlen, in der falschen Reihenfolge sind oder dekorativ verwendet werden, bricht diese Navigation zusammen. WCAG 2.2 Erfolgskriterium 1.3.1 (Info und Beziehungen) und 2.4.6 (Überschriften und Beschriftungen) verlangen, dass Überschriften die Struktur korrekt vermitteln.

Die Regeln sind einfach zu formulieren und leicht zu verletzen. Es sollte genau eine h1 pro Seite geben (den Seitentitel). Jede nachfolgende Überschrift sollte höchstens eine Ebene tiefer als ihr Elternteil sein (eine h2 kann von einer weiteren h2 oder einer h3 gefolgt werden, aber nicht direkt von einer h4). Überschriften sollten nicht leer sein. Überschriftenebenen sollten die Dokumentstruktur beschreiben, nicht die visuelle Größe (verwenden Sie nicht h4, nur weil Sie kleineren Text wollen). Die meisten Barrierefreiheits-Audits markieren Probleme mit der Überschriftenhierarchie als das Erste, was behoben werden muss, da sie häufig, leicht zu überprüfen und für Screenreader-Nutzer wirkungsvoll sind.

Dieses Werkzeug parst HTML, das Sie einfügen (kein Upload, keine Server-Roundtrip), durchläuft die Überschriftenelemente in Dokumentenreihenfolge und meldet die Probleme: fehlende h1, mehrere h1, übersprungene Ebenen, leere Überschriften und einen Überblick der Seitenstruktur. Die Ausgabe ist einfacher Text, der jedes Problem beschreibt. Führen Sie es auf jeder Seite während der Entwicklung aus, vor dem Start oder als Teil eines regelmäßigen Barrierefreiheits-Audit-Zyklus. Die Ausgabe ist in einfacher Sprache, keine numerische Bewertung; das Ziel ist, Ihnen spezifische zu behebende Probleme zu geben, keine Bestehensnote zu jagen.

Was im Werkzeug enthalten ist

Oben auf der Seite befindet sich ein Textbereich, in den Sie Ihren HTML einfügen. Sie können ein vollständiges Dokument (DOCTYPE, html, head, body) oder ein Fragment (nur den body-Inhalt) einfügen. Das Werkzeug extrahiert alle h1 bis h6 Elemente in Dokumentenreihenfolge unter Verwendung eines Standard-Browser-DOMParsers, sodass die Analyse mit dem übereinstimmt, was ein echter Browser tun würde. Der Textbereich verarbeitet Eingaben jeder Größe; sehr große Dokumente (Zehntausende von Zeilen) funktionieren, dauern aber eine Sekundenbruchteil länger zu analysieren.

Klicken Sie auf Überschriften prüfen und die Ergebnisse erscheinen unten. Der erste Abschnitt ist die Überschriftengliederung: jede Überschrift in Reihenfolge, nach Ebene eingerückt, sodass Sie die Struktur als Inhaltsverzeichnis lesen können. Der zweite Abschnitt ist die Problemliste: jedes Problem mit seinem spezifischen Standort, was falsch ist und eine kurze Erklärung, warum es wichtig ist. Probleme werden nach Schweregrad kategorisiert: Fehler (müssen für WCAG-Konformität behoben werden) und Warnungen (Best Practice, aber keine strikten Fehler).

Die Ausgabe bleibt im Browser; nichts wird hochgeladen. Sie können dasselbe HTML viele Male mit Bearbeitungen dazwischen einfügen, um Korrekturen zu iterieren. Das Werkzeug überprüft absichtlich nichts außerhalb der Überschriftenstruktur (es prüft keinen Alt-Text, Kontrast, Fokusreihenfolge, ARIA oder irgendein anderes WCAG-Kriterium). Verwenden Sie für diese dieses Werkzeug zusammen mit einem umfassenden Audit-Tool wie axe DevTools, Lighthouse oder WAVE.

Geschichte und Hintergrund

HTML-Überschriften von Anfang an (1991)

Tim Berners-Lee führte HTML 1991 mit h1- bis h6-Elementen als Teil der ursprünglichen 18 Tags ein. Die ursprüngliche semantische Absicht war immer Dokumentstruktur, nicht visuelles Styling. Die Hierarchie der Überschriften des Webs stammt aus einer viel älteren Tradition: gedruckte Dokumente (Bücher, Aufsätze, Regierungsberichte) verwenden seit Jahrhunderten nummerierte Abschnittsebenen, um Struktur zu vermitteln. HTML hat dieses Modell direkt geerbt. Trotz 35 Jahren stabiler Semantik ist Überschriftenmissbrauch einer der häufigsten Barrierefreiheitsfehler im modernen Web, weil Designer oft zuerst nach visueller Größe stylen und die Struktur danach überprüfen.

Screenreader lernen die Navigation per Überschrift (ab 1996)

JAWS (Job Access With Speech) wurde 1989 von Henter-Joyce veröffentlicht und fügte Webseiten-Überschriftennavigation hinzu, als das Web in den späten 1990er Jahren beliebt wurde. Das Drücken der H-Taste in JAWS springt zur nächsten Überschrift; die nummerierten Tasten 1 bis 6 springen zu dieser spezifischen Überschriftenebene. Jeder wichtige Screenreader seitdem (NVDA 2006, VoiceOver 2005, TalkBack auf Android) hat diese Tastenkombination kopiert. WebAIMs jährliche Screenreader-Nutzerumfrage findet konsistent, dass 67 bis 70 Prozent der Screenreader-Nutzer per Überschriften als ihre primäre Methode zum Verstehen einer Seite navigieren. Eine kaputte Überschriftenhierarchie ist daher kein kosmetisches Problem.

WCAG 1.0 und der Aufstieg der Barrierefreiheitsstandards (1999)

Die Web Content Accessibility Guidelines 1.0 wurden vom W3C im Mai 1999 veröffentlicht, der erste internationale Standard für Webbarrierefreiheit. WCAG 1.0 verlangte ausdrücklich, dass Überschriften für die Dokumentstruktur verwendet werden (Prüfpunkt 3.5). WCAG 2.0 (2008) verfeinerte dies in Erfolgskriterium 1.3.1 (Info und Beziehungen, Stufe A) und 2.4.6 (Überschriften und Beschriftungen, Stufe AA). WCAG 2.1 (2018) und 2.2 (2023) hielten diese Kriterien unverändert, weil die zugrunde liegende Anforderung solide ist. Die meisten Barrierefreiheitsgesetze weltweit (ADA in den USA, EAA in Europa, AODA in Ontario) zitieren jetzt WCAG 2.1 AA als gesetzliche Grundlage.

HTML5-Sektionierung und der Dokumentumriss (2014)

HTML5 (W3C-Empfehlung 2014) führte Sektionierungselemente (article, section, nav, aside) und einen Umrissalgorithmus ein, der die Überschriftenhierarchie aus der Verschachtelungstiefe ableiten sollte. Der Algorithmus wurde nie in einem Browser oder Screenreader implementiert und 2022 formell veraltet. Die praktische Anleitung lautet: verwenden Sie explizite Überschriftenebenen (h1 bis h6) und behandeln Sie Sektionierungselemente als semantische Gruppierung, nicht als Ersatz für Überschriftentiefe. Der HTML Living Standard besagt jetzt klar, dass Überschriftenebenen explizit gesetzt werden müssen.

ARIA-Rollen und aria-level (ab 2014)

WAI-ARIA 1.1 (W3C-Empfehlung 2017) bietet role="heading" mit aria-level="N" als alternative Möglichkeit, Überschriften zu kennzeichnen, nützlich, wenn Sie die nativen h1-h6 Elemente nicht verwenden können (zum Beispiel in einer Framework-Komponente, die verschiedene Überschriftenebenen in verschiedenen Kontexten rendern muss). Screenreader behandeln role="heading" identisch zum nativen Element. Best Practice ist die Verwendung nativer Elemente, wo möglich; verwenden Sie ARIA nur, wenn die native Semantik nicht verfügbar ist. Dieses Werkzeug prüft sowohl native Überschriftenelemente als auch Elemente mit role="heading".

Barrierefreiheitsklagen und der Geschäftsfall (ab 2017)

Domino's Pizza v. Robles (US Supreme Court 2019) etablierte, dass der Americans with Disabilities Act (ADA, 1990) auf kommerzielle Websites zutrifft. Hunderte ähnlicher Klagen folgten jedes Jahr (über 4.000 ADA-Webklagen allein 2024 eingereicht). Der European Accessibility Act (EAA, in Kraft Juni 2025) macht WCAG-äquivalente Barrierefreiheit zur gesetzlichen Anforderung für die meisten verbraucherorientierten Websites in der gesamten EU. Eine fehlgeschlagene Überschriftenstruktur ist eines der einfachsten Probleme, das Kläger identifizieren und dokumentieren können, was grundlegende Überschriftenprüfungen zu einem stark hebelnden Compliance-Schritt macht.

Praktische Arbeitsabläufe

Vor-Launch-Check auf neuen Seiten und Vorlagen

Bevor eine neue Seite oder Vorlage ausgeliefert wird, führen Sie den HTML durch diesen Prüfer. Probleme mit der Überschriftenstruktur sind die am einfachsten einzuführenden Barrierefreiheitsfehler (besonders in CMS-gesteuerten Inhalten, wo Editoren Überschriftenebenen basierend auf visueller Größe wählen) und die einfachsten zu beheben. Sie vor dem Start zu fangen ist viel billiger als danach, wenn Korrekturen Koordination mit Inhaltsverantwortlichen erfordern. Für Agenturen bauen Sie diese Prüfung in die QA-Checkliste ein; für interne Teams führen Sie sie als Teil der Code-Überprüfung oder vor dem Mergen zu main aus.

Auditing einer bestehenden Website auf Barrierefreiheits-Compliance

Für ein Barrierefreiheits-Audit (Vor-Litigation, EAA-Compliance, Vertragsanforderung) gehen Sie die meistbesuchten Seiten durch und führen Sie den HTML jeder Seite durch diesen Prüfer. Dokumentieren Sie die Ergebnisse: welche Seiten haben Überschriftenprobleme, welcher Typ, wie zu beheben. Kombinieren Sie mit axe DevTools oder Lighthouse für die anderen WCAG-Kriterien. Die Überschriftenstruktur-Ergebnisse sind normalerweise am einfachsten zu beheben und bilden einen soliden Quick-Win-Abschnitt des Audit-Berichts.

CMS-Editor-Schulung und Templating

CMS-gesteuerte Inhalte (WordPress, Drupal, Contentful, Sanity) geben Editoren oft ein Überschriften-Dropdown mit H1- bis H6-Optionen. Editoren, die die Regeln nicht kennen, wählen Ebenen nach visueller Größe. Demonstrieren Sie diesen Prüfer Editoren, damit sie sehen können, was ihre Überschriften-Auswahl produziert. Für Vorlagen führen Sie die gerenderte Ausgabe nach jedem Designwechsel durch den Prüfer, um zu bestätigen, dass die Überschriften-Auswahl des Editors immer noch eine gültige Hierarchie produziert. Viele CMS-Plugins existieren, die Editoren zur Schreibzeit warnen; dieses Werkzeug dient dem Verifikationsschritt.

Validierung von E-Mail-Vorlagen und HTML-Newslettern

HTML-E-Mails, die von Screenreadern gelesen werden, sollten der gleichen Überschriftenhierarchie wie Webseiten folgen. Führen Sie den HTML Ihrer E-Mail-Vorlage durch diesen Prüfer, bevor Sie an eine große Liste senden. Häufige E-Mail-Vorlagen-Probleme: mehrere h1 (wenn jeder Abschnitt seine eigene Überschrift hat), fehlende h1 (wenn das Layout direkt mit h2 beginnt) und dekorative h4, die rein für kleine Überschriften verwendet werden. Beheben Sie diese vor dem Versand; Hilfstech-Nutzer auf Ihrer Liste werden es bemerken.

Validierung von PDF-zu-HTML-Konvertierungen

Wenn Sie PDFs in HTML für Barrierefreiheit konvertieren (damit sie von Screenreadern mit Überschriftennavigation gelesen werden können), muss der Konverter PDF-Strukturtags auf HTML-Überschriftenebenen abbilden. Das Ergebnis ist oft kaputt: PDFs ohne richtige Auszeichnung produzieren flachen HTML ohne Überschriften, und sogar getaggte PDFs produzieren manchmal All-h1- oder All-h2-Ausgabe. Führen Sie den konvertierten HTML durch diesen Prüfer, um das Problem zu erkennen, bevor Sie die konvertierte Seite veröffentlichen.

Onboarding neuer Entwickler und Designer

Junior-Front-End-Entwickler und Designer profitieren davon, konkrete Beispiele einer kaputten Überschriftenhierarchie und der resultierenden Screenreader-Erfahrung zu sehen. Kombinieren Sie dieses Werkzeug mit einer Screenreader-Demo (NVDA auf Windows ist kostenlos, VoiceOver auf Mac ist eingebaut), um zu zeigen, wie Überschriften die Screenreader-Navigation antreiben. Die Verbindung zwischen abstrakten Überschriftenregeln und konkreter Nutzererfahrung ist oft das, was die Lektion festigt.

Häufige Fallstricke

Überschriftenebene nach visueller Größe wählen

Der häufigste Fehler: ein h4 verwenden, weil Sie kleineren Text wollen, oder von h2 zu h4 springen, weil es kein h3 in der richtigen Größe im Design gibt. Überschriftenebenen sind strukturell, nicht visuell; verwenden Sie CSS zur Steuerung der Größe und verwenden Sie die Ebene, die mit der Dokumenthierarchie übereinstimmt. Wenn Ihr Design-System keinen visuellen Stil für jede benötigte Ebene hat, fügen Sie einen hinzu (oder überschreiben Sie mit Klassennamen), anstatt die falsche Ebene zu wählen.

Mehrere h1 pro Seite

Eine Seite sollte genau ein h1 haben, das den Seitentitel repräsentiert. Häufige Fehler: ein Site-Logo in h1 eingewickelt plus ein Artikeltitel auch in h1 (zwei h1), eine Startseite, bei der jeder Hero-Abschnitt h1 verwendet (mehrere h1), oder gar kein h1, weil das Layout mit h2 beginnt. Die Korrektur ist strukturell: wählen Sie den wichtigsten Inhalt auf der Seite als einzigen h1 und stufen Sie alles andere auf h2 oder darunter herab. Tools wie axe und Lighthouse warnen aus diesem Grund vor mehreren h1.

Übersprungene Überschriftenebenen

Von h2 direkt zu h4 zu gehen bricht den Dokumentumriss. Screenreader-Nutzer, die sich von Überschrift zu Überschrift bewegen, erwarten, dass jedes h4 unter einem h3 verschachtelt ist, und das fehlende h3 verwirrt die Struktur. Die Korrektur ist, die fehlende Zwischenebene einzufügen oder das h4 zu h3 herabzustufen. Die häufigste Ursache ist das Kopieren von Design aus einem Mockup, wo die visuelle Hierarchie drei Größen verwendet, aber das Design-System vier Überschriftenebenen verwendet; nach jedem Komponenten-Update erneut prüfen.

Leere Überschriften

Eine h2 ohne Textinhalt (oft weil ein JavaScript-Widget den Text entfernt aber das Element behalten hat) erscheint in der Überschriftenliste des Screenreaders als unbeschriftete Überschrift, was verwirrend und nutzlos ist. Füllen Sie entweder die Überschrift mit Text oder entfernen Sie das Überschriftenelement vollständig. Dies ist häufig in Single-Page-Apps, wo Platzhalterelemente gerendert werden, bevor Daten geladen werden; rendern Sie die Überschrift nur, wenn es Inhalt gibt, der hineingelegt werden kann.

Überschriften in nicht-semantischen Wrappern

Eine Überschrift, die in einem div mit role="presentation" oder aria-hidden="true" eingewickelt ist, wird aus dem Accessibility-Baum entfernt, was eine ansonsten korrekte Überschrift vor Screenreadern verbergen kann. Auditieren Sie die übergeordneten Elemente jeder Überschrift, um sicherzustellen, dass sie die Überschrift nicht aus dem Accessibility-Baum entfernen. CSS display:none und visibility:hidden entfernen die Überschrift ebenfalls; verwenden Sie diese nur absichtlich und niemals bei Inhalten, die für Screenreader sichtbar sein sollten.

ARIA verwenden, wenn natives HTML ausreichen würde

Das Hinzufügen von role="heading" aria-level="2" zu einem div anstelle der Verwendung eines h2-Elements funktioniert für die Barrierefreiheit, ist aber unnötige Komplexität. Native h1-h6-Elemente erhalten Überschriftensemantik kostenlos, rendern korrekt in Standard-Browser-Stilen und überleben Screenreader-Bugs besser als ARIA-Überschreibungen. Die erste Regel von ARIA (gemäß den WAI-ARIA Authoring Practices) lautet: Verwenden Sie kein ARIA, wenn natives HTML die gleiche Semantik bietet. Verwenden Sie native Überschriftenelemente, es sei denn, eine Framework-Einschränkung erzwingt wirklich ARIA.

Datenschutz und Datenverarbeitung

Der HTML, den Sie einfügen, bleibt während der gesamten Prüfung in Ihrem Browser. Der DOMParser, der die Überschriften extrahiert, läuft in JavaScript auf Ihrer Maschine; die Ergebnisse werden auf der Seite unter dem Textbereich gerendert. Es gibt keinen Upload-Schritt, keine Fernverarbeitung und keine Telemetrie darüber, welchen HTML Sie eingefügt haben. Das ist wichtig, weil der HTML, den Sie am ehesten prüfen wollen (Vor-Launch-Vorlagen, Kunden-Websites unter NDA, interne Admin-Seiten), genau das ist, was Sie nicht in einen Drittanbieter-SaaS-Validator einfügen sollten.

Sobald die Seite geladen ist, funktioniert das Werkzeug offline. Sie können die Internetverbindung trennen, HTML einfügen, die Prüfung ausführen und die Ergebnisse überprüfen, ohne dass Ihr Markup jemals eine andere Maschine berührt. Die meisten Cloud-Barrierefreiheitsprüfer (PowerMapper, Tenon, Site Improve) verlangen das Hochladen der Seiten-URL oder des HTMLs; für vertrauliche Seiten ist das genau der Fehlermodus, den Sie vermeiden sollten.

Wann dieses Werkzeug nicht zu verwenden ist

Für vollständige WCAG-Audits (verwenden Sie ein umfassendes Werkzeug)

Die Überschriftenstruktur ist eines von Dutzenden WCAG-Kriterien. Für ein vollständiges Audit verwenden Sie axe DevTools (kostenlose Chrome/Firefox-Erweiterung von Deque), Lighthouse (in Chrome eingebaut), WAVE (WebAIMs kostenloses Werkzeug) oder eine kostenpflichtige Lösung wie Tenon oder PowerMapper. Diese prüfen Farbkontrast, Alt-Text, ARIA-Nutzung, Formularbeschriftungen, Fokusreihenfolge und vieles mehr. Führen Sie dieses Werkzeug zusammen mit den umfassenden aus, nicht stattdessen.

Für dynamische Inhalte (testen Sie das gerenderte DOM)

Wenn Ihre Überschriften von JavaScript generiert werden (React, Vue, Svelte, Angular), enthält die statische HTML-Quelle nicht die endgültigen Überschriften. Sie müssen das gerenderte DOM einfügen, nachdem JavaScript ausgeführt wurde. Verwenden Sie die Browser-DevTools: öffnen Sie die Seite, öffnen Sie DevTools, Tab Elements, Rechtsklick auf body oder main, Copy outerHTML, dann fügen Sie das in diesen Prüfer ein. Oder verwenden Sie eine Browser-Erweiterung, die das Live-DOM direkt durchläuft.

Für automatisierte CI/CD-Pipelines (verwenden Sie eine Node-Bibliothek)

Wenn Sie möchten, dass Überschriftenprüfungen automatisch bei jedem Commit oder Pull Request laufen, integrieren Sie axe-core, Pa11y oder jest-axe in Ihre Test-Suite. Sie führen Überschriftenprüfungen (und viele andere WCAG-Prüfungen) headless im CI aus. Dieses Browser-Werkzeug ist für interaktive Nutzung während Entwicklung und Überprüfung, nicht für Automatisierung. Beide haben ihren Platz; verwenden Sie das Browser-Werkzeug für einmalige Audits und die CI-Bibliothek für kontinuierliche Validierung.

Für PDF- oder Word-Dokument-Barrierefreiheit

PDFs und Word-Dokumente haben ihre eigenen Barrierefreiheits-Tagging-Systeme (PDF/UA, die Word-Überschriftenstile). Sie verwenden keine HTML-Überschriften, daher trifft dieses Werkzeug nicht zu. Für PDF-Barrierefreiheit verwenden Sie den Adobe Acrobat Pro Accessibility Checker oder PAC 2024 (kostenlos, auf PDF/UA fokussiert). Für Word verwenden Sie den eingebauten Accessibility Checker (Tab Überprüfen). Konvertieren Sie zuerst zu HTML, wenn Sie dieses Werkzeug verwenden möchten, aber die Konvertierung selbst kann Überschriftenprobleme einführen.

Weitere Fragen

Ist es jemals OK, eine Überschriftenebene zu überspringen?

Nicht in geradem Dokumentinhalt. WCAG 2.2 SC 1.3.1 impliziert, dass Überschriften eine hierarchische Reihenfolge bilden sollten. Der eine häufige Fall, wo es wie ein Sprung aussieht, ist der Seitenumriss, der bei h1 beginnt und dann h2 innerhalb des Hauptinhaltsbereichs hat, während eine Seitenleiste oder Navigation auch h2 hat; das ist in Ordnung, weil beide Geschwister unter dem h1 der Seite sind. Die tatsächliche Regel lautet: überspringen Sie keine Ebenen innerhalb eines zusammenhängenden Inhaltsflusses. Der Prüfer markiert nur echte Sprünge.

Was, wenn mein Framework nur eine Überschriftenebene unterstützt?

Einige Komponentenbibliotheken rendern Überschriften auf einer festen Ebene (immer h2, unabhängig von der Verschachtelung). Die Korrektur ist, eine Level-Prop auf der Überschriften-Komponente offenzulegen (h2, h3 usw.) und Eltern den entsprechenden Wert übergeben zu lassen. Frameworks wie React tun dies häufig; wenn Ihres nicht, fügen Sie ein aria-level auf der Komponente hinzu und verwenden Sie role="heading" als temporären Workaround, bis Sie refaktorieren können. Langfristig sollte jede wiederverwendbare Überschriften-Komponente eine Level-Prop akzeptieren.

Prüft das Werkzeug ARIA-Rollen wie role="heading"?

Ja. Jedes Element mit role="heading" und einem gültigen aria-level-Attribut (1 bis 6) wird als Überschrift auf der angegebenen Ebene behandelt. Native h1-h6-Elemente werden immer bevorzugt, aber ARIA-markierte Überschriften sind gleichermaßen gültig für Screenreader und werden zusammen mit den nativen geprüft.

Wie wichtig ist die Überschriftenhierarchie im Vergleich zu anderen WCAG-Kriterien?

Sehr. WebAIMs jährliche Screenreader-Nutzerumfrage findet konsistent, dass 67-70% der Screenreader-Nutzer per Überschriften als ihre primäre Methode zum Verstehen einer Seite navigieren. Schlechte Überschriften blockieren effektiv eine der Hauptmethoden der Barrierefreiheitsnavigation. In WebAIMs jährlicher WebAIM Million-Analyse gehören Überschriftenprobleme zu den fünf häufigsten Barrierefreiheitsfehlern im Web. Die Kombination aus hoher Nutzerwirkung und einfacher Erkennung macht sie zur obersten Priorität.

Sollte jede Seite ein h1 haben?

Ja, mit seltenen Ausnahmen. Jedes vollständige HTML-Dokument sollte genau ein h1 haben, das den Seitentitel repräsentiert. Die Ausnahme sind Fragmente, die explizit in eine größere Seite eingefügt werden (eine E-Mail-Signatur, ein in eine andere Seite eingebettetes Widget); die Host-Seite liefert das h1 und das Fragment beginnt bei h2 oder darunter. Für eigenständige Seiten ist fehlendes h1 ein klarer Barrierefreiheitsfehler.

Kann ich diesem Werkzeug für rechtliche Compliance-Audits vertrauen?

Für Überschriftenstruktur speziell, ja: die Regeln sind präzise und das Werkzeug implementiert sie genau. Für die gesamte WCAG-Compliance reicht kein einzelnes automatisiertes Werkzeug aus; manuelle Tests mit Hilfstechnologie, Experten-Überprüfung und Benutzertests mit Behinderten Benutzern sind für Audits von rechtlicher Qualität erforderlich. Verwenden Sie dieses Werkzeug als einen von mehreren Eingaben in Ihrem Audit, nicht als alleinige Wahrheitsquelle für die Compliance.