Eine Progressive Web App ist zur Laufzeit drei Dinge, die auf einer normalen Website aufgeschichtet sind: ein Web App Manifest, ein Service Worker und eine installierte Chrome-Oberfläche, die den Browser-Rahmen durch den eigenen Task-Switcher-Eintrag des Betriebssystems ersetzt. Jede der drei Schichten bringt ihre eigenen Barrierefreiheitspflichten mit sich — und jede versagt ihren Nutzern assistiver Technologien auf eine andere, separat debuggbare Weise.

Im Jahr 2020 kollabierte die gesamte Diskussion in „WCAG gilt für PWAs“, was technisch korrekt und operativ nutzlos war. Im Jahr 2026 ist die Diskussion in die vier Oberflächen aufgeteilt, auf die es wirklich ankommt: die Install-Prompt-UX, die Manifest-Eigenschaften, die Bedienelemente auf OS-Ebene steuern, die Übergabe zwischen dem Barrierefreiheitsbaum des Browsers und dem Barrierefreiheitsbaum des Betriebssystems, sobald die PWA im Standalone-Modus gestartet wird, und das AT-Verhalten des Offline-Fallbacks des Service Workers. WCAG 2.2 regelt das Dokument; die Plattformintegrationsschicht wird von einem weit lückenhafteren Mix aus W3C-Entwürfen, anbieterspezifischem Verhalten und vom Web geerbten ARIA-Konventionen geregelt.

Der Install-Prompt ist die am stärksten für Nutzende sichtbare PWA-Oberfläche und im Jahr 2026 immer noch die am schlechtesten entwickelte. In Chromium wird der Prompt durch beforeinstallprompt gesteuert, das erst nach einer heuristischen Engagement-Schwelle ausgelöst wird und das Websites typischerweise in eine benutzerdefinierte „App installieren“-Schaltfläche einbinden. Diese benutzerdefinierte Schaltfläche ist der Ort, an dem Barrierefreiheit schiefgeht: ungefähr jede dritte Lighthouse-bewertete PWA rendert die Installationsausprägung als <div> oder ein gestaltetes <span> ohne Rolle, ohne zugänglichen Namen und ohne Tastaturverarbeitung — für einen Screenreader unsichtbar, per Tab nicht erreichbar und von dekorativem Chrome nicht zu unterscheiden.

Die Lösung ist unspektakulär und verpflichtend: Die Installationsausprägung als echtes <button>-Element rendern, einen zugänglichen Namen vergeben, der das Verb enthält (z. B. „Disability World auf diesem Gerät installieren“), dieselbe Schaltfläche allen Eingabemodalitäten zugänglich machen und Erfolg oder Misserfolg über eine Live-Region ankündigen, nachdem der Nutzer die OS-Bestätigungsaufforderung geschlossen hat. Dasselbe gilt für die Zustände related-applications und beforeinstallprompt dismissed — beide müssen eine für AT wahrnehmbare Statusänderung erzeugen.

Das Web App Manifest ist zwischen 2022 und 2026 still gewachsen, und viele seiner neueren Eigenschaften haben direkte Konsequenzen für die Barrierefreiheit. Die nachfolgende Matrix ordnet die elf Manifest-Eigenschaften, die mit assistiver Technologie interagieren, dem zu, was jeder Browser heute tatsächlich damit macht — über Chrome auf Android, Safari auf iOS, Edge auf Windows und Firefox auf dem Desktop. Eigenschaften wie file_handlers, share_target und window_controls_overlay existierten 2021 in keiner nennenswerten Form; 2026 bestimmen sie, ob die PWA im Teilen-Menü des Betriebssystems erscheint, Dateien aus dem System-Dateimanager öffnet und ihre eigene Titelleiste rendert — all das muss der Screenreader-Nutzer wahrnehmen und bedienen können.

Das schwierigste einzelne Debugging-Problem bei der PWA-Barrierefreiheit im Jahr 2026 ist das, was passiert, wenn der Nutzer die Naht zwischen dem Standalone-Modus-PWA-Chrome und dem Betriebssystem selbst überquert. Auf Android liest TalkBack den Manifest-name, wenn der Nutzer das Startbildschirm-Icon fokussiert, und wechselt dann zum Lesen des In-App-Barrierefreiheitsbaums, sobald die PWA startet; auf iOS 16.4+ tut VoiceOver dasselbe für eine installierte PWA, aber mit einer wichtigen Besonderheit — das erste fokussierbare Element nach dem Start wird ohne den App-Kontext angekündigt, den eine native iOS-App über ihren UIWindow-Titel liefern würde.

