E-Book-Barrierefreiheit: Screenreader und ihre Lesegewohnheiten

Nach der Veröffentlichung der BFSGV blieben viele Fragen unbeantwortet, nicht zuletzt die, wie eigentlich ein barrierefreies E-Book aussehen muss? Wie üblich wenn eine schwergewichtige Frage die Branche umtreibt, werden Experten, Consultants, Working Groups und Task Forces ins Werk gesetzt, mithin ein nicht unwesentlicher Joint Effort, der Recommendations, Guidelines, Best Practices und andere Formen akkumulierter Knowledge produziert.

Doch nicht alles was geraten wird ist gut, sondern manchmal nur gut gemeint. Manche Empfehlungen erzeugen nur hohe Aufwände, obwohl sie nachweislich keine Auswirkungen auf die Barrierefreiheit haben. Daher soll es an dieser Stelle darum gehen, welche Maßnahmen die E-Book-Barrierefreiheit verbessern und welche nur für die Galerie sind.

Hervorhebungen: Betont oder kursiv?

Keiner großen Diskussion bedarf, dass man für kursive und fette Auszeichnungen span-Elemente vermeiden sollte, weil für diesen Zweck schon geeignetere Tags wie i und b existieren. Bei den Kollegen von Siteimprove liest man auch, dass man statt i und b lieber die „semantischen“ Tags em und strong verwenden solle. em steht für eine Betonung, strong für eine stärkere Betonung. Wer sich nun fragt, wofür man semantische Tags braucht, wo doch schon kursiv und fett eine schwache und starke Betonung beim Vorlesen intendieren, der wird auch bei einem Blick in die HTML Spec nicht viel schlauer:

The em element represents stress emphasis of its contents.
HTML Standard: The em element

Gut könnte man meinen, em verwendet man um Text zu betonen. Weiter unten heißt es aber:

The em element isn’t a generic „italics“ element. Sometimes, text is intended to stand out from the rest of the paragraph, as if it was in a different mood or voice. For this, the i element is more appropriate.
HTML Standard: The em element

Ich versuche zu übersetzen: em verwendet man zur Betonung von Wörtern und i um Wörter zu betonen. Soweit so unklar? Für meine Begriffe ist die Abgrenzung zwischen em und i mehr als dürftig. em soll laut HTML Spec auch Betonungen wie „anger“ und „cuteness“ transportieren, was immer man auch von einem Text halten soll, der diese Emotionen nur mit HTML-Tags auszudrücken vermag?

Da Autoren nur über Knöpfchen für Kursiv und Fett verfügen, kommt em und strong am Ende des Tages keine andere Bedeutung als „kursiv“ und „fett“ zu. In Hinblick auf die Barrierefreiheit spielt diese Unterscheidung übrigens gar keine Rolle: Gängige Screenreader wie JAWS, NVDA oder Microsoft Narrator ignorieren Tags wie i und em in der Voreinstellung.

Man kann den sogenannten formatting verbosity level bei Screenreadern einstellen, aber dieser ist mit Absicht niedrig angesetzt, um die Benutzer nicht zu stören, wie ein NVDA-Entwickler in einem GitHub-Kommentar anmerkte. Screenreader geben nur jene, für das Textverständnis wesentlichen Tags wie z.B. Einfügungen und Löschungen wieder. Die folgende Tabelle zeigt, was Screenreader buchstabengetreu bei jedem HTML-Tag vorlesen:

Tag	Beispiel	JAWS	NVDA	MS Narrator
i	kursiv	❌	❌	❌
b	fett	❌	❌	❌
em	betont	❌	❌	❌
strong	stark betont	❌	❌	❌
s	gestrichen	❌	„gelöscht“	❌
mark	hervorgehoben	„Hervorhebung“	„hervorgehoben“	❌
ins	eingefügt	„Einfügung“	„eingefügt“	❌
del	gelöscht	„Löschung“	„gelöscht“	❌

Textstruktur

