Wenn der grüne Haken täuscht

Webinare, Checklisten, KI und Automated-Testing-Tools versprechen heute eine schnelle Lösung: Code durchsuchen, Fehler beheben, grüner Haken, Thema erledigt.

Oder?

In der Praxis entsteht eine gefährliche Illusion. Ein Dokument kann laut Validierungs-Tool fehlerfrei sein, der Code sieht sauber aus und die Schrift ist ausreichend groß. Für Menschen, die auf assistive Technologien angewiesen sind, kann ungetesteter Code ein digitales Buch trotzdem in eine unbenutzbare Ansammlung von Zeichen verwandeln.

Barrierefreiheit entsteht nicht durch das Abarbeiten von Anleitungen. Man arbeitet hier Hand in Hand durch Verständnis von Ursache und Wirkung. Wer E-Books aufbereitet, muss verstehen, was im System passiert, wenn visuelle Gestaltung in Code übersetzt wird. Welche Information soll vermittelt werden? Welche Struktur liegt dahinter? Und wo entstehen technische Wechselwirkungen?

Diese Artikel-Reihe zeigt anhand alltäglicher Praxisbeispiele aus unterschiedlichen Perspektiven, wie kleine Formatierungsfehler im EPUB echte Barrieren im Lesealltag erzeugen.

Ursache, Wirkung und Konsequenz im Code

Das Weglassen oder Hinzufügen von Attributen verbunden mit HTML-Semantik sind die Kabel, die in einer digitalen Leseumgebung für unterschiedliche Arten der Ausgabe sorgen. Praxistests geben hier über Erkenntnisse aufschluss, wo Kernfunktionen ausgesetzt oder vervollständigt werden können.

Die unsichtbaren Bilder (Alt-Texte & Bild-Semantik)

Die Ursache

Ein Bild wird ohne alt-Attribut eingebaut oder rein visuell als Schmuckelement eingestuft – obwohl es inhaltlich relevante Informationen (z. B. eine botanische Skizze) enthält.

Die Wirkung

Assistenzsysteme stufen das Element als irrelevant ein. VoiceOver filtert das Bild vollständig aus dem Rotor-Menü „Bilder“. Wenn im Text eine Bildbeschreibung steht, verleitet das vielleicht dazu, den Alt-Text wegzulassen. Die Beschreibung ist ja sichtbar und wird im linearen Lesefluss erfasst. Schauen wir uns das an.

Die reale Konsequenz

Wer sich gezielt über das Rotor-Menü durch die Abbildungen eines Buchs bewegt, bekommt diese Information nicht angeboten. Das Bild existiert jetzt in dieser Navigationsansicht nicht. Über zentrale Einstellungen können Screenreader Bild-Elemente ohne Alt-Text aus diesem Strukturverzeichnis aussortieren lassen. Das Weglassen des Alt-Textes sorgt dann ungewollt dafür.

Die Kehrseite

Werden dekorative Bilder oder Elemente wie Trennzeichen wiederum ohne aria-hidden="true" platziert, zwingt man den Leser durch akustisches Rauschen („Stern, Stern, Stern“). Dieses Attribut gehört an Designelemente, zu denen auch Bilder gehören, die von Screenreadern vollständig ignoriert werden sollen, um unnötige Stopps beim Navigieren zu vermeiden. Durch das fehlende Alt-Tag werden sie aus gutem Grund nicht in das Rotormenü aufgenommen und gleichzeitig aus dem Lesefluss entfernt.

Der Blindflug im Kapitel (Überschriften-Hierarchie)

Die Ursache

Überschriften werden nur optisch über CSS (z. B. <p class="title">) groß skaliert oder die Ebenen (h1 bis h4) werden nach Aussehen statt nach funktionaler Strukturierung gewählt.

Die Wirkung

Die visuelle Hierarchie existiert, aber die technische Navigationsachse im Accessibility-Baum fehlt. Die Kapitel-Binnennavigation bleibt unvollständig. Zusätzlich können Navigationen dann technisch nicht einfach mal nachgebaut werden, da die Tag-Struktur im HTML schon fehlt. Heuristik kann manchmal solche Strukturen erkennen und ersetzen. Bleibt aber fehleranfällig.

Die reale Konsequenz

Das primäre Orientierungswerkzeug – das Rotor-Menü „Überschriften“ – wird unnutzbar. Leser können nicht von Abschnitt zu Abschnitt springen. Sie werden gezwungen, das Dokument zeilenweise abzuhören oder jedes Mal das globale Inhaltsverzeichnis anzusteuern, um sich neu zu verorten. Man muss sich dann aber erstmal das gesamte Inhaltsverzeichnis durchhören, damit man den gewünschten Punkt findet. Dabei ist man bereits im Kapitel und könnte es über die Rotormenü-Funktion mit einer Tastenkombination aufrufen. Eine korrekte h1–h6-Struktur liefert genau diese essenzielle Abkürzung für einen unterbrechungsfreien Lesefluss.

Der digitale Geister-Seitensprung (Doppelte Page-Breaks)

Die Ursache

Ein Kapitel ist als eigene XHTML-Datei angelegt, zusätzlich wird im CSS ein hartes page-break-before: always erzwungen. Layout-Programme übersetzen hier oft schlicht die Einstellungen aus dem Print-Satz doppelt.

Die Wirkung

