Laura Kalbags 'Accessibility for Everyone' (A Book Apart, 2017) war kostenpflichtig, jetzt kostenlos. Anna E. Cook erklärt, warum KI von barrierefreien Systemen abhängt, statt sie zu reparieren. Eric Eggert: Screen Reader sind keine Testwerkzeuge.
Sam, Laura Kalbags Bruder mit Zerebralparese, verbringt neun Stunden täglich im Netz, braucht aber zwei- bis dreimal so lange für jede Aufgabe. Seine Geschichte eröffnet 'Accessibility for Everyone', 2017 bei A Book Apart erschienen und jetzt als komplette Web-Edition kostenlos. Kalbag behandelt fünf Behinderungskategorien mit konkreten Zahlen - 12,1 % der US-Bevölkerung, bis zu 8 % Farbenblindheit bei Männern, 35 % der Über-40-Jährigen mit vestibulären Störungen - und führt von Copywriting bis HTML-Semantik und Testing mit JAWS, VoiceOver und NVDA. Ihr Kernargument: Accessibility ist kein Budgetposten, sondern eine grundlegende Praxis.
Anna E. Cook argumentiert, die Branche drehe die Logik um. KI kann eine kaputte Struktur nicht reparieren - sie erbt sie und reproduziert sie skaliert. Sie verweist auf den WebAIM-2026-Million-Report mit 95,9 % fehlerhaften Startseiten und 10,1 % mehr Fehlern pro Seite in einem Jahr, dem ersten Rückschritt nach sechs Jahren. Microsofts eigene LLM-Auswertung erreichte 0-31 % WCAG-Konformität, GPT-5 Mini am höchsten mit 31 %. Sie zerlegt vier Mythen, darunter Jakob Nielsens diagnosebasierte generative UI. Ihr Fazit: Nicht jedes Produkt braucht KI, aber jedes barrierefreie, gut gestaltete Systeme.
Stéphanie Walter widmet sich dem schwierigen Teil von Accessibility - andere zu überzeugen. Sie sammelt neun verbreitete Einwände und liefert zu jedem Daten und eine Umdeutung. Gegen 'niemand hat sich beschwert': eine Nucleus-Studie von 2019 fand 23 % abgebrochene E-Commerce-Transaktionen bei blinden Nutzer:innen, 6,9 Milliarden Dollar jährlich verloren. Gegen 'zu teuer': Forrester (2022) mit 100 Dollar Rückfluss pro investiertem Dollar. Gegen 'machen wir später': IBMs Kurve von 1x im Design bis 100x in der Wartung, Deque mit 67 % der Probleme aus dem Design. Ihr Satz: Konformität ist der Boden, nicht die Decke.
Der Access-Ability-Newsletter macht ein Beschaffungsargument, das Entscheider:innen selten hören. Die Agentur, die deine nicht barrierefreie Website gebaut hat, sollte nicht die sein, die du fürs Nachbessern bezahlst. Der Text vergleicht das mit jemandem, der dir an der Tankstelle Zucker in den Tank kippt und dir dann einen neuen Motor verkaufen will, und warnt: Ein Auditor, der den Remediation-Auftrag gewinnen kann, hat ein Interesse daran, wie schwer die Befunde wirken. Fehlende Alt-Texte und Kontrast sind keine Ausnahmen. Empfehlung: erst ein unabhängiges Audit, dann ein separater, ausgeschriebener Auftrag.
Eric Eggert argumentiert, Screen Reader sollten nicht das primäre WCAG-Testwerkzeug eines Auditors sein. Sie zeigen die Symptome von schlechtem Code, nicht die eigentlichen Probleme, und brauchen Expertenbedienung. Seine Beispiele sind konkret: Ein div mit tabindex=0 lässt sich mit VO+Space aktivieren, also 'funktioniert' es, obwohl die Affordanz kaputt ist; schlechte Fokus-Indikatoren bleiben unsichtbar, weil Screen Reader ihren eigenen Fokusrahmen zeichnen. Er empfiehlt schnellere, ursachenorientierte Tools - a11y-tools.com-Bookmarklets, Polypane Peek - und Screen-Reader-Checks erst für Live-Regionen und Usability nach den Fixes.
Working Draft Episode 651 widmet sich komplett ARIA. Die Hosts besprechen die fünf ARIA-Regeln und betonen, dass die erste - kein ARIA verwenden, wenn ein natives HTML-Element den Job erledigt - viel häufiger verletzt wird, als Entwickler:innen ahnen. Die Diskussion behandelt praktische Patterns für Live-Regionen, aria-label versus aria-labelledby und Landmark-Rollen. Sie untersuchen, wie ARIA-States mit dem Accessibility Tree des Browsers interagieren und warum falsches ARIA schlimmer ist als gar keines. Eine rund 60-minütige deutschsprachige Episode, kostenlos und ohne Anmeldung - ein solider Einstieg jenseits der ersten Regel.
Manuel Matuzovic prüft eine Best Practice erneut, die viele im Autopilot anwenden - ein tabindex=-1 auf das Ziel eines Sprunglinks. Browser implementieren seit Langem den Sequential Focus Navigation Starting Point (Firefox 2013, Chrome 2016), sodass Tab nach dem Sprunglink auch ohne den Workaround vom Ziel weiterläuft. Er belegt das über Firefox, Chrome, Safari und Edge unter macOS und Windows, dazu VoiceOver, JAWS 2026, NVDA, Narrator, TalkBack und Screen Magnifier bei 700 %. Der Haken: Dan Burzo fand, dass tabindex=-1 auf main den iOS-Zurück-Button kaputt machen kann. Prüfe alte Gewohnheiten neu.
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.