Offenbar ignorieren Screenreader beim Vorlesen die meisten HTML-Tags. Dennoch gibt es ein paar Ausnahmen, die zum Verständnis der Textstruktur wichtig sind. Alle getesteten Screenreader weisen gesondert auf Überschriften, Links und Listen hin. Bei Überschriften wird die Hierarchieebene mit angegeben. JAWS und NVDA melden auch Zitatblöcke. Nur als Anmerkung, weil es mitunter zu Missverständnissen kommt: Das cite-Tag dient in Zitatblöcken zur Auszeichnung eines kreativen Werks, nicht für dessen Autor, wird aber auch von keinem Screenreader vorgelesen. Der sonst eher wortkarge MS Narrator sagt bei Tabellen noch Zeilen- und Spaltennummer an, während JAWS und NVDA nur nacheinander den Inhalt der Tabellenzellen vorlesen.

Tag	JAWS	NVDA	MS Narrator
nav	„Navigation-Region“	❌	❌
section/h1	„Überschrift Ebene Eins“	„Überschrift Ebene Eins“	„Überschriftenebene Eins“
section/h2	„Überschrift Ebene Zwei“	„Überschrift Ebene Zwei“	„Überschriftenebene Zwei“
a	„Link“	„Link“	„Link“
blockquote	Zitatblock	„Zitatblock“	❌
cite	❌	❌	❌
ul	„Liste mit x Einträgen“	„Liste mit x Elementen Aufzählungszeichen“	„Liste Aufzählungszeichen x von x“
ol	„Liste mit x Einträgen“	„Liste mit x Elementen“	„Liste x von x“
figure	❌	„Illustration“	❌
img	„Abbildung“ und Alternativtext	Alternativtext	Alternativtext
table	❌	❌	„Zeile x von x, Spalte x von x“
pre	❌	❌	❌
code	❌	❌	❌

Barrierefreie Semantik

HTML wurde ursprünglich nur für die visuelle Darstellung von Webseiten entwickelt. Buchtypische Elemente Register und Fußnoten sind in HTML nicht vorgesehen. Aus diesem Grund wurde mit EPUB 3.0 das Structural Semantics Vocabulary (SSV) eingeführt, um mittels epub:type-Attributen den HTML-Code anzureichern.

Es werden allerdings nur wenige epub:type-Attribute von EPUB-Readern unterstützt. Zudem steht SSV in Konkurrenz zu Barrierefreiheits-Standards wie WAI-ARIA. Wie bei epub:type wird das HTML mit ARIA-role-Attributen angereichert, um die Barrierefreiheit zu verbessern. Daher bemühen sich die Autoren des EPUB-Standards mit der Veröffentlichung von Version 3.3 um mehr Trennschärfe:

This means that adding epub:type values to semantically neutral elements like [html] div and span does not make them any more accessible to assistive technologies. Only ARIA roles influence how assistive technologies understand such elements. The epub:type attribute is consequently only intended for publishing semantics and reading system enhancements.
EPUB 3.3: The epub:type attribute

Kurz gefasst dienen epub:type nur noch zur Unterstützung von technischen EPUB-Reader-Funktionen. Für die Verbesserung der Barrierefreiheit sollen ARIA roles verwendet werden. Das World Wide Web Consortium (W3C) bietet zur Abbildung von epub:type-Attributen auf ARIA-roles eine Übersicht. Für viele epub:types existiert jedoch kein ARIA-Äquivalent. Zudem machen Screenreader nur bei wenigen ARIA-roles den Zuhörer darauf aufmerksam:

ARIA role	JAWS	NVDA	MS Narrator
doc-toc	❌	❌	❌
doc-chapter	❌	❌	❌
doc-appendix	❌	❌	❌
doc-bibliography	❌	❌	❌
doc-footnote	„Fußnote“	„Fußnote“	❌
doc-biblioref	❌	❌	❌

Navigation

Der EPUB-Standard verlangt das Einfügen eines Inhaltsverzeichnisses, das sogenannte toc nav. Die Reihenfolge der Inhaltsverzeichniseinträge muss der Reihenfolge der HTML-Dokumente (im EPUB spine) und ihres Inhalts folgen. Man sollte für die Auszeichnung immer ein ol-Element verwenden, um die Überschriftenhierarchie auch im Inhaltsverzeichnis abzubilden.

