HTML-Barrierefreiheitsprüfer

Die meisten schnellen Barrierefreiheitsprüfungen sind entweder ein oberflächlicher Schlüsselwortscan oder eine umfangreiche Bibliothek, der Sie als Black Box vertrauen müssen. Dieses Tool geht einen dritten Weg: Es analysiert den von Ihnen eingefügten HTML-Code mit dem im Browser integrierten DOMParser – kein Axe-Core, keine externe Barrierefreiheitsbibliothek, nichts heruntergeladen – und überprüft dann den resultierenden DOM-Baum mit einer Reihe handschriftlicher Überprüfungen, die häufige, echte WCAG 2.1-Fehlermuster widerspiegeln. Das bedeutet, dass die Logik vollständig überprüfbar ist und die Prüfung vollständig in Ihrem Browser ausgeführt wird: Das von Ihnen eingefügte Markup und jedes von Ihnen getestete Farbpaar werden niemals hochgeladen oder irgendwohin gesendet.

Die Prüfungen decken die Fehler ab, die am häufigsten auf echten Seiten auftreten: <img>-Elemente ohne Alt-Attribut (ein echter WCAG-Fehler, der sich von dem absichtlich leeren alt="" unterscheidet, das für dekorative Bilder verwendet wird und korrekterweise nicht gekennzeichnet ist), Formularsteuerelemente, bei denen die unterstützende Technologie nicht erkennen kann, wozu sie dienen (überprüft anhand jedes echten Pfads zu einer Beschriftung – ein passendes <label für>, das in ein <label> eingeschlossen ist, oder ein aria-label/aria-labelledby-Attribut), Überschriftenebenen, die ohne springen Warnung (ein <h1> direkt zu einem <h3> oder ein Dokument ohne oder mit mehreren <h1>), Links ohne href oder mit vagen, nicht kontextbezogenen Texten wie „hier klicken“ oder „mehr lesen“ und ein fehlendes lang-Attribut, wenn ein vollständiges HTML-Dokument (nicht nur ein Fragment) eingefügt wird.

Das herausragende Stück ist echte Kontrastmathematik, keine oberflächliche Heuristik „sieht lesbar aus“. Für jedes Element, das eine Inline-Farbe und eine Hintergrundfarbe trägt, liest das Tool beide Werte, löst sie über die eigene CSS-Engine des Browsers in echte RGB-Zahlen auf (hex, rgb(), hsl() und benannte Farben wie „Tomate“ funktionieren also alle identisch) und berechnet für jedes Element die genaue relative WCAG-Luminanz – L = 0,2126×R + 0,7152×G + 0,0722×B, wobei jeder Kanal gammakorrigiert ist Verwenden Sie zunächst die echte sRGB-Übertragungskurve – bevor Sie sie in die offizielle Kontrastverhältnisformel (helleres L + 0,05) / (dunkleres L + 0,05) kombinieren. Die eigene Schriftgröße und Schriftstärke des Elements entscheidet darüber, ob die strengeren Schwellenwerte für „normalen Text“ oder die milderen Schwellenwerte für „großen Text“ (18pt+ oder 14pt+ fett) gelten, und das Ergebnis wird mit allen vier echten WCAG-Zahlen gleichzeitig verglichen: 4,5:1 und 3:1 für AA, 7:1 und 4,5:1 für AAA – nie zu einem einzigen falschen Gut/Schlecht-Urteil zusammengefasst.

Hierbei handelt es sich um eine bewusst ehrliche, pragmatische Teilmenge einer vollständigen Prüfung der Barrierefreiheit und nicht um ein Zertifizierungstool: Es werden keine JavaScript-gesteuerte Interaktivität, ARIA-Widget-Muster über die grundlegende Beschriftung hinaus, die Reihenfolge des Tastaturfokus oder alles, was das tatsächliche Rendern und Ausführen der Seite erfordert, nicht bewertet. Betrachten Sie es als einen schnellen ersten Durchgang, der einige der häufigsten und folgenreichsten WCAG-Fehler erkennt – fehlender Alt-Text, unbeschriftete Felder, fehlerhafte Überschriftenhierarchie, kontrastarmer Text und vage Links –, bevor eine Seite versendet wird, zusammen mit (nicht anstelle) einer vollständigen manuellen Überprüfung oder einem speziellen Prüftool für alles, was in die Produktion geht.