Case Study:
EPUB 3.3 Reflowable*
* Hinweis: Diese Case Study wurde am 10. Juni 2026 um aktuelle europarechtliche Entwicklungen zur Barrierefreiheitsrichtlinie ergänzt (direkt zum Update zur EU-Richtlinie springen).
Das Problem: Semantische Architektur vs. Print‑Layout
Automatisierte Exporte aus klassischen Layout-Programmen generieren oftmals fehlende HTML5-Semantik und unnötig aufgeblähte Stylesheets. Verschachtelte <div>– und <span>-Container mögen visuell funktionieren führen aber zu Performance-Problemen, Darstellungsfehlern auf älteren E-Readern und einer schlechteren Barrierefreiheit.
Die Konsequenz: manuelle Nacharbeit, Validierungsfehler bei Distributoren und das Verstöße gegen gesetzliche Vorgaben (European Accessibility Act). Ein EPUB ist eine Web-Applikation und erfordert einen nativen Herstellungsprozess auf Code-Ebene.
Der Befund: Die Grenzen automatisierter Validierung
Die Praxis zeigt ein wiederkehrendes Paradoxon: E-Books bestehen die offiziellen Markt-Validatoren fehlerfrei, sind jedoch weder barrierefrei noch plattformstabil. Automatisierte Prüftools erkennen strukturelle Defizite nicht, solange der Code syntaktisch korrekt geschrieben ist.
Die Analyse der Standard-Exporte deckt diese stummen Strukturfehler auf:
- Maskierte Absätze statt echter Hierarchie: Layout-Programme und Konvertierungen aus Word-Dokumenten neigen dazu, Überschriften als Standard-Absatz (
<p>) zu exportieren. Die Hierarchie wird dann ausschließlich über visuelle CSS-Eigenschaften (Schriftgröße, Fettung) simuliert. Der EPUBCheck meldet 0 Fehler, da der Code valide ist. Für Screenreader existiert das Dokument jedoch ohne Überschriftenstruktur. - Exorbitanter CSS‑Overhead (Das Tabellen-Problem): Ein nativer Export (z. B. aus Affinity) erzeugt für komplexe Elemente wie Tabellen oft für jede einzelne Zeile und Zelle ein separates, eindeutiges Inline-Style oder eine eigene CSS-Klassen. Das Ergebnis ist ein unlesbares, 1500 Zeilen langes Stylesheet. Jede spätere globale Designanpassung wird dadurch fast unmöglich.
- Semantische Blindheit: Ein Validator prüft nicht, ob ein Bild eine Beschreibung benötigt, ob ein
<div>eine Zelle einer Tabelle sein soll oder Elemente logisch aufgebaut sind. Er registriert lediglich die Anwesenheit der Tags.
Die Methodik: Markdown-zu-EPUB Workflow als Lösung
Der Showcase aus dieser Case Study demonstriert einen technologisch anderen Ansatz. Durch einen Workflow basierend auf Markdown entsteht eine minimale, objektorientierten und kaskadenbasierte Code-Architektur (max. 400 Zeilen CSS). Dies eliminiert redundanten Code und liefert eine technisch saubere Basis, die mit minimalem Aufwand für maximale Barrierefreiheit weiter optimiert werden kann.
Das Ergebnis der Code‑Optimierung: Echte Semantik
Die markdown-basierte Strukturierung löst die Diskrepanz anderer Workflows durch den gezielten Einsatz von Code-Architektur auf:
- Strikte Trennung von Inhalt und Design: Das Stylesheet wurde von über 1000 Zeilen redundantem Code auf unter 400 Zeilen kaskadierendes, objektorientiertes CSS reduziert. Elemente erben ihre Eigenschaften global, statt jede Zeile separat zu formatieren. Die Datei bleibt schlank und plattformübergreifend wartbar.
- Verifizierte Barrierefreiheit über den Validator hinaus: Durch den gezielten Einsatz von echten Überschriften-Tags (
<h1>bis<h3>), Tabellen-Headern (<th scope="col">), bidirektionaler Verlinkung, korrekte Attribute und Landmark-Rollen wird sichergestellt, dass assistive Technologien die logische Struktur der Datei erfassen. Die Barrierefreiheit ist hier im Code verankert, statt nur visuell simuliert zu werden.
1. Beispiele aus der Praxis
- Hybride Attributierung: Kombination aus EPUB-spezifischen strukturellen Attributen (
epub:type) für die Abwärtskompatibilität und W3C ARIA-Rollen (role) zur nativen Ansprache von Screenreadern. Dies stellt die technische Konformität mit den Barrierefreiheitsanforderungen der WCAG 2.1 AA für assistive Technologien sicher. - Maschinenlesbare Tabellenstrukturen: Komplexe Datensätze werden in semantischen
<figure>-Containern mit<figcaption>gekapselt. Die Verwendung von Spalten- und Zeilen-Headern (<th scope="col">) erlaubt assistiven Technologien eine logische, achsenbasierte Navigation. - Bidirektionale Verlinkung: Fuß- und Endnoten werden als interaktive Sprungmarken verankert. Dies ermöglicht die standardkonforme Popup-Darstellung auf modernen Geräten und schließt strukturelle Sackgassen im Dokument aus.
2. Dreifache technische Validierung & Compliance
Ein ansprechendes Layout ist im digitalen Publizieren wertlos, wenn der Code beim Upload abgewiesen wird. Diese Architektur durchläuft die drei kritischen Prüfinstanzen der Industrie fehlerfrei:
- Strukturelle Integrität (EPUBCheck 5.1.0): Die Datei ist nach den strengen Vorgaben des W3C für EPUB 3.3 valide (0 Fehler, 0 Warnungen). Garantierte Akzeptanz bei allen globalen E-Book-Händlern.
- Gesetzliche Barrierefreiheit (DAISY Ace): Vorbereitet auf das Barrierefreiheitsstärkungsgesetz (BFSG). Der automatisierte Prüfbericht des Industriestandards DAISY Ace bestätigt 0 Verstöße gegen die aktuellen WCAG Level AA Anforderungen.
- Darstellungsstabilität (W3C CSS Validator): Das Stylesheet ist auf CSS Level 3 validiert und frei von Syntaxfehlern für ein unfallfreies Rendering über alle Plattformen hinweg.
3. Cross‑Platform Rendering & Layout-Stabilität
Die Fragmentierung der Rendering-Engines (Apple WebKit vs. Amazon KF8) führt oft zu zerrissenen Layouts auf Zielgeräten. Diese Case Study beweist ein robustes Fallback-System:
- Native Dark-Mode-Compliance: Die Nutzung von relativen Farbwerten (
currentColor) garantiert eine fehlerfreie Invertierung der Typografie im Nachtmodus, während semantische Akzentfarben (#D86DCB) als harter Kontrast erhalten bleiben. - Typografie & Gestaltung: Eine präzise ausbalancierte CSS‑Kaskade sichert eine normgerechte, branchenübliche Typografie, ohne auf gestalterische Flexibilität zu verzichten. Spezifische WebKit-Präfixe (Apple) werden strategisch als Fallback eingesetzt, um komplexe Parameter zu steuern, ohne Konflikte auf älteren Kindle-Generationen oder proprietären E-Ink-Systemen auszulösen.
- Responsive Viewports: Tabellen, Einzüge und verschachtelte Listen skalieren dynamisch von Smartphones bis zu Tablets, ohne horizontale Scrollbalken zu erzwingen.
Fazit: Publish‑Ready statt Nachbesserungsschleifen
- Jeder abgewiesene Distributor-Upload kostet operative Zeit und Marge. Ein sauberes E-Book erfordert den kompromisslosen Aufbau einer semantischen Code‑Architektur. Dieses Projekt demonstriert, wie ein auf Markdown basierender Workflow den Standard für eine reibungslose, normgerechte und barrierefreie Veröffentlichung setzt.
- Barrierefreiheit im Code ist kein starres, juristisches Produkt, das man fehlerfrei von der Stange kauft, sondern ein fortlaufender handwerklicher Prozess am Stand der Technik. Mein Anspruch ist es nicht, unkonkrete Gesetze juristisch auszulegen, sondern das technisch bestmögliche Fundament im XHTML-Quelltext zu verankern.
- Selektorenbasierte CSS-Styles und HTML5-Tags bieten nachhaltig lesbare Strukturen. Das resultierende EPUB 3.3 ist strukturell und technisch so aufgebaut, dass es auf Code‑Ebene leicht lesbar ist. Sollten später doch Nacharbeiten oder Updates nötig sein, entwickelt sich das nicht zu einem unkontrollierten Zeitfresser für deine Teams.
Überzeuge dich selbst von der Code-Qualität. Lade hier die vollständige Datei herunter, prüfe die Struktur im eigenen Validator und teste das Verhalten auf deinen Zielgeräten.
Hinweis zur technischen Umsetzung der Fußnoten:
Ich habe mich hier bewusst für die modernere Variante des EPUB 3.3-Standards (Fußnoten-Sections direkt am Kapitelende) entschieden. Diese Methode wird von den meisten E-Reading-Systemen voll unterstützt und bietet eine optimale, hybride Funktionalität für Pop-ups und Barrierefreiheit.
Zwar interpretieren vereinzelte Plattformen (wie die Tolino-App) diese Spezifikation derzeit noch instabil, der Verzicht auf das Auslagern in eine separate XHTML-Datei am Buchende bietet jedoch einen entscheidenden redaktionellen Mehrwert: Fußnoten sind in Sachbüchern häufig essenzieller Bestandteil des Textes und damit auch der Leseprobe. Befinden sich die Notizen in einer isolierten Datei am Ende des EPUBs, bleiben sie für potenzielle Käufer in der Leseprobe unsichtbar und unzugänglich.
Durch das Platzieren der Fußnoten in einer <section> direkt am Ende des jeweiligen Kapitels bleiben die Quellen und Zusatzinfos innerhalb der Leseprobe vollständig erhalten und auslesbar. Dies definiert für mich einen zukunftssicheren Standard, der die inhaltliche Integrität und die barrierefreie Teilhabe schon vor dem Kauf sichert.
Update 10. Juni 2026: Europäische Barrierefreiheitsrichtlinie (EAA)
Die Europäische Kommission hat im März 2026 eine zusätzliche mit Gründen versehene Stellungnahme an Deutschland gerichtet. Wie aus der offiziellen Pressemitteilung der Europäischen Kommission hervorgeht, besteht der Hintergrund in fortlaufenden administrativen Umsetzungslücken und verbleibenden Beanstandungen bei der Übernahme der Europäischen Barrierefreiheitsrichtlinie (Richtlinie (EU) 2019/882) in nationales Recht.
Der deutsche Staat hat nun eine zweimonatige Frist zur Nachbesserung erhalten, bevor das Verfahren an den Gerichtshof der Europäischen Union verwiesen werden kann.
Unabhängig von diesen zwischenstaatlichen Mahnverfahren ist die gesetzliche Übergangsfrist für Wirtschaftsakteure bereits im Juni 2025 abgelaufen. Für Verlage bedeutet die anhaltende regulatorische Unschärfe vor allem eines:
Erhöhte Rechtssicherheit bietet in dieser Übergangsphase eine kompromisslose technische Konformität auf Basis standardisierter Validierungsparameter.
- Spezifikation als Standard: Die Anforderungen des Barrierefreiheitsstärkungsgesetzes (BFSGV) werden über die europäische Norm EN 301 549 konkretisiert, welche für digitale Dokumente die Einhaltung der WCAG 2.1 AA-Kriterien vorschreibt.
- Code-Integrität: Die fehlerfreie Validierung mittels EPUBCheck und dem Ace by DAISY Accessibility Checker bildet eine verlässliche Mindestanforderung, um die Konformität bei behördlichen Prüfverfahren nachzuweisen, ersetzt aber keinen Blick in den Code.
- Fokus des Workflows: Der hier beschriebene alternative Produktionsweg über eine native HTML5-Struktur stellt sicher, dass die geforderten technischen Kernkomponenten ohne fehleranfällige manuelle Nacharbeit im Quelltext verankert sind.
Was bedeutet das konkret für die Code-Ebene?
Die technische Umsetzung der Europäischen Barrierefreiheitsrichtlinie (EAA) im „Wildkräuter“-Projekt basiert auf den Handlungsempfehlungen für barrierefreie E-Books des Börsenvereins des Deutschen Buchhandels.
Anstatt sich auf Software-Exporte zu verlassen, trennt dieser Workflow die Basisarchitektur von der semantischen Spezialisierung:
Die Umwandlung von Markdown über den Compiler Pandoc in ein EPUB liefert das fehlerfreie HTML5-Fundament, während die tiefgreifende Barrierefreiheit manuell auf Code-Ebene in Sigil manuell stattfindet (semantische Anreicherung).
Dies lässt sich anhand der vier WCAG-Prinzipien (POUR) im Quellcode belegen:
1. Wahrnehmbarkeit
Informationen müssen so dargestellt werden, dass Anwender sie über verschiedene Sinne aufnehmen können.
- Automatisierte Basis: Das Inhaltsverzeichnis und die Buchteile werden in strikt hierarchischen HTML-Strukturen (
<section>,<h1>bis<h6>,<ul>/<ol>) ausgegeben. - Manuelle Anreicherung:
- Verzicht auf statische Farbwerte im CSS. Durch
color: currentColorpassen sich Texte und Tabellenränder nativ den Nacht- oder Kontrastmodi der Lesegeräte an. - Komplexe Bildelemente werden gekapselt (
<figure>) und innerhalb desselben Dokuments maschinenlesbar mit ihrer Bildunterschrift (<figcaption>) verknüpft. - Tabellen erhalten Achsen-Definitionen (
scope) und statt<ficaption>ein<caption>-Tag im<table>-Tag.
Grund ist der Bezug zur Tabelle:<caption>wird als Beschriftung der Tabelle zugeordnet, welche sichtbar und unsichtbar für alle zugänglich ist.<figcaption>wird nur verwendet, wenn eine weitere Beschreibung notwendig wird, sie aber nicht direkt mitgelesen werden soll, sobald man die Tabelle betritt, oder das Popup die Tabelle vergrößert.
- Verzicht auf statische Farbwerte im CSS. Durch
- Verwendete Code-Praxis (Tabellen): Durch die explizite Achsen-Definition wird die Tabelle zu einem zweidimensionalen, navigierbaren Datenmodell.
<figure class="tabelle">
<table>
<caption>Tabelle 4: Durchschnittliche Nährwerte im Vergleich von Löwenzahn zu Kultursalat</caption>
<!-- Tabellen Kopfzeile -->
<thead>
<tr>
<th scope="col">
Inhaltsstoff
</th>
<th scope="col">
Menge
</th>
<th scope="col">
Vergleich zu Kultursalat
</th>
</tr>
</thead>
<tbody>
<!-- Tabellen-Inhalt / Daten in einer Tabellen Reihe von Links nach Rechts gelesen:
1. Energie wird mit dem <th>-Tag umschlossen. 2. Attribut `scope="row"` fungiert als Lese-Richtung: "alle folgenden <td>-Tags beziehen sich auf Energie". -->
<tr>
<th scope="row">
Energie
</th>
<td>
ca. 45 kcal / 188 kJ
</td>
<td>
Nährstoffdichter als Kopfsalat
</td>
</tr>
</tbody>
</table>
</figure>2. Bedienbarkeit
Navigation und Interaktion müssen für alle Nutzer, unabhängig vom Eingabegerät (z. B. Tastatur- oder Sprachsteuerung), logisch bedienbar sein.
- Automatisierte Basis: Erstellung der elementaren korrekt verschachtelter Navigationsdateien (
toc.xhtml,nav.ncx,spineincontent.opf). - Manuelle Anreicherung:
- Implementierung einer unsichtbaren, tiefgehenden Landmark-Navigation (
epub:type="bodymatter",glossary,endnotes). - Da
aria-describedbynicht dokumentenübergreifend funktioniert, erhalten seitenübergreifende Verweise (Endnoten) ein präzisesaria-label. Um das WCAG-Kriterium 2.5.3 (Label in Name) für Sprachsteuerungen zu erfüllen, beginnt das Label zwingend mit dem sichtbaren Linktext.
- Implementierung einer unsichtbaren, tiefgehenden Landmark-Navigation (
- Code-Praxis (Sichere Endnoten-Navigation):
<!-- Markierung zur Endnote im Text -->
<a id="noteref-b" href="anhang.xhtml#maigloeckchen-endnote" epub:type="noteref" role="doc-noteref" aria-label="Hinweis b: Unterscheidungsmerkmale">[b]</a>
<!-- Die Endnote am Ende des Buches auf einer eigenen XHTML-Seite. -->
<section epub:type="endnotes" role="doc-endnotes" aria-labelledby="endnoten">
<h2 id="endnoten" class="level2">Endnoten</h2>
<ol class="endnoten-liste">
<li id="maigloeckchen-endnote" epub:type="endnote"><p>[b] Das Maiglöckchen ist giftig [...]
<!-- Die Endnote enthält zwei Links. Link 1: Ohne Screenreader liest man nur "Externer Link", damit er nicht zu lang wird. Aria-label vervollständigt die fehlende Information für Screenreader. Link 2: Da hier zwei Links in der Endnote enthalten sind, wurden sie optisch durch Text dazwischen voneinerander getrennt. Eine Endnote braucht einen Backlink zurück ins Kapitel. Screenreader können das erkennen, aber alle anderen nicht. Deshalb wurde der zweite Link mit dem Linktext "Zurück zum Text im Kapitel" versehen. -->
<a href="https://commons.wikimedia.org/wiki/File:20170814Lysimachia_arvensis1.jpg" aria-label="Externer Link zum Vergleichsbild Ackergauchheil auf Wikimedia Commons öffnen">Externen Link</a> zum Vergleichsbild auf Wikimedia Commons öffnen. <a href="ch005.xhtml#noteref-a" epub:type="backlink" role="doc-backlink">Zurück zum Text im Kapitel Vogelmiere</a>.</p></li>
</ol>
</section>3. Verständlichkeit
Texte müssen sprachlich maschinenlesbar und vorhersehbar aufgebaut sein.
- Automatisierte Basis: Die Hauptsprache des Buches wird global in jedem HTML-Dokument deklariert (
<html xml:lang="de" lang="de">). - Manuelle Anreicherung:
- Fremdsprachige Fachbegriffe (z. B. lateinische Pflanzennamen) werden für die Erkennung von Sprachwechsel im Text gezielt isoliert.
- Spezifische Buchbereiche wie das Glossar erhalten W3C-standardisierte Beschreibungslisten (
<dl>). Die visuelle Hervorhebung der Begriffe (<dt>) erfolgt ohne semantisch verfälschende Inline-Tags rein deklarativ über das zentrale CSS-Stylesheet.
- Code-Praxis Glossar:
<!-- Sprachwechsel -->
<span xml:lang="la" lang="la">Allium ursinum</span>
<!-- Eintrag im Glossar -->
<dt id="term-anthocyane" epub:type="glossterm" role="term">Anthocyane</dt>
<dd epub:type="glossdef" role="definition">Pflanzenfarbstoffe [...]</dd>/* term glossar */
dt[role="term"] {
font-weight: bold;
}4. Robustheit
Der Code muss so standardisiert sein, dass er von aktuellen und zukünftigen assistiven Technologien (Screenreadern, Braillezeilen) verlässlich interpretiert wird.
- Automatische Umsetzung im Workflow: Es werden ausschließlich W3C HTML-Standards genutzt, die im EPUB 3.3 Konsortium freigegeben sind. Gleichzeitig werden etablierte Standards zur Unterstützung älterer Systeme beibehalten. Dazu gehört z. B. die Integrierung der
toc.ncxals EPUB 2-Fallback für das Inhaltsverzeichnis. - Validierung: Vor der Auslieferung wird das Dokument nicht nur strukturell (EPUBCheck), sondern explizit auf die geforderten ONIX-Metadaten zur Barrierefreiheit durch den Branchenstandard Ace by DAISY geprüft.
- Code-Praxis (Abwärtskompatibiliät Tabellen):
<!-- XHTML-Validierung und Präfix-Deklaration -->
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" epub:prefix="z3998: http://daisy.org" lang="de-DE" xml:lang="de-DE">
<!-- XHTML-Struktur: Auszeichung der Tabelle durch `epub:type="z3998:table"` zur Unterstützung älterer Reader -->
<figure class="tabelle" epub:type="z3998:table">
<table>
<caption>Tabelle 1: Durchschnittliche Nährwerte im Vergleich von Vogelmiere zu Kultursalat</caption>
<thead>
<tr>
<th scope="col">Inhaltsstoff</th>
<th scope="col">Menge</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row">Vitamin C</th>
<td>115 mg</td>
</tr>
</tbody>
</table>Systemgrenzen und rechtliche Einordnung
Die technische Umsetzung basiert auf der aktuellen Interpretation der EN 301 549 durch Branchenverbände wie den Börsenverein des Deutschen Buchhandels. Da die Gesetzgebung keine detaillierten Code-Spezifikationen für jede assistive Software vorschreibt, definiert die fehlerfreie maschinelle Validierung mittels EPUBCheck und Ace by DAISY den vertraglich geschuldeten Stand der Technik. Die finale juristische Entlastung im Rahmen des BFSGV verbleibt in der Verantwortung der jeweiligen Verlags-Rechtsabteilung, da die fehlerfreie Darstellung auf Endgeräten maßgeblich von der Aktualisierungsrate der genutzten Screenreader-Software abhängt.