<nav role="doc-toc" epub:type="toc">
   <h1>Inhaltsverzeichnis</h1>
   <ol role="directory">
      <li><a href="preface.xhtml">Vorwort</a></li>
      <li><a href="chap_01.xhtml">Kapitel 1</a>
        <ol>
          <li>
            <a href="chap_01.xhtml#sect1-1">Abschnitt 1.1</a>
          </li>
        </ol>
      </li>
      <!-- (…) -->
   </ol>
</nav>

Optional kann man auch ein landmarks nav und ein pagelist nav verwenden:

1. Ersteres bietet im Unterschied zum toc nav eine Übersicht über die grundsätzlichen strukturellen Komponenten des Buches, wie z.B. Inhaltsverzeichnis, Beginn des Inhalts und Anhang.
2. Zweiteres stellt eine Möglichkeit dar, die Seitenumbrüche des gedruckten Buches auch im EPUB abzubilden. Wenn man die Seitenzahlen mit der ARIA-role doc-pagebreak einfügt, weisen weder JAWS, NVDA noch MS Narrator darauf hin, dass es sich um einen Seitenumbruch handelt, sondern lesen nur die Zahl vor. Wenn man den Seitenumbruch nur als Tag aber nicht als Text einfügt, wird dieser auch nicht vorgelesen.

Language Tagging

Die englische und französische Sprache teilen sich das Wort „Prononciation“ und nur mit der korrekten Betonung weiß man, welcher Sprache es entstammt. In diesem Sinne müssen auch die verwendeten Sprachen kodiert werden, damit ein Screenreader die korrekte synthetische Stimme auswählt. Das geschieht auf mehreren Ebenen. Im HTML muss die Hauptsprache und Passagen mit Sprachwechseln mit dem lang-Attribut ausgezeichnet werden. Aber auch für die Interpretation der OPF-Metadaten muss die Sprache mit einem xml:lang-Attribut und einem <dc:language>-Element versehen sein. Hier ist ein kleines Beispiel für korrekte Metadaten:

<?xml version="1.0" encoding="UTF-8"?>
<package xmlns="http://www.idpf.org/2007/opf" 
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:dcterms="http://purl.org/dc/terms/" 
  version="3.0" xml:lang="de">
  <metadata>
    <!-- (…) -->
    <dc:language>de</dc:language>        
  </metadata>
  <!-- (…) -->
</package>

Das sauberste Language Tagging nützt nichts, wenn dem Screenreader die Sprachen nicht zur Verfügung stehen. Auf dem Desktop muss man die fehlenden Sprachpakete selbst installieren, ansonsten wechselt der Screenreader trotz korrektem Language Tagging nicht die synthetische Stimme. Dieser Mangel wiegt insbesondere bei geisteswissenschaftlichen Texten schwer, die nicht selten Griechisch, Hebräisch, Aramäisch und andere Sprachen beinhalten. Aber es bedeutet auch, dass man bei Problemen Nachforschungen betreiben muss, wo das System des Users vielleicht schief liegt.

Alternativtexte

Es besteht kein Zweifel daran, dass man für Bilder, die zum Textverständnis beitragen, Alternativtexte hinterlegen muss. Das geschieht ganz einfach, indem man das HTML-Tag für Bilder <img> um ein alt-Attribut ergänzt. JAWS, NVDA und der MS Narrator lesen einfach den Alternativtext vor, JAWS gibt zumindest noch den Hinweis, dass es sich um eine „Abbildung“ handelt. Dabei sollte der Alternativtext möglichst kurz den wesentlichen Inhalt des Bildes in ein bis zwei Sätzen darstellen. Mit dieser Vorgabe stößt man bei der Beschreibung von wissenschaftlichen Darstellungen jedoch schnell an seine Grenzen.

Der Wissenschaftsverlag De Gruyter empfiehlt in seinen Image Alt Text Guidelines daher die Verwendung von sogenannten long descriptions. Die Frage ist nur wie diese ausführlichen Bildbeschreibungen abgebildet werden können? Die Techniques for WCAG 2.0 des W3C empfehlen für längere Bildbeschreibungen das longdesc-Attribut. So lässt sich ein Bild mit einem HTML-Dokument assoziieren, welches die ausführliche Bildbeschreibung enthält.

