Accessibility Espresso #5
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.