Die Abmahnung schreibt ein Roboter

Jahrzehntelang wurde Title III des Americans with Disabilities Act wörtlich gelesen: eine Rampe zum Eingang, Beschilderung in Brailleschrift, eine barrierefreie Toilette. Alles über Gebäude. Der Bruch kam, als Bundesgerichte eine kommerzielle Website neben einen öffentlich zugänglichen Ort stellten.

Die Folge ist schlicht und hart. Verkauft eine Website Waren, nimmt Buchungen an oder gibt einfach Informationen an ein allgemeines Publikum weiter, schuldet sie Menschen mit Seh-, Hör-, motorischen und kognitiven Beeinträchtigungen Zugang. Diese Pflicht kam nicht mit einem neuen Gesetz, sondern mit einer Lesart des alten, und sie traf auf einen Schlag alle, die bereits online waren.

Was folgte, war ein Unterschied in den Kosten der Prüfung. Sich über den Laden an der Ecke zu beschweren, braucht einen Menschen: hinfahren, hineingehen, messen, festhalten. Sich über eine Website zu beschweren, braucht nur eine Maschine, die nie schläft. Kanzleien, die von Klagen in großer Zahl leben, sahen das vor allen anderen.

Das Ergebnis ist messbar: In den letzten Jahren sind Klagen nach Title III wegen nicht barrierefreier Websites um mehr als dreihundert Prozent gestiegen. Fast niemand blieb verschont — Einzelhandel, Gastgewerbe, Finanzen, Gesundheitswesen und kleine lokale Betriebe. Und der Warnschuss ist selten eine Kundenbeschwerde. Es ist ein förmliches vorgerichtliches Schreiben mit einer Zahlungsforderung, meist irgendwo zwischen zehn- und fünfzigtausend Dollar, mit einer Bundesklage als Alternative.

Wonach der Crawler tatsächlich sucht

Ein Bot beurteilt keine Bequemlichkeit. Er prüft vier Dinge, und jedes ist im Markup sichtbar. Erstens: ein Bild ohne Alternativbeschreibung — ohne Textattribut kann ein Bildschirmleser einem blinden Besucher nicht sagen, was das Bild zeigt. Zweitens: ein Eingabefeld ohne zugeordnete Beschriftung — ein Suchfeld, ein Kontaktformular, eine Newsletter-Anmeldung.

Das Dritte ist Arithmetik: Der Standard verlangt, dass sich gewöhnlicher Text von seinem Hintergrund mit einem Kontrastverhältnis von mindestens viereinhalb zu eins abhebt, und Stylesheets werden rechnerisch geprüft. Das Vierte ist die Tastatur: Jemand mit motorischer Beeinträchtigung bewegt sich mit Tab und Enter durch eine Seite, und lässt sich ein Menü so nicht öffnen oder eine Bestellung nicht bestätigen, gibt es keine Konformität. Alle vier stammen aus den internationalen Richtlinien WCAG, Version 2.1, Stufe AA.

Danach ist kein Anwalt mehr beteiligt. Software holt die Registrierungsdaten des Domaininhabers, setzt sie in eine vorbereitete Klagevorlage und druckt die Forderung. Eine Kanzlei bringt Hunderte davon pro Woche heraus, und die Grenzkosten jeder einzelnen gehen gegen null.

Nach Erhalt des Schreibens sucht ein Inhaber einen schnellen Ausweg und findet ihn als JavaScript-Plugin eines Drittanbieters, meist ein Kreis in der Ecke des Bildschirms. Das Versprechen ist perfekt: Eine Zeile Code einfügen, und künstliche Intelligenz bringt die Website in volle Konformität.

Technisch ist das Schminke, keine Reparatur. Das zugrunde liegende HTML und CSS bleibt, wie es war; das Overlay lebt im Browser des Besuchers und versucht, das Objektmodell der Seite im Betrieb neu aufzubauen. Eine Oberflächenschicht bewältigt das Einfache und scheitert am Komplexen: Dynamische Menüs, modale Fenster und der Warenkorb bleiben für Hilfssoftware undurchsichtig.

Schlimmer noch: Das Overlay stört genau die Menschen, für die es gekauft wurde. Blinde Nutzer navigieren nicht über ein an die Website geschraubtes Bedienfeld. Sie nutzen ihre eigene eingerichtete Software — JAWS, NVDA, VoiceOver. Widgets geraten damit in Konflikt und reißen die Tastatursteuerung an sich, weshalb so viele dieser Bedienfelder abgeschaltet oder gleich blockiert werden.

Warum der Flicken eine Klage anzieht

Das zentrale Paradox ist rechtlicher Natur. Ein Widget ist im Seitenquelltext auf einen Blick sichtbar, und die Scanner der Kläger sind genau auf solche Websites eingestellt. Für die klagende Seite ist das ein fertiges Argument: Der Inhaber kannte das Problem und wählte ein billiges Overlay statt einer Behebung. Viele amerikanische Gerichte haben Widgets bereits für unzureichend erklärt, und Unternehmen, die sie einsetzen, haben Hunderte von Fällen verloren.

Die Nebenkosten kommen als Zugabe. Ein schweres Skript eines Drittanbieters verlangsamt die Seite und schadet den Core Web Vitals, sodass die Wirkung auf die Suchergebnisse bestenfalls neutral und schlimmstenfalls negativ ist.