<img src="duchamp_LHOOQ.jpg"
     alt="The work of art L.H.O.O.Q. by Marcel Duchamp" 
     longdesc="img-descriptions/duchamp_LHOOQ.html"/>

Entgegen der mutmaßlich veralteten Empfehlung des W3C würde ich von dem Gebrauch von longdesc eher abraten. Das Attribut ist im HTML-Standard als obsolet markiert, d.h. es wird in zukünftigen Revisionen entfernt werden. Über kurz oder lang würde die Verwendung des Attributes dann zu invaliden E-Books führen, weil der EPUB-Standard an die HTML-Spezifikation gebunden ist. Als Alternative wird empfohlen, das Bild einfach in einen Link zu schachteln, der auf die Beschreibung verweist:

<a href="img-descriptions/duchamp_LHOOQ.html">
  <img src="duchamp_LHOOQ.jpg" 
       alt="The work of art L.H.O.O.Q. by Marcel Duchamp"/>
</a>

Eine interessante Alternative für die Zukunft könnten HTML Image Maps bieten. Damit lassen sich Bildbereiche durch Koordinaten bestimmen und mit Alternativtexten und Links auf andere HTML-Dokumente versehen: Auf diese Weise könnte man verschiedene Teile einer schematischen Darstellung mit separaten Alternativtexten beschreiben.

<img src="shapes.png" usemap="#shapes"
     alt="die Grundformen und -farben nach Kandinsky"/>
<map name="shapes">
  <area shape=rect coords="25,25,125,125" 
        href="img-descriptions/viereck.html" 
        alt="rotes Viereck"/>
  <area shape=circle coords="200,75,50" 
        href="img-descriptions/kreis.html" 
        alt="blauer Kreis"/>
  <area shape=poly coords="325,25,262,125,388,125" 
        href="img-descriptions/dreieck.html" 
        alt="gelbes Dreieck"/>
</map>

Metadaten

Die EPUB Accessibility 1.1 Guidelines haben eine Reihe neuer Metadaten eingeführt, welche die Barrierefreiheits-Features eines E-Books beschreiben sollen. So werden Mechaniken geschaffen, die es erstmals erlauben, Disclaimer anzuzeigen, wenn etwa ein Video in einem E-Book flackernde Inhalte enthält, die epileptische Anfälle auslösen können. Aber auch weniger dramatisch stellt es eine sinnvolle Information dar, ob die Bilder Alternativtexte enthalten oder eben nicht.

Zu diesem Zweck wird die Semantic-Web-Taxonomie von Schema.org implementiert. Diese stellt ein Set von Metadaten zur Verfügung, mit denen man verschiedene Aspekte der Barrierefreiheit beschreiben kann. Hier ist eine kleine Übersicht der verfügbaren Metadaten:

Metadatum	Beispiele	Beschreibung
schema:​accessMode	textual, visual, auditory	Sinne mit denen der Inhalt erfahrbar wird
schema:​accessMode​Sufficient	textual, visual, auditory	welche Sinne sind ausreichend zum Verständnis
schema:​accessibility​Feature	alternativeText, longDescription, MathML, transcript, synchronizedAudioText	welche Barrierefreiheits-Features bietet der Titel
schema:​accessibility​Hazard	flashing, noMotionSimulationHazard, noSoundHazard	welche Risiken birgt das Buch
schema:​accessibility​Summary	Das E-Book enthält Alternativtexte	eine kurze, menschenlesbare Zusammenfassung über die Barrierefreiheit

Während die ersten drei Metadaten eine maschinenlesbare Beschreibung der Accessibility-Features bieten soll, die etwa ein E-Book-Shop automatisch auswerten könnte, bleibt die Spezifikation beim accessibilitySummary eher vage: Menschenlesbar soll es sein, den Inhalt der anderen Metadaten nicht wiederholen und auf Defizite hinweisen. Nicht überraschend war dann auch die am häufigsten von unseren Kunden gestellte Frage, was man da eigentlich genau eintragen soll? An sich müsste die Zeile „um die Barrierefreiheit dieses E-Books waren wir stets bemüht“ den Anforderungen Genüge leisten.

