"image001.jpg" besteht den Scan wie eine echte Beschreibung - Prozent-Scores führen in die Irre. Für KI-Agenten schlägt der Accessibility Tree Screenshots klar: Struktur statt Pixel, eine Größenordnung günstiger. Dazu zehn Lücken, die axe übersieht.
Automatisierung und Barrierefreiheit sind nicht dasselbe - diesen Denkfehler hält Dennis Deacon für einen der folgenreichsten, die Führungskräfte machen können. Ein Scan lässt ein Bild mit dem Alt-Text "image001.jpg" genauso durch wie eines, das ein Balkendiagramm mit 40 Prozent mehr Kundenzufriedenheit beschreibt. Das Attribut ist vorhanden, also gilt der Test als bestanden. Deacon rät deshalb, nicht länger nach dem Prozentwert aus dem Scan zu fragen. Die bessere Frage lautet, ob Screen-Reader-Nutzer den Checkout allein abschließen können. Die Abdeckung der Scans sagt viel über eure Tools und wenig über eure Nutzer.
Navya Agarwal hält KI-Agenten für falsch gebaut. Wer Screenshots auswertet, lässt ein Vision-Modell aus Pixeln zurückrechnen, was der Browser längst kennt - der Accessibility Tree liefert Rolle, Name und Zustand bereits strukturiert. Ihr Argument zielt nicht auf Tempo, sondern auf Passung. Die semantische Ebene ist schlicht die bessere Schnittstelle, niedrigere Latenz ist nur die Folge davon. In ihren eigenen Projekten sank die Latenz pro Aktion von 2-5 Sekunden auf unter 500 ms, die Token-Kosten um eine Größenordnung. Agent-Tauglichkeit nennt sie eine echte Obermenge von Accessibility. Menschen kommen mit unklarer UI zurecht, Agenten nicht.
Abhay Kapur von BarrierBreak legt Zahlen auf ein Argument, das viele von uns im Bauch haben. Derselbe Accessibility-Defekt kostet im Design 1x, in der Implementierung 6,5x, im QA 15x und in Produktion das 60- bis 100-Fache. Live sind das 800 Dollar aufwärts pro Fix. Dazu kommen 20 bis 30 Prozent mehr Support-Tickets, sobald Leute ihr Anliegen nicht mehr selbst erledigen können. Kapur hängt das an die DOJ-Regel vom April 2024, die US-Behörden auf WCAG 2.1 Level AA verpflichtet. Der Text kommt von einem Hersteller und endet als Werbung für die eigene Plattform. Die Kostenkurve taugt trotzdem fürs nächste Budgetgespräch.
KI sollte barrierefreien Code endlich einfach machen. Warum wird das Web dann unzugänglicher? Ela Gorla, Principal Accessibility Specialist bei TetraLogical, findet die Ursache in den Trainingsdaten. LLMs lernen aus öffentlich zugänglichen Websites, und viele davon sind nicht barrierefrei - also bauen die Modelle genau diese Barrieren nach. Sie nimmt vier Muster auseinander: Vibe Coding, KI-gestütztes Coding, KI-Agenten und schnelle Produktentwicklung, bei der Discovery und Wireframing wegfallen. Neu ist daran nichts, KI beschleunigt nur alte Abkürzungen. Ihre Antwort heißt Governance statt Tools, wie bei der BBC.
Rund die Hälfte aller Websites setzt tabindex laut Web Almanac gar nicht ein. Patrick Brosset zählt im Microsoft Edge Blog auf, woran Tastaturnavigation scheitert - falsche tabindex-Werte, ein vergessener focus()-Aufruf, Pfeiltasten ohne preventDefault, Fokus auf deaktivierten Feldern. Microsofts Antwort heißt focusgroup. Ein einziges HTML-Attribut übernimmt den Roving-tabindex-Code, steuert die Pfeiltasten in allen Textrichtungen, überspringt versteckte Elemente und folgt dem ARIA Authoring Practices Guide. Auch im Shadow DOM greift es. 2021 entworfen, ab 2022 in der OpenUI Community Group gereift, jetzt in Edge testbar - stabil ist es noch nicht.
Wie viel Barrierefreiheit lässt sich automatisiert testen? David Mello stellt fünf Quellen nebeneinander, die sich nicht einig sind. WebAIM nennt rund 30% der echten WCAG-Fehler, das W3C/WAI 20-30% der Erfolgskriterien, die US-Behörde GSA jedes dritte Problem. Accessible.org teilt WCAG 2.2 AA auf in 13% voll automatisierbar, 45% teilweise und 42% gar nicht. Deque misst für axe-core 57,38% und liegt damit am optimistischsten. Danach zeigt Mello zehn Lücken, die axe und Lighthouse grundsätzlich nicht bewerten können - und zu jeder ein Playwright-Pattern zum Nachbauen. Gegen Tools argumentiert er nicht.
Ein fancy-button Element wirkt in den DevTools leer, bis du den Shadow Root aufklappst und den echten Button darin siehst. Genau diesen Root bekommt ein Screen Reader nie zu sehen, zeigt Max Design. Beim Aufbau des Accessibility Trees erledigt der Browser das Flattening und fasst Light DOM und Shadow DOM zu einem einzigen Baum zusammen. Der innere Button landet dort mit dem Namen "Buy now", das fancy-button Element selbst bekommt nur eine generische Rolle - es bringt keine eigene Semantik mit. Chrome, Firefox und Safari erledigen das an verschiedenen Stellen ihrer Engines. Und die Performance? Laut Artikel liegt Trägheit fast nie am Shadow DOM.
Vielen Dank für Ihre Anmeldung!
Ich habe Ihnen auch schon die erste E-Mail geschickt und bitte Sie, Ihre E-Mail-Adresse über den Aktivierungslink zu bestätigen.
