Wie wir testen und bewerten

Die Engine

Wir rendern Ihre Seite in einem echten Browser und lassen die feste, versionierte Engine axe-core 4.12 gegen die WCAG 2.1 und 2.2 Level AA laufen. Die exakte Version wird bei jedem Scan aufgezeichnet, damit ein Ergebnis später reproduzierbar und ein Bericht datierbar ist.

Dass die Seite tatsächlich gerendert wird, ist kein technisches Detail, sondern der Unterschied zwischen zwei Prüfungen. Ein Blick in den Quelltext sieht das HTML, das der Server ausliefert. Ihre Kundschaft sieht etwas anderes: das, was JavaScript daraus gebaut hat, mit eingeklapptem Menü, nachgeladenen Produktfiltern und einem Cookie-Banner darüber. Genau dort sitzen die Barrieren, die niemand bemerkt. Wir prüfen den Zustand, den ein Mensch vorfindet.

Die Version festzuschreiben statt automatisch zu aktualisieren, kostet uns Aufwand und ist Absicht. Eine neue Engine-Version bringt neue Regeln mit; derselbe Shop bekäme plötzlich einen anderen Wert, ohne dass sich an ihm etwas geändert hätte. Für einen Vergleich zweier Scans — und für einen Bericht, den Sie in einem halben Jahr noch erklären wollen — wäre das wertlos.

Ehrliche Abdeckung: ~30–57 %

Automatisierte Tests finden nur einen Teil der WCAG-Probleme. Wie groß dieser Teil ist, hängt von der Methode ab: Branchenübliche Schätzungen liegen bei rund 30 %, die Deque-Studie zu axe-core kommt auf bis zu 57 %. Wir nennen bewusst diese Spanne statt einer einzelnen Zahl — alles andere wäre geschönt.

Die beiden Zahlen widersprechen sich nicht — sie messen Verschiedenes. Der Branchenwert um 30 % zählt die WCAG-Erfolgskriterien, die sich überhaupt maschinell entscheiden lassen: rund ein Drittel des Regelwerks. Deque hat stattdessen gezählt, welcher Anteil der real gefundenen Fehler automatisch erkannt wurde, über tausende Audits hinweg — und kommt auf bis zu 57 %, weil sich einige wenige Fehlerarten millionenfach wiederholen. Beide Zahlen stimmen. Wer nur die höhere nennt, verkauft; wer nur die niedrigere nennt, ebenfalls.

Deshalb behaupten wir nie „100 % konform“ aus einem Scan. Was die Automatik nicht sicher entscheiden kann, markieren wir ausdrücklich zur manuellen Prüfung — und zählen es sichtbar mit, statt es aus dem Bericht zu lassen. Ein Wert, der nur das zeigt, was gut aussieht, wäre für eine Behörde und für Sie gleichermaßen nutzlos.

Was automatisch geprüft wird

Zuverlässig maschinell prüfbar sind u. a.: Farbkontrast, fehlende Alt-Texte, Formularbeschriftungen, Link- und Button-Namen, Überschriftenstruktur, Sprachauszeichnung, Dokumenttitel, ARIA-Fehler und Landmark-Regionen.

Diese Liste sieht kurz aus für „nur ein Drittel der Kriterien“ — sie trifft aber den Löwenanteil der real vorhandenen Fehler. Die WebAIM Million 2026 hat eine Million Startseiten geprüft: Sechs Fehlerarten machen 96 % aller gefundenen Verstöße aus, und alle sechs stehen oben. Die vollständigen Zahlen stehen im Ratgeber „Wie Sie Ihre Website auf Barrierefreiheit testen“. Genau deshalb lohnt ein automatischer Durchgang, obwohl er nur einen Teil des Regelwerks abdeckt.

Was ein Mensch prüfen muss

Ob ein Alt-Text inhaltlich sinnvoll ist, ob die Fokusreihenfolge logisch ist, ob Fehlermeldungen verständlich sind, ob Inhalte in einfacher Sprache vorliegen — das braucht Urteilsvermögen. Solche Punkte zählen wir als „manuell zu prüfen“ und senken damit nie den Wert.

Ein Beispiel macht die Grenze deutlich. Ein Produktbild trägt den Alt-Text „Bild“. Maschinell ist alles in Ordnung: Das Attribut ist vorhanden, nicht leer, kein Dateiname. Für eine Screenreader-Nutzerin ist es wertlos — sie erfährt, dass da ein Bild ist, aber nicht, welches Produkt sie kauft. Kein Prüfprogramm der Welt entscheidet das, weil dazu gehört zu wissen, was auf dem Foto zu sehen sein sollte.

Dasselbe gilt für die Bedienung mit der Tastatur, für Videountertitel, die zwar existieren, aber automatisch und falsch generiert wurden, und für Formulare, die technisch korrekt beschriftet sind und trotzdem niemand versteht. Wir markieren diese Punkte namentlich, damit Ihr manuelles Budget dorthin geht, wo es gebraucht wird — statt eine ganze Website noch einmal von Hand durchzugehen.

Wie der Wert 0–100 entsteht

Der Wert startet bei 100 und zieht je bestätigtem Problem einen gewichteten Abzug nach Schweregrad ab, mit 0 als Untergrenze. Punkte zur manuellen Prüfung senken den Wert nicht — wir bestrafen nur, was der Scan tatsächlich bestätigt hat. Der Website-Wert ist der Mittelwert der Seitenwerte.

Dass Punkte zur manuellen Prüfung den Wert nicht senken, ist eine bewusste Entscheidung gegen unser eigenes Verkaufsinteresse. Ein niedrigerer Wert wäre ein besseres Verkaufsargument. Er wäre aber unehrlich: Wir wissen an dieser Stelle nicht, ob ein Problem vorliegt — nur, dass eine Maschine es nicht entscheiden kann. Einen Shop dafür zu bestrafen, dass unsere Software an ihre Grenze stößt, wäre eine Aussage über uns, nicht über ihn.

Aus demselben Grund ist der Website-Wert ein einfacher Mittelwert der Seitenwerte und keine Gewichtung nach Bedeutung. Eine Gewichtung würde voraussetzen, dass wir wissen, welche Seiten Ihnen wichtig sind — das wissen wir nicht. Ein Mittelwert ist nachvollziehbar und lässt sich in einem Bericht erklären; eine Formel mit unsichtbaren Faktoren wäre genau das Blackbox-Siegel, das wir ablehnen.

Kein Overlay

Wir verändern Ihre Website nicht und legen kein Widget darüber. Wir prüfen Ihre echten Seiten und sagen Ihnen, was Sie im eigenen Code ändern müssen.

Overlays versprechen das Gegenteil: ein Skript einbinden, fertig. Sie verändern die Seite im Browser, ohne die Ursachen im Markup zu beseitigen — und sind in mehreren Ländern Gegenstand von Klagen geworden, weil Betroffene die überlagerte Seite schlechter bedienen konnten als die ursprüngliche. Ein Werkzeug, das Ihnen Arbeit abnimmt, indem es das Problem verdeckt, verlagert das Risiko nur zu Ihnen.

Was wir liefern, ist deshalb unbequemer: eine Liste konkreter Fundstellen mit CSS-Selektoren, die jemand in Ihrem Code ändern muss. Das dauert länger als ein Skript einzubinden, hält aber einer Prüfung stand — und Sie besitzen das Ergebnis, statt es zu mieten.