Barrierefreiheit ab Werk: Was das für PanelWave bedeutet

In den meisten Lese-Apps ist Barrierefreiheit eine Einstellungsseite. In PanelWave ist sie eine Eigenschaft des Formats. Das klingt abstrakt, bis man sieht, was es bringt: Alternativtexte sind übersetzt, weil jeder Text übersetzt wird. Reduzierte Bewegung funktioniert, weil Übergänge Daten sind. Und eine Graphic Novel lässt sich mit der Tastatur von vorn bis hinten lesen, weil die Geschichte ein Graph ist, durch den man mit der Tastatur navigieren kann. Dieser Beitrag zeigt, wie sich Barrierefreiheit durch alle drei Schichten zieht – vom Manifest über den Player bis zum CMS –, was sie den Lesenden bringt, was sie von Creators verlangt und wo noch Lücken sind.

Es beginnt im Format

Im Manifest sind Angaben zur Barrierefreiheit vollwertige Felder, kein optionaler Anhang. Jedes Asset im Katalog kann einen Alternativtext, eine Bildunterschrift und ein Transkript für Audio und Video haben. Alle drei sind LocalizedStrings, die Screenreader-Ausgabe folgt also genauso der Sprache der Lesenden wie der Dialog (Assets, Localization). Ein Panel hat eine Beschreibung, die anstelle des Artworks vorgelesen wird, und einen Barrierefreiheitsblock mit einer alternativen Beschreibung des ganzen Panels (AccessibilityHints). Ein Hotspot trägt sein eigenes ARIA-Label, sodass ein interaktiver Bereich ansagt, was er tut, statt wo er ist (Hotspots).

Inhaltswarnungen werden einmal in den Metadaten des Werks angelegt, mit lokalisiertem Label und einem defaultBlur-Flag. Jedes betroffene Panel verweist dann per ID darauf (ContentWarning). Weil die Angabe im Format steht, kann jede Leseanwendung sie berücksichtigen, nicht nur unsere. Das Muster zieht sich durch: Leg die Information dorthin, wo jedes Werkzeug sie sieht – dann hängt Barrierefreiheit nicht mehr davon ab, mit welcher App jemand die Datei öffnet.

Was die Lesenden im Player bekommen

Der Open-Source-Player setzt diese Felder in Verhalten um. Jeder Button in der Werkzeugleiste trägt ein übersetztes aria-label, und Schalter geben aria-pressed aus. Der Viewport ist eine beschriftete Region, die man per Tastatur mit Enter oder Leertaste aktiviert. In der Seitenansicht ist jedes platzierte Panel ein fokussierbarer Button mit sichtbarer Fokusanzeige. Mit den Pfeiltasten geht es durch die Geschichte, T blendet die Werkzeugleiste ein und aus, Escape schließt Modals, und solange jemand in ein Feld tippt, bleiben Tastenkürzel stumm (Accessibility, Input methods).

Hotspots – die interaktiven Bereiche, die Creators zeichnen – stehen in der Tab-Reihenfolge: Tab springt von einem zum nächsten, Enter oder Leertaste aktiviert sie, und jeder sagt sein lokalisiertes Label an. Sehende Lesende erkennen sie an einem sanft pulsierenden Umriss. Bei reduzierter Bewegung entfällt das Pulsieren, und der Umriss erscheint stattdessen bei Hover und Fokus (Interactive hotspots).

Reduzierte Bewegung kann aus zwei Quellen kommen: aus der Betriebssystemeinstellung prefers-reduced-motion und aus dem Input reducedMotion des Hosts. Und sie ändert mehr als nur das Animationstempo. Übergänge zwischen Panels fallen weg, Videos, die sonst beim Erscheinen starten würden, laufen erst per Klick, und in der Canvas-Ansicht gleitet die Kamera nie. Neue Bildausschnitte erscheinen sofort mit einer kurzen Überblendung – es sei denn, der Creator hat einen eigenen Fallback-Übergang festgelegt, dann hat der Vorrang. Panels, die gerade nicht aktiv sind, tragen aria-hidden und inert, damit eine virtualisierte Leinwand nie den Fokus einfängt. Screenreader folgen der linearen Reihenfolge des Graphen, die Leinwand bleibt reine Darstellung (Canvas View, Configuration).