Die Alternative wird als Paket AIfa Shield des Studios AIfa Works beschrieben, und es ist umgekehrt gebaut: Der Quellcode selbst wird bearbeitet. Das erste Stockwerk ist bedeutungstragendes Markup. Gesichtslose Container weichen Tags, die ihren eigenen Zweck nennen — Kopfbereich, Navigation, Hauptbereich, Abschnitt, Fußbereich. Überschriften bilden eine strenge Leiter von der ersten bis zur sechsten Ebene. Knöpfe sind Knöpfe und Links sind Links, und der Tastaturfokus funktioniert von selbst, ohne eine Zeile Code dafür.

Das zweite Stockwerk ist ARIA für Elemente ohne Standardentsprechung. Der Zweck wird über Beschriftungen und Verknüpfungen mit einer Beschreibung laut ausgesprochen, der Zustand einer aufklappbaren Liste wird als auf- oder zugeklappt mitgeteilt, und rein dekorative Symbole werden vor dem Vorlesen verborgen, damit der Zuhörer nicht von Rauschen zermürbt wird.

Das dritte Stockwerk ist die Bedienung ohne Maus. Der Fokus wandert in sinnvoller Reihenfolge, ganz oben sitzt ein Link zum Hauptinhalt, damit man nicht auf jeder Seite die Menüs anhören muss, das aktive Element wird deutlich und kontrastreich hervorgehoben, und ein modales Fenster hat immer einen Ausgang über die Escape-Taste. Fallen, aus denen die Tastatur nicht herauskommt, darf es nicht geben.

Das vierte Stockwerk ist die Farbe. Der Kontrast wird für jedes Textelement neu berechnet und auf das gebracht, was der Standard verlangt: viereinhalb zu eins für gewöhnlichen Text, drei zu eins für große Überschriften. Das betrifft nicht nur Blindheit, sondern auch Sehschwäche und Farbenblindheit.

Barrierefreiheit ist leicht zu erreichen und ebenso leicht mit der nächsten Version wieder zu verlieren. Deshalb beschreibt der Artikel zwei ständige Mechanismen statt einer einzelnen Änderung. Serverseitiges Rendering in Next.js 14 liefert sofort fertiges semantisches Markup, an den Bildschirmleser wie an den Such-Crawler; niemand wartet, bis der Browser die Seite zusammensetzt.

Der zweite Mechanismus ist wichtiger. Eine automatische Prüfung ist in die Build-Pipeline eingebaut: Ein Barrierefreiheitsfehler hält den Build an, und der Code erreicht den Produktivserver nie. Das verschiebt die Barrierefreiheit aus der Spalte der Versprechen in die Bedingungen der Veröffentlichung. Und anders als ein Overlay, das Gewicht hinzufügt, nimmt das Bereinigen des Codes Gewicht weg, was sich in der Ladezeit und in der Lighthouse-Bewertung zeigt.

Die Ausgabe zahlt sich nicht nur durch das Schweigen der Kläger aus. Etwa fünfzehn Prozent der Weltbevölkerung leben mit irgendeiner gesundheitlichen Einschränkung — keine wohltätige Fußnote, sondern ein Marktsegment, das eine nicht barrierefreie Website mechanisch abschneidet.

Die zweite Wirkung ist technisch. Ein Such-Crawler liest eine Seite ganz ähnlich wie eine Vorlesesoftware: nach semantischem Markup, Alternativbeschreibungen und Überschriftenstruktur. Was für den einen lesbar ist, ist es auch für den anderen. Die dritte Wirkung betrifft den Ruf, und sie zählt ebenfalls: Sichtbare Sorge um Zugang wirkt auf das Vertrauen.

Hier ist es wichtig, den Vorbehalt nicht zu überspringen, den der Artikel selbst macht. Im Vergleich zwischen Overlay und nativer Behebung wird der rechtliche Schutz der Letzteren hoch genannt — mit einem ausdrücklichen Zusatz: Native Barrierefreiheit verringert das Klagerisiko, statt es ganz zu beseitigen. Das Studio wird so beschrieben, dass es Konformität auf Stufe AA anstrebt, und das genannte Ergebnis ist eine erhebliche Verringerung des rechtlichen Risikos.

Das ist die richtige Formulierung, und man sollte sie genau in dieser Gestalt behalten. Konformität ist ein Zustand des Codes, kein Ablassbrief: Jeder kann jederzeit klagen. Der Unterschied liegt darin, womit man antwortet. Eine Website mit Widget antwortet mit dem Widget, das vor Gericht bereits für unzureichend erklärt wurde. Eine Website mit berichtigtem Markup antwortet mit einer Build-Geschichte, in der jede Prüfung vor der Veröffentlichung bestanden wurde.

Die Ökonomie einer Klage hat sich geändert, bevor die Websites sich änderten. Die Prüfung wurde für den Prüfer kostenlos, während die Behebung für den Inhaber teuer blieb, und in dieser Lücke wuchs der ganze Markt schneller Overlays. Ein Overlay beruhigt die Sorge, ohne das Markup in Ordnung zu bringen, und markiert die Website obendrein als bequemes Ziel.

Die einzige Antwort, die unter Last hält, ist eine langweilige: semantische Tags, Beschriftungen für nicht standardmäßige Elemente, eine funktionierende Tastatur, ehrlicher Kontrast — und eine automatische Prüfung, die den Build brechen darf.