Barrierefreiheits-Prüfer

Prüfen Sie HTML-Ausschnitte auf häufige WCAG-Barrierefreiheitsprobleme mit umsetzbaren Verbesserungsvorschlägen

HTML-Eingabe

Was Wir Prüfen

Bild-Alt-Text

Prüft, ob alle <img>-Elemente alt-Attribute haben, damit Screenreader Bilder für Nutzer beschreiben können.

Formularbeschriftungen

Prüft, ob alle Formulareingaben zugeordnete Beschriftungen haben, entweder über <label for>, aria-label oder aria-labelledby.

Überschriftenhierarchie

Stellt sicher, dass Überschriften einer logischen Reihenfolge folgen (h1, h2, h3...), ohne Ebenen zu überspringen.

Linktext

Erkennt leere Links und generische Linktexte wie 'hier klicken', die für Screenreader-Nutzer nicht aussagekräftig sind.

Sprachattribut

Prüft auf ein lang-Attribut am <html>-Element, das Screenreadern hilft, die korrekte Aussprache zu verwenden.

ARIA & Interaktive Elemente

Prüft, ob interaktive Elemente geeignete Rollen und ARIA-Beschriftungen für die Unterstützung assistiver Technologien haben.

Barrierefreiheits-Prüfer

Prüfen Sie HTML-Ausschnitte auf häufige WCAG-Barrierefreiheitsprobleme mit umsetzbaren Verbesserungsvorschlägen

Funktionen

  • Parse pasted HTML locally with DOMParser and check for common WCAG issues
  • 12+ rule categories: alt text, form labels, heading hierarchy, empty links, ARIA usage, tabindex misuse, autoplay
  • No network calls — paste HTML, get instant feedback
  • NOT a full WCAG audit — for that use axe-core, Lighthouse, or a dedicated tool
  • Useful for quick sanity-checks during development

Anleitung

  1. Fügen Sie Ihren HTML-Code in den Eingabebereich ein oder laden Sie einen der Beispielausschnitte, um das Tool in Aktion zu sehen.
  2. Klicken Sie auf 'Barrierefreiheit Prüfen', um Ihr HTML auf häufige WCAG-Probleme anhand von mehr als 12 Barrierefreiheitsregeln zu analysieren.
  3. Überprüfen Sie die nach Schweregrad gruppierten Ergebnisse, lesen Sie die Verbesserungsvorschläge und aktualisieren Sie Ihr HTML, um die gefundenen Probleme zu beheben.

Tipps & Best Practices

  • Paste the HTML source (View Source / Inspect → Outer HTML) — the checker doesn't fetch URLs (CORS would block that anyway).
  • For a complete audit, use axe-core in your test suite or Lighthouse in DevTools — those check ~30 more rules including dynamic ones.
  • Heading hierarchy: each level should follow the previous (h1 → h2 → h3); skipping levels is flagged.
  • Alt text rule allows `alt=""` for purely decorative images — only missing/duplicate alt is flagged.
  • Form labels: every input should have an associated label (via `for` attribute) or `aria-label`. Placeholder-only is flagged.

FAQ

Welche Barrierefreiheitsprobleme prüft dieses Tool?

Dieses Tool prüft mehr als 12 häufige WCAG-Barrierefreiheitsprobleme, darunter: fehlende alt-Attribute an Bildern, Formulareingaben ohne zugeordnete Beschriftungen, Verletzungen der Überschriftenhierarchie (übersprungene Ebenen), leere Links und generische Linktexte, fehlendes lang-Attribut am HTML-Element, interaktive Elemente ohne ARIA-Rollen oder -Beschriftungen, leere Schaltflächen, veraltete HTML-Elemente, positive tabindex-Werte, die die Tab-Reihenfolge stören, Medienelemente mit autoplay und fehlende Dokumenttitel. Jedes Problem ist bestimmten WCAG-Erfolgskriterien zugeordnet.

Ersetzt dies ein vollständiges WCAG-Audit?

Nein, dieses Tool prüft häufige Probleme auf HTML-Ebene, die durch Analyse des Markups erkannt werden können. Ein umfassendes WCAG-2.1- oder -2.2-Audit erfordert Tests mit echten assistiven Technologien wie Screenreadern, die Prüfung von Farbkontrastverhältnissen, die Überprüfung der Tastaturnavigation, Tests dynamischer Inhaltsaktualisierungen und die Bewertung der kognitiven Barrierefreiheit. Dieses Tool ist ein hervorragender erster Schritt, um die häufigsten Probleme zu erkennen, bevor ein vollständiges manuelles Audit durchgeführt wird.

Was ist der Unterschied zwischen Fehlern und Warnungen?

Fehler weisen auf eindeutige Verletzungen der Barrierefreiheit hin, die Nutzer assistiver Technologien beeinträchtigen. Zum Beispiel ist ein fehlendes alt-Attribut an einem Bild ein Fehler, weil Screenreader das Bild nicht beschreiben können. Warnungen weisen auf potenzielle Probleme hin, die je nach Kontext problematisch sein können oder nicht. Zum Beispiel ist ein leeres alt-Attribut eine Warnung, weil es für dekorative Bilder richtig, für informative Bilder jedoch falsch ist. Bestandene Prüfungen bestätigen, dass eine bestimmte Prüfung erfüllt wurde.

Kann ich eine Live-Website-URL prüfen, anstatt HTML einzufügen?

Dieses Tool ist dafür konzipiert, HTML-Ausschnitte zu prüfen, die Sie direkt einfügen. Um Live-Websites zu testen, müssten Sie den Seitenquelltext anzeigen oder die Entwicklerwerkzeuge des Browsers verwenden, um das HTML zu kopieren, und es dann hier einfügen. Für Live-Website-Tests sollten Sie Browser-Erweiterungen wie axe DevTools oder Lighthouse in Betracht ziehen, die das gerenderte DOM einschließlich dynamisch generierter Inhalte inspizieren können.

Warum ist das lang-Attribut am HTML-Element so wichtig?

Das lang-Attribut teilt Screenreadern und anderen assistiven Technologien mit, in welcher Sprache der Inhalt verfasst ist. Ohne dieses Attribut könnte ein Screenreader versuchen, einen englischen Text mit französischen Ausspracheregeln vorzulesen, was den Inhalt unverständlich macht. Es beeinflusst auch, wie Browser mit Silbentrennung, Rechtschreibprüfung und anderen sprachabhängigen Funktionen umgehen. Das Setzen von lang ist eine der einfachsten, aber wirkungsvollsten Verbesserungen der Barrierefreiheit, die Sie vornehmen können.

Wird mein HTML-Code zur Analyse an einen Server gesendet?

Nein, die gesamte Analyse findet vollständig in Ihrem Browser mit JavaScript statt. Ihr HTML-Code verlässt nie Ihr Gerät. Das Tool parst das HTML mithilfe der im Browser integrierten DOMParser-API und führt alle Barrierefreiheitsprüfungen lokal durch. Dadurch ist es sicher für die Verwendung mit proprietärem Code, internen Projekten oder beliebigem HTML mit sensiblen Inhalten.