Das Lesesystem führt zwei Umbruch-Anweisungen hintereinander aus und generiert eine technisch reale, leere Seite im Hintergrund.

Die reale Konsequenz

Screenreader melden einen neuen Abschnitt, lesen nichts vor und verunsichern den Leser („Habe ich etwas verpasst? Bin ich in einem anderen Teil gelandet?“). Eine leere Seite wird beim Betreten nicht als solche angekündigt. Man muss erst hineinsteuern, um festzustellen, dass sie leer ist, und wieder herausmanövrieren. Der Lesefluss bricht ab – genau in dem Moment, in dem man herausfinden wollte, ob sich das Hauptpaar nun endlich küsst. Da eine eigene XHTML-Datei im EPUB bereits einen Seitenumbruch erzeugt, reicht es aus, das CSS von Umbruch-Befehlen im Kapitelstart zu bereinigen, wo die Trennung der XHTML-Seite diese Funktion bereits übernimmt.

Das Inhaltsverzeichnis des Grauens

Die Ursache

Die Layout-Software exportiert Inhaltsverzeichnisse auf Basis unvollständiger Voreinstellungen. Navigationspunkte werden automatisch nummeriert, Zeilennummern und Punkte-Ketten als fester Text exportiert oder das Verzeichnis besteht aus nur drei Einträgen, weil im Satzprogramm keine Überschriften-Struktur definiert wurde.

Die Wirkung

Für Nutzer von Screenreadern entsteht eine akustische Hölle. Sie hören wahlweise:

• Verschachtelte Monster-Listen („Liste 58 Objekte, 1 von 58, 1, Liste 58 Objekte, 2 von 58…“),
• Zeichenwüsten aus Vorgängerpunkten („Einführung . . . . . . . . 12 Kapitel 1 . . . . . . . . 15“),
• oder vier finale Navigationspunkte in einem 2.400-Seiten-Werk: Cover, Anfang, Mitte, Ende.

Die reale Konsequenz

Die Schnellnavigation im E-Reader ist für alle Lesenden ein Graus. Steht wie schon weiter oben thematisiert nicht mal eine Überschriftenstruktur zur Verfügung, ist das Buch wie ein Sprung ohne Fallschirm, nach der Landung ein Ozean ohne Kompass in einer Welt, die keinen Funkturm enthält, um nach Hause zu telefonieren. Die Leserschaft muss das Buch also jetzt manuell durchblättern. Screenreader lesen stumpf Punkt-Reihen vor („Punkt, Punkt, Punkt, Punkt…“). Und das 58-mal die Anzahl der Punkte. Das digitale Inhaltsverzeichnis ist kein visuelles Deko-Element. Es ist der primäre Kompass für das gesamte Dokument.

Der wirtschaftliche Blindfleck (Metadaten & Markt-Ausschluss)

Die Ursache

Der Inhaltsbereich ist ordentlich strukturiert, aber im EPUB-Package oder den ONIX-Metadaten fehlen die Barrierefreiheits-Deklarationen (accessibilitySummary, accessMode) oder der <title>-Tag im Header.

Die Wirkung

Bibliotheken, Distributoren und Shops können das E-Book nicht als zugänglich klassifizieren. Wenn der <title>-Tag fehlt, liest der Screenreader stattdessen den Dateinamen vor („kapitel_01_final_v2.xhtml“).

Die reale Konsequenz

Zielgruppen, die gezielt nach barrierefreien Titeln filtern, bekommen das Buch im Shop gar nicht erst angezeigt. Der Aufwand bei der Formatierung bleibt wirtschaftlich wirkungslos.

Fazit: (Don’t) Make Me Think!

In der Web-Entwicklung gilt das UX-Gebot „Don’t make me think“ – Systeme sollten so gebaut sein, dass Nutzer:innen nicht nachdenken müssenss. Bei der Erstellung digitaler Dokumente erleben wir heute das Gegenteil: Software, Baukästen, Exporter und Checklisten nehmen das Denken ab, erzeugen dabei aber eine unverständliche Masse in digitaler Form. Da man Barrierefreiheit und technisches Verständnis hier leichter passieren kann, muss man nicht darüber nachdenken und der grüne Haken gibt uns Recht.

Aber: Wir müssen aber wieder anfangen nachzudenken.

Code ist kein Selbstzweck. Er ist die Verkabelung, die eine Information von A nach B transportiert. Welches Kabel wo platziert werden muss und warum es dort liegt, ist keine reine IT-Frage. Informationsarchitektur die von Menschen für Menschen gemacht wird erfordert das Durchdenken dieser Gestaltung für Alle.

Gutes Buchdesign ordnet Informationen visuell durch Typografie, Abstände und Rahmen. Gute Code-Architektur tut exakt dasselbe – nur in diesem Fall aus deutlich mehr Perspektiven in fluiden Umgebungen. Es sind nicht nur Nuancen. Beide Welten verfolgen dasselbe Ziel: Funktion, Ordnung und Verständnis. Nur die Sprache ist eine andere.

Barrierefreiheit besteht hier nicht nur aus Code und Attributen. Menschen und ihre Bedürfnisse sind individuell, sie lassen sich nicht vereinheitlichen. Wer die Wechselwirkung versteht, baut Bücher, die nur auf eine Art zum Nachdenken anregen: durch ihren Inhalt.