Die goldene Regel aller technischen Standards, dass ein unterspezifizierter Teil einer Spezifikation meistens in eine neue Spezifikation mündet, bewahrheitet sich auch in diesem Fall. Statt das Accessibility Summary in einer zukünftigen Revision stillschweigend zu kassieren, hat das W3C eine weitere Spezifikation veröffentlicht, die sich ausschließlich mit dem richtigen Schreiben eines Accessibility Summary beschäftigt. Da das Accessibility Summary seit Version 1.1 der EPUB Accessibility Guidelines kein Pflichtfeld mehr ist und von keinem der getesteten Reader interpretiert wird, kann man es getrost entsorgen, sobald Accessibility-Checker die jüngste Revision der Guidelines vernünftig umsetzen. Zusammenfassend muss man leider feststellen, dass bis dato weder E-Book-Reader noch Screenreader die in diesem Abschnitt aufgeführten Metadaten auswerten.

Für blinde und sehbehinderte Menschen wäre das Wissen um die Barrierefreiheit eines E-Books aber sicher vor dem Kauf nützlicher. Diese Informationen müssten also schon mit der ONIX-Meldung des Titels an den Webshop gelangen. Dafür bietet ONIX die Code-Liste 196, welche Metadaten für die Barrierefreiheit von E-Books bereitstellt. Mir ist aber kein Web-Shop bekannt, der diese Metadaten schon irgendwo darstellen würde.

Cover

Getreu dem Motto, don’t judge a book by its cover geht es bei Literaturbesprechungen in der Regel nicht um den Umschlag, sondern das bedruckte Papier dazwischen. Daher könnte man sich fragen, ob ein Alternativtext für das Cover irgendeinen Nutzen für das Textverständnis hat? Nichtsdestotrotz wurde an uns die Anforderung eines Cover-Alternativtextes mit der Begründung herangetragen, dass dieser bei der Auswahl eines Buches im Web-Shop helfen würde.

Mal abgesehen davon, dass bei Amazon, Thalia und Co. aussagekräftigere Inhaltsbeschreibungen und Kundenrezensionen zu finden sind, werden die Cover auch über die ONIX-Meldung und nicht das EPUB geliefert. Schließlich werden Titel auch schon vor ihrer Veröffentlichung in die Shops gestellt um Vorbestellungen zu ermöglichen. Wer sich im Web-Shop einen Alternativtext wünscht, der müsste ihn mit der ONIX-Meldung liefern. Für meine Begriffe würde ein Cover-Alternativtext eher aus dem Grund Sinn machen, dass man blinden und sehbehinderten Menschen überhaupt die Entscheidung ermöglicht, ob der Inhalt des Umschlags relevant für den Inhalt ist.

Da es auch schon an uns gemeldet wurde, hier nochmal zur Aufklärung: Falls das einzige Bild eines EPUBs das Cover ist, rechtfertigt das laut EPUB Accessibility Techniques nicht visual als schema:accessMode-Metadatum:

Most EPUB publications contain cover images, for example, but it is not necessary to see the cover image to read the publication

Fazit

Wie eingangs erwähnt besteht kein Mangel an Anleitungen zur Barrierefreiheit und es steht jedem frei, den Code wie einen Weihnachtsbaum mit ARIA-Attributen auszuschmücken und letztlich handhaben wir das auch bei transpect so. Allerdings müssen sich gerade kleine Verlage und Satzbetriebe mit weniger Automatisierung überlegen, welche Dinge sie wirklich umsetzen wollen. Die meisten Auszeichnungen und Metadaten werden von JAWS, NVDA & Co. ignoriert. Daher sollte man sich auf die Punkte konzentrieren, die für die Barrierefreiheit wirklich wichtig sind: Navigation, Gliederung, Sprachtagging und Alternativtexte. Wer das richtig macht, kann sich auch die Schreibwerkstatt für das Accessibility Summary sparen.