Zum Hauptinhalt springen
Über Services Kontakt Newsletter Blog
en
Alle Ausgaben

Accessibility Espresso #5

Veröffentlicht am 13. Mai 2026 13. Mai 2026

Empfehlung des Podcast '13 Letters': Mike Shebanek erzählt, wie er bei Apple den späteren VoiceOver startete. Bogdan Cerovac: 'WebMCP ist kein Ersatz für Accessibility.' Russ Weakley erklärt den Weg vom Klick bis zur Screen-Reader-Ansage.

⭐ Thema der Woche

Podcast-Empfehlung mit der Entstehungsgeschichte von VoiceOver

13 Letters ist der Accessibility-Podcast von Be My Eyes - der Name spielt auf die 13 Buchstaben im englischen Wort 'accessibility' an. Die Show interviewt Praktiker aus der Branche zu Universal Design, ADA-Compliance, Inklusion und digitalen A11y-Best-Practices. Die zweiteilige Folge 'Who Invented VoiceOver?' von 2020 mit Mike Shebanek ist das Highlight. Teil 1 erzählt Mikes Weg bei Apple - Product Manager beim ersten iMac und beim allerersten iPad - und wie er das damals strauchelnde Unternehmen dazu brachte, VoiceOver als kostenlosen, eingebauten Screen Reader für eine als 'Nische' geltende Community blinder Studenten auszuliefern. Teil 2 behandelt Apple von 2004 bis 2013 und seine spätere Arbeit bei Yahoo/Verizon, wo er ein Accessibility-Departement-Modell aufbaute, das überall im Silicon Valley nachgebildet wurde.

📋 Das große Ganze

Accessibility-Theater hat jetzt ein System

Jared Cunha überträgt das D.E.N.N.I.S.-System aus 'It's Always Sunny in Philadelphia' auf Accessibility-Theater in Unternehmen: Demonstrate Value (laute Claims), Engage Physically (Vertriebsversprechen ohne Substanz), Nurturing Dependence (SaaS-Lock-In), Neglect Emotionally (jahrelang ungelöste Probleme), Inspire Hope (Pledges ohne Ergebnis), Separate Entirely (Nutzer steigen aus oder verlieren den Job). Seine Fallstudie: das National Design Studio mit dem Artikel 'Accessibility Matters' bei einem Portfolio voller Mängel. Kernargument: Es gibt keine Abkürzung für die Skills, die diese Arbeit verlangt.

Vorsicht vor KI-gestützten Accessibility-Audits

Karl Groves zerlegt die neue Welle 'KI-gestützter' Audit-Anbieter. Sein technisches Argument: LLMs greifen nicht auf das aktuelle DOM, Fokus-Zustand, berechnete Accessible Names oder dynamische ARIA-Änderungen zu. Was sie liefern, sind plausibel klingende Issue-Beschreibungen und Empfehlungen, die identisch mit dem fehlerhaften Code sind, den sie ersetzen sollen. ChatGPT gibt selbst zu: 'They are not doing a deep inspection of anything, much less the code.' Sechsstellige 'MCP-Server'-Angebote nennt Groves Counterfeit-Expertise. Seine Warnung: 'Wenn die Beweise synthetisch sind, ist das Audit nicht mehr in der Realität verankert.'

WebMCP - Accessibility nicht zurücklassen

Bogdan Cerovac untersucht WebMCP - den Chrome-Labs-Vorschlag, mit dem Websites KI-Agenten über das Model Context Protocol vordefinierte Tools anbieten können. Seine zentrale Sorge: WebMCP könnte zum Vorwand werden, Webseiten unzugänglich zu lassen, wenn Firmen barrierefreie KI-Interfaces anbieten und die Seite dahinter vernachlässigen - ein zweistufiges Web, in dem nur KI-Nutzer dazugehören. Er beschreibt konkrete Szenarien und legt vier Empfehlungen vor. Kernsatz: 'WebMCP ist kein Ersatz für Accessibility.'

⚙️ Praxis

Mobile Apps testen - was anders ist als im Web

Detlev Fischer startet eine Mobile-Accessibility-Serie mit der Frage, an der Tester scheitern: Warum lassen sich Web-Techniken nicht sauber auf native Apps übertragen? Drei strukturelle Unterschiede prägen den Rest. Erstens die Source-Code-Inspektion: App-Quellcode ist oft gar nicht zugänglich. Zweitens die Rolle des User Agents: Im Web kümmert sich der Browser um Textgröße und Reflow, bei nativen Apps macht das das Betriebssystem. Drittens die Standards: bei Konflikten hat EN 301 549 Klausel 11 (Non-web Software) Vorrang vor Klausel 9.

Die Realität hinter dem KI-Hype

Mario Gregor hat einen Accessibility-Scanner getestet: Claude Code im Backend, Lovable im Frontend, WCAG Scan mit axe-core. Der Start war vielversprechend: drei KI-Agenten produzierten in Stunden funktionale User Stories und ein Backend. Zeitaufwand: vier Stunden Architektur, mehr als drei Wochen Debugging. Fazit: 'Der Zwei-KI-Ansatz ist in der aktuellen Form nicht tragfähig für ernsthafte Produktentwicklung.'

End-to-End Event-Architektur in Browsern

Russ Weakley zeichnet den vollen Pfad nach, den ein User-Event vom Eingabegerät bis zur Assistive-Technology-Ausgabe nimmt. Der Artikel enthält eine strukturierte Schicht für Schicht Aufstellung mit Hinweisen auf Unterschiede in den Browser-Implementierungen.Eine Referenz, um zu verstehen, warum ein Fokus-Wechsel manchmal seltsam angekündigt wird oder eine Live-Region in einem Browser feuert und im anderen nicht.

Jetzt abonnieren

Und alle zwei Wochen Impulse zu digitaler Barrierefreiheit erhalten.
DSGVO-Erklärung

Für den Versand unserer Newsletter nutzen wir rapidmail. Mit Ihrer Anmeldung stimmen Sie zu, dass die eingegebenen Daten an rapidmail übermittelt werden. Beachten Sie bitte auch die AGB und Datenschutzbestimmungen.

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.
  • © 2026 Jan Deppisch
  • Impressum & Datenschutz