Der PWA-Autor hat ein Werkzeug, um diese Lücke zu schließen: Beim Kaltstart den Fokus auf eine Überschrift oder ein main-region-Landmark setzen, das den App-Namen in seinem zugänglichen Label enthält, und den Dokument-<title> auf eine Zeichenkette setzen, die der OS-Task-Switcher liest, wenn der Nutzer zwischen Apps wechselt. Ohne dies verliert der Screenreader-Nutzer den kontextuellen Hinweis, dass er die Anwendung gewechselt hat — ein „Wo bin ich?“-Fehler, der bei nativen Apps nicht existiert.

Wenn der Service Worker eine Offline-Fallback-Seite ausliefert, treten zwei AT-spezifische Fehlermodi auf: Der Fokus, der sich innerhalb der nun entladenen Seite befand, wird still auf den Dokumentkörper fallen gelassen, und die Offline-Seite selbst verwendet selten eine Live-Region, um dem Screenreader-Nutzer mitzuteilen, was gerade passiert ist. Das Ergebnis ist ein Nutzer, der eine Ankündigung des Offline-Seiten-Titels hört (wenn er Glück hat) und ansonsten einen vollständigen Kontextverlust erlebt.

Die Lösung besteht darin, den Offline-Übergang als Zustandsänderung zu behandeln, ihn über eine höfliche aria-live-Region anzukündigen, den Fokus auf ein bekanntes Landmark der Offline-Seite zu setzen und eine „Wiederholen“-Steuerung als echtes Schaltflächen-Element bereitzustellen statt als den „Neu laden“-Link, den die meisten Service-Worker-Vorlagen liefern. Dasselbe gilt für den Hintergrund-Sync-Wiederherstellungspfad: Wenn die Verbindung zurückkehrt und der Service Worker die Warteschlange abarbeitet, ist das ebenfalls eine Zustandsänderung, über die der AT-Nutzer informiert werden muss.

Die Frage „Sollen wir eine PWA oder eine native App ausliefern?“ hat nun neben einer Funktionsvollständigkeitsdimension auch eine Barrierefreiheitsdimension. Nachfolgend wird dieselbe hypothetische Nachrichten-Lese-App in vier Varianten verglichen — als PWA auf Android, als PWA auf iOS 16.4+, als native iOS-App und als native Android-App — über die fünf Oberflächen, die ein Screenreader-Nutzer zuerst berührt.

Die Installationsausprägung als echtes <button>-Element mit einem zugänglichen Namen ausliefern. Eine höfliche Live-Region an das userChoice-Ergebnis koppeln. name, short_name, description, lang und dir im Manifest ausfüllen und maskierbare Icons für Android bereitstellen. Wenn window_controls_overlay aktiviert wird, eine eigene Titelleiste rendern und beschriften; wenn file_handlers oder share_target aktiviert werden, den resultierenden Start als Zustandsänderung behandeln und ihn beim Einstieg ankündigen.

Den Fokus auf ein beschriftetes Landmark setzen, jedes Mal wenn der Screenreader-Nutzer die Naht überquert — Erststart, App-Switcher-Rückkehr, Offline-Übergang, Share-Target-Start, Wiederverbindung. Jede Überquerung als ein diskretes Ereignis behandeln, das dem Nutzer eine wahrnehmbare Ankündigung und einen bekannten Fokusanker schuldet. Nichts davon ist schwierig; fast nichts davon wird konsistent ausgeliefert.

Eine PWA im Jahr 2026 kann für einen AT-Nutzer einer nativen App sehr ähneln — auf Android. Auf iOS ist sie näher als früher, und es gibt immer noch eine echte Lücke. Die Lücke schließt sich ungefähr um eine Manifest-Eigenschaft pro Jahr. Für Beschaffungsteams, die zwischen einer PWA und einer nativen App wählen, lautet die Barrierefreiheitsfrage nicht mehr „Kann eine PWA barrierefrei sein?“ — das kann sie. Die Frage ist, ob das Team, das sie baut, die elf Manifest-Zeilen oben gelesen und akzeptiert hat, dass jede einzelne zu seinem Lieferumfang gehört.