Die Lesenden haben auch selbst etwas in der Hand. Das Einstellungsfenster bietet den Manga-Modus zum Lesen von rechts nach links, reduzierte Bewegung und hohen Kontrast, dazu Optionen für Sprechblasen, Audio und Autoplay-Timing; alles lässt sich auf die Standardwerte zurücksetzen (Settings modal). Auch der Sprachwechsel ist eine Barrierefreiheitsfunktion, und er geht sofort: Text, Sprechblasen, lokalisierte Assets und Audio werden ohne Neuladen neu aufgelöst (Player localization).

Wie wir dafür sorgen, dass es so bleibt

Versprechen wie diese veralten, wenn niemand sie überprüft. Die Playwright-End-to-End-Suite des Players lässt axe-core auf die Panelansicht mit geöffneter Werkzeugleiste, die Seitenansicht und das Sprachfenster los und schlägt bei schwerwiegenden Verstößen fehl; die Berichte hängen an jedem Lauf. Tastaturnavigation und reduzierte Bewegung haben eigene Specs. Die Suite läuft in der Continuous Integration für Desktop- und Mobilbrowser (Development: testing). Tests mit echtem Screenreader ersetzt sie nicht – die machen wir vor Releases zusätzlich von Hand. Aber sie verhindert, dass Rückschritte unbemerkt ausgeliefert werden.

Was Creators tun müssen

Das Format kann nur transportieren, was jemand hineinschreibt. Deshalb macht das CMS das Schreiben zum Teil des normalen Ablaufs statt zu einem separaten Audit.

Für nichts davon musst du wissen, wofür ARIA steht. Die Felder sitzen direkt beim Inhalt, die Prüfung läuft vor dem Veröffentlichen, und zur Korrektur ist es nur ein Klick.

• Beschreib deine Panels. Titel und Beschreibung bearbeitest du im Panel-Inspektor pro Sprache. Screenreader lesen die Beschreibung vor – schon ein Satz darüber, was im Panel passiert, macht das Werk für blinde und sehbehinderte Lesende zugänglich (Panel properties).
• Gib Artwork einen Alternativtext. Setz ihn einmal am Asset über Edit Metadata oder an der Ebene im A11y-Tab des Inspektors. Im selben Tab findest du auch Untertitel für Audio und Video sowie die Barrierefreiheit interaktiver Elemente (Alt text and accessibility, Right inspector).
• Beschrifte deine Hotspots. Jeder Hotspot hat in den Basic Properties ein Feld Label pro Sprache und ein Feld ARIA Label (Naming and accessibility).
• Markiere sensible Inhalte. Inhaltswarnungen werden pro Panel im Strukturbaum oder im Bereich Content Settings gesetzt, und der Baum zeigt an jedem markierten Panel ein W-Badge (Pages and Panels).
• Führ Preflight aus. Die Kategorie Accessibility markiert Bildebenen ohne Alternativtext und Audio ohne Untertitel. Ein fehlender Alternativtext gibt eine Warnung, ein fehlender Untertitel einen Fehler, der das Veröffentlichen blockiert. Jeder Fund verlinkt auf das Panel, in dem das Asset steckt, und auf die Codereferenz (Validation, Missing alt text, Missing caption).

Auch das Autorenwerkzeug muss barrierefrei sein

Wer schlecht sieht oder motorisch eingeschränkt ist, sollte einen barrierefreien Comic nicht nur lesen, sondern auch machen können. Der Editor hat app-weit sichtbare Fokusrahmen (focus-visible), Fokusfallen in jedem Dialog, ARIA-Semantik im Strukturbaum mit voller Pfeiltastennavigation und eine Übersicht der Tastenkürzel hinter der Fragezeichentaste (Shortcuts). Über die Befehlspalette (Strg+K) erreichst du die meisten Editor-Aktionen ohne Maus, und ein Ebenen-Navigator für die Tastatur sagt Screenreadern die Ebenen an, während du durch sie blätterst. Zur Wahl stehen die Designs System, Hell, Dunkel und eine kontrastreiche Palette, die für die App und für die Bedienelemente auf der Editor-Leinwand gilt (Account: theme). Das kontrastreiche Design ist diesen Monat zusammen mit einer Reihe gemeinsamer UI-Grundbausteine erschienen. An ihm werden wir mit dem ersten Feedback voraussichtlich am meisten feilen.

Altersprüfung und Paywall – mit Respekt

Bei Komfort geht es nicht nur um Bewegung und Kontrast. Braucht ein Werk eine Altersprüfung, bringt der Player eine passende Komponente mit, mit einstellbarem Mindestalter und Hinweistext. Die Entscheidung trifft der Entitlement-Adapter des Hosts: Er kann das Alter prüfen oder auf eine schreibgeschützte Nutzervariable zurückgreifen, die beim Start gesetzt wird. Gibt es beides nicht, verweigert die Prüfung den Zugang, statt zu raten (Paywall and Entitlement). Für Paywall-Overlays gilt dieselbe Regel: Die Lesenden erfahren klar und in ihrer Sprache, was gesperrt ist und warum, und die Geschichte überspringt nie stillschweigend Inhalte.

Was noch offen ist

Wir zählen das auf, weil ein Versprechen zur Barrierefreiheit, das seine Lücken versteckt, weniger wert ist als eines, das sie offen benennt.

• Preflight liefert noch nicht jede Prüfung, die es auflistet. Vollständigkeit der Lokalisierung und Audio-Abdeckung pro Sprechblase erscheinen schon als Kategorien, ihre Problemcodes sind aber erst geplant. Die Prüfungen für Alternativtexte und Untertitel laufen bereits (Validation codes).
• Drei Einstellungs-Checkboxen werden gespeichert, aber noch nicht angewendet. Die Audio- und SFX-Schalter in der Werkzeugleiste funktionieren inzwischen: Audio schaltet den ganzen Player stumm, Videoton eingeschlossen, SFX den Effekt-Bus, und Speech bringt auch die Sprecherstimme zum Schweigen. Alle drei merken sich deine Wahl (Toolbar controls). Die Checkboxen für Manga-Modus, reduzierte Bewegung und hohen Kontrast im Einstellungsfenster werden zwar gespeichert, aber die Shell reagiert noch nicht darauf. Reduzierte Bewegung kommt stattdessen aus der Betriebssystemeinstellung und dem Input des Hosts.
• Wie Inhaltswarnungen aussehen, entscheidet die jeweilige Implementierung. Das Format legt die Warnung fest und ob ein Panel standardmäßig unscharf sein soll. Wie ein Player die Zustimmung abfragt, ist seine Sache – unsere Lösung feilen wir noch an echten Werken.

Warum vom ersten Tag an

Wer Barrierefreiheit nachrüstet, muss alle Schichten gleichzeitig anfassen: Das Format braucht neue Felder, der Player muss sie lesen, das Autorenwerkzeug muss sie erfassen – und bestehende Werke bleiben unzugänglich, bis jemand sie nacharbeitet. Weil wir sie von Anfang an eingebaut haben, ergibt sich das meiste davon aus Entscheidungen, die ohnehin gefallen waren. Alternativtexte sind lokalisiert, weil alles ein LocalizedString ist. Reduzierte Bewegung ist verlässlich, weil ein Übergang ein Datenfeld ist, das eine Engine überspringen kann. Die Tastaturnavigation ist vollständig, weil die Geschichte ein Graph mit klar definiertem Vor und Zurück ist. Story-Graph, Lokalisierungsmodell und Barrierefreiheitsfelder sind zusammen entstanden. In diesem Sinn ist Barrierefreiheit bei uns ein Standard und keine Zusatzfunktion.

Weiterlesen

• Reader Interface: alle Bedienelemente, Eingabemethoden und Barrierefreiheitsfunktionen im Player.
• Panels und Assets: die Barrierefreiheitsfelder im Format.
• Validation and Preflight: die Prüfungen, die vor dem Veröffentlichen laufen.
• Warum graphbasierte Navigation?: das Modell, das die Tastaturnavigation vollständig macht.