Buchbesprechung – „Barrierefreie PDF-Dokumente erstellen“ von Klaas Posselt und Dirk Frölich

Kurzinformationen zum Buch „Barrierefreie PDF-Dokumente erstellen“

Das Buch „Barrierefreie Dokumente“ von Klaas Posselt und Dirk Frölich erschien im Juni 2019 im dpunkt-Verlag. Es ist unterteilt in 14 Kapitel. Neben einer Einführung, mehreren Grundlagenteilen sowie u.a. einem Kapitel zu gesetzlichen Grundlagen sowie Standards gibt es im Übergang zu den Praxiskapiteln (InDesign sowie Office) auch Kapitel zu Anforderungen sowie zu einigen redaktionellen Aspekten und Design-Aspekten. Das Buch schließt mit einem Kapitel zur Prüfung sowie zur Nacharbeitung. Ergänzt wird das Buch durch eine Website mit Download-Dateien für Übungen, einigen weiterführenden Informationen, verschiedenen Checklisten und einer Errata-Seite. Die Autoren haben und setzen den Schwerpunkt auf die Umsetzung gemäß PDF/UA.

Aufgrund der Länge dieser Buchbesprechung verweise ich auf die Vorstellung der Autoren beim dpunkt-Verlag.

Hinsichtlich der Zuordnung einzelner Kapitel zu Autoren verweise ich auf die beim dpunkt-Verlag als Leseprobe verfügbare Einleitung (Abschnitt „Zu den Autoren“).

Hintergrund, Beschreibung und Analyse

Was ein „barrierefreies Dokument“ ist wird von Menschen mit (verschiedenen) Behinderungen unterschiedlich beantwortet. Auch existierende Standards (WCAG – Web Content Accessibility Guidelines, PDF/UA – PDF Universal Accessibility) beantworten die Frage nicht deckungsgleich. Die Antwort aber entscheidet darüber, was 1. umgesetzt werden muss und was 2. zusätzlich die Barrierefreiheit für Menschen mit Behinderungen unterstützt und fördert. Diese „Trennlinie“ ist wichtig und muss sauber gezogen werden. Sie ist relevant für Redaktionsrichtlinien, Konzeption und Design, für die tägliche Praxis und natürlich für Ausschreibungen und Verträge, Prüfungen und Qualitätssicherung. Sie ist insbesondere wichtig für Dokumentersteller (und Dienstleister) im öffentlichen Dienst, da man hier im Zuge der EU-Richtlinie (2016/2102) über den barrierefreien Zugang zu den Websites und mobilen Anwendungen öffentlicher Stellen und der (inzwischen aktualisierten) Barrierefreien Informationstechnikverordnung (BITV 2.0) gesetzlichen Anforderungen unterliegt, die in Zukunft regelmäßig überprüft werden. Im privaten Sektor gibt es aktuell keine Verpflichtungen, aber global agierende Firmen und Dienstleister können dennoch verpflichtet sein, sich an einen bestimmten Standard als Mindestanforderung zu halten.

Im Zuge der Harmonisierung von Standards wurden mit dem europäischen Standard EN 301 549 in der Version 1.1.1 im Jahr 2014 zunächst die Web Content Accessibility Guidelines 2.0 als Mindestanforderung für den öffentlichen Dienst festgelegt. Nach Veröffentlichung der WCAG 2.1 im Juni 2018 wurde Ende letzten Jahres dieser europäische Standard auf die Version 2.1.2 aktualisiert. Entscheidend dabei: Für beide Versionen ist die Stufe AA die Mindestanforderung und damit, was verbindlich umgesetzt werden muss. Auch für sogenannte „Non-web documents“ wurden und Teil des Europäischen Standards – abzüglich vier Erfolgskriterien – die WCAG auf Stufe AA als Mindeststandard definiert. Erwähnt sei noch der Standardisierungsprozess in den USA. Hier entschied das US Access Board in 2017 im Rahmen der Aktualisierung der Section 508 nach einer Anhörung, in der auch PDF/UA diskutiert wurde, letztlich für die WCAG (aktuell in der Fassung 2.0) auf Stufe AA.

Diese Themen werden nach einer allgemeinen Einführung in den ersten Kapiteln des Buches in unterschiedlicher Tiefe behandelt. Leider vermischen sich früh Meinungen, Einstellungen und Bewertungen mit der fachlichen Ebene. Dabei finden sich immer wieder Aussagen zu den WCAG (und damit zum EU-Standard), die ungenau und nicht immer fehlerfrei sind. Insbesondere wird die Linie zwischen AA und AAA nicht sauber genug gezogen. Warum wäre das wichtig gewesen?

Die Erfolgskriterien der WCAG sind den drei Stufen A, AA und AAA zugeordnet. Auf Stufe AAA sind Erfolgskriterien angesiedelt, die für viele Menschen mit Behinderungen sehr wichtig sind, aber nicht mit jedem Webinhalt (z.B. Artikel, Fachartikel, Fachbücher und Gesetze) erreicht werden (können). So dürfen etwa aus urheberrechtlichen Gründen oft nicht nachträglich Zwischenüberschriften in Artikel eingefügt werden und natürlich ist illusorisch, dass jeder Autor Zwischenüberschriften für Abschnitte verwendet oder Abkürzungen mindestens bei erstmaliger Nennung auflöst bzw. erklärt. Auch das Verwenden einer einfacheren Sprache kann nicht durchgehend gesichert werden und nicht immer kann gewährleistet werden, dass Autoren oder generell Anbieter von Webinhalten Nutzer auf Erklärungen für ungewöhnliche Wörter verweisen. Diese beispielhaft genannten Aspekte fördern die Barrierefreiheit für viele Nutzer, aber können eben nicht durchgehend sichergestellt werden – einer der Hauptgründe, warum sie auf Stufe AAA der WCAG liegen und nicht auf Stufe AA. Auch findet sich in den Konformitätsbedingungen der WCAG – im Buch fiel mir die Note nicht auf – die folgende Note:

„It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.”

Die in Europa für den öffentlichen Dienst relevante EU-Richtlinie 2016/2102 und der europäische Standard EN 301 549 folgen dieser Note. Die im Buch mehrfach kritisch aufgegriffenen AAA-Erfolgskriterien befinden sich im EN 301 549 nur im Annex D und sind nicht Teil der Mindestanforderungen. Dass sie über abgeleitete Normen, Verordnungen oder Gesetze „zwingend“ und verbindlich werden scheint mir kein realistisches Szenario.

Dass meist nur AA verlangt wird, wird zwar erwähnt, geht aber durch das häufige und teils auch plakative Aufgreifen von AAA-Erfolgskriterien unter. Gerade im Unterkapitel 5.3 über gesetzliche Grundlagen, Normen und Standards wäre ergänzend zur Information, dass der Europäische Standard auf WCAG 2.1 verweist, die Nennung der Stufe AA als Mindeststandard wichtig gewesen. Dies insbesondere, weil sich im darauf folgenden Unterkapitel 5.4. Abschnitte und rhetorische Fragen befinden, die sich eigentlich nur auf AAA beziehen können, und zwar „Was machen Sie beispielsweise, wenn eine berühmte Fachkoryphäe ihren Text nicht WCAG-konform verfasst hat?“ oder auch „Können Gesetze rechtssicher und WCAG-konform verfasst werden?“ (beides Seite 119). Können solche Inhalte keine „vollständige Konformität“ (Seite 118) erreichen? Das mag der Fall sein, wenn man darunter auch AAA fasst, was aber zu kurz – oder besser zu weit – greift. WCAG-Konformität bedeutet nicht automatisch AAA-Konformität. Es gibt quasi drei vollständige Konformitäten (konform mit A, konform mit AA, konform mit AAA). Nötig wäre hier eine differenziertere Darstellung gewesen – gerade für Leser, die in das Thema der digitalen Barrierefreiheit einsteigen und mit existierenden Standards nicht oder kaum vertraut sind.

Auch sind im Buch aufgegriffene WCAG-Erfolgskriterien nicht immer fehlerfrei beschrieben und zugeordnet. So wird – anders als auf Seite 86 gesagt – kein Verzicht auf ungewöhnliche Wörter verlangt. Die mehrfach kritisch beleuchteten Zwischenüberschriften sind kein AA-Erfolgskriterium (u.a. Seite 90), sondern ein AAA-Erfolgskriterium. Richtig sind Zuordnung und Beschreibung dann in einem der späteren Praxiskapitel (Seite 271). Kurz zur Erläuterung: Erst auf Stufe AAA der WCAG werden tatsächlich Zwischenüberschriften / Abschnittsüberschriften (Section Headings) erwartet. Für AA und damit für die Umsetzung der EU-Richtlinie ist ausreichend, wenn Überschriften und Beschriftungen Thema und Zweck eines Inhalts vermitteln. Explizite Abschnittsüberschriften werden für AA nicht erwartet. Natürlich sind Zwischenüberschriften nicht überflüssig, aber verbindlich sind sie vor dem Hintergrund der EU-Richtlinie, dem europäischen Standard oder der BITV 2.0 nicht.

Auch an anderen Stellen haben sich Ungenauigkeiten und Fehler eingeschlichen:

Die vier Prinzipien der WCAG (wahrnehmbar, bedienbar, verständlich, robust) werden kurz erläutert (Seite 88f.) und – sehr kurz – die drei Konformitätsstufen (Seite 89 f.). In der Beschreibung der vier Prinzipien wurden die Auszeichnung anderssprachiger Inhalte und Auszeichnung der Hauptsprache – Aspekte der Verständlichkeit für Screenreadernutzer, damit Texte mit der richtigen Betonung vorgelesen werden – dem Prinzip „robust“ zugeordnet. Das lässt sich aufgrund der geringen Relevanz für die tägliche Praxis der Dokumenterstellung verschmerzen. Auch manch Ungenauigkeit lässt sich verschmerzen, etwa wenn auf Seite 184 die genannten Erfolgskriterien als „Richtlinien“ bezeichnet werden.

Die beiden als „Probleme“ für die Anwendung der WCAG auf das PDF-Format aufgeführten Beispiele (Seite 91) verdienen eine etwas nähere Betrachtung:

• Bei der Beschreibung des Erfolgskriteriums 1.4.4 handelt es sich um eine Fehlinterpretation. Das AA-Erfolgskriterium 1.4.4 erlaubt für die Konformität einen waagerechten Scrollbalken, daher ist hier anders als dargestellt kein Umbrechen von Inhalten bei Vergrößerung gefordert. Das ergibt sich daraus, dass erst im Erfolgskriterium 1.4.8 und damit für AAA im Listenpunkt 5 explizit aufgeführt wird, dass bei 200% Vergrößerung kein waagerechter Scrollbalken entstehen darf. (Auf das neue Reflow-Kriterium der WCAG 2.1 gehe ich unten kurz ein.)
• Dass sich „verhältnismäßig einfach“ bei HTML Schriftarten an individuelle Bedürfnisse anpassen lassen und bei PDF „jedoch nicht“ ist natürlich völlig richtig. Die kritische Einschätzung hinsichtlich der Anwendung der WCAG auf PDF verfängt jedoch nicht, da in den WCAG keine Anpassbarkeit von Schriftarten gefordert ist. Leider gibt es keinen Verweis. Daher ist unklar, auf was sich bezogen wird.

Wenige Tage vor Erscheinen des Buches wurde die deutsche BITV 2.0 aktualisiert. Daher war der Abschnitt zur BITV bei Veröffentlichung des Buches veraltet. Es sollte verlagsseitig erwogen werden, Leser durch einen Einleger zu informieren.

Dennoch ein paar Worte zur Version der BITV 2.0 vor ihrer Aktualisierung Ende Mai dieses Jahres: Dass die Bedingungen der Priorität 1 erfüllt werden mussten und die der Priorität 2 erfüllt werden konnten (Seite 106), trifft nicht den Kern. Die Priorität 2 (AAA-Kriterien, mit einigen inhaltlichen Abweichungen) galt für sogenannte „zentrale Einstiegs- und Navigationsangebote“; das sind PDF-Dokumente regelmäßig nicht. Auch das Gros der Websites inkl. der dort vorhandenen Inhalte fällt nicht darunter. Dass auf Priorität 1 der „Einsatz von Überschriften zur Themeneinteilung verlangt“ worden wäre (Seite 107) ist unzutreffend. Da die BITV 2.0 hier den WCAG folgte waren Abschnittsüberschriften eine Bedingung der Priorität 2.

Ein Szenario, nach dem ein „Professor Doktor“ wegen einer Verordnung zur Barrierefreiheit einen Fachaufsatz hätte umschreiben müssen (Seite 107) irritiert daher. Wenn Autoren in Aufsätzen oder Artikeln Abkürzungen ohne Erläuterungen verwenden möchten, dann ‚dürfen‘ sie das in unbegrenzter Zahl. Wenn sie ungewöhnliche Wörter (z.B. Metaphern, selbst erfundene Begriffe oder oder) ohne Verweise auf Definitionen verwenden wollen, dann ‚dürfen‘ sie das auch. Sie ‚dürfen‘ so kompliziert schreiben, wie sie möchten, und alles ohne Abschnittsüberschriften. Dem können interne Redaktionsrichtlinien entgegenstehen, aber weder die alte noch die neue BITV (noch die EU-Richtlinie) würden dies verbieten oder hätten das verboten. Schon der Abschnitt auf Seite 69 verwundert, wo es heißt:

„(…) Verbindliche Anforderungen an den Inhalt für alle Publikationen sollte es im engeren Sinne nicht geben (…) Menschen aufgrund von vielleicht sogar rechtsverbindlichen Anforderungen an barrierefreie Zugänge flächendeckend vorzuschreiben, was und wie sie zu schreiben haben, ist zum einen einfach praxisfern und kann zum anderen nach meinem Dafürhalten gegen das Recht auf Meinungsfreiheit verstoßen.“

Den WCAG-Techniken ist ein kurzer Abschnitt gewidmet, der etwas mehr „Futter“ hätte vertragen können (Seite 90). WCAG-Techniken sind – wie hier richtig gesagt – keine Umsetzungsvorgaben oder Anforderungen, sondern optionale Umsetzungshilfen. Man kann sich daran orientieren, muss es aber nicht. Auf Seite 107 werden sie jedoch als „normative Bestandteile der WCAG, z.B. die Techniken zu HTML, CSS, PDF (…)“ bezeichnet, was widersprüchlich und mithin nicht korrekt ist. Nicht erwähnt wird, dass auch General Techniques für PDF optional anwendbar sein können.

Die Kritik an geringem Umfang oder fehlender Aktualität der PDF-Techniken kann man leicht teilen. Allerdings können auf einfache Weise Techniken eingereicht werden und z.B. PDF/UA-Techniken für ein Review durch die Working Group beim W3C vorgelegt werden. Dass das bis dato nicht passiert ist, ist aus meiner Sicht das eigentliche Ärgernis. Denn das Verhältnis zwischen PDF/UA und WCAG ist alles andere als ausreichend geklärt. Schaut man in die relevante Mailingliste waren potenzielle PDF/UA-Techniken für WCAG im September 2012 kurz Thema. Die Working Group beim W3C antwortete damals: „We think documenting techniques from PDF/UA is a useful approach. Please do submit such techniques for consideration (…) We look forward to reviewing them.” Dass sich inzwischen eine externe Arbeitsgruppe zusammengefunden hat, trägt hoffentlich zur überfälligen Klärung bei.

(Persönlich bin ich der Meinung, dass man das Thema „Techniken“ nicht so hoch hängen sollte. Entscheidender ist, welcher PDF/UA-Fehler auch ein Fehler im Sinne der WCAG und damit der EU-Richtlinie ist. Gerade angesichts der vielfältigen Wege zum PDF (u.a. aus Word heraus über „speichern unter“) ist das für tägliche Praxis alles andere als unwichtig).

Sehr gut dargestellt wird, dass es „nicht immer PDF sein muss“ (Seite 55 bis 60). Auf mehreren Seiten werden „Mythen“ behandelt, die sich um das Thema „Barrierefreie Dokumente“ gerankt haben – ein wichtiger einleitender Abschnitt (Seite 62-68). Hier stößt man mit dem Adobe Umfließen auf ein echtes Reizthema. Das Adobe Umfließen ist ein Vergrößerungsmodus des Adobe Readers, bei dem bei Vergrößerung Inhalte umbrechen und man als sehbehinderter Mensch bei starkem Vergrößerungsbedarf beim Lesen eines PDF nicht ständig waagerecht scrollen muss. Er taucht mal mehr und mal weniger direkt in Musterausschreibungen auf, lässt sich aber als Verpflichtung von keinem Standard und keiner Verordnung ableiten – wie im Buch auch sehr richtig geschrieben. Das Adobe Umfließen ist ein Ärgernis für alle, denn sehr berechtigte Forderungen sehbehinderter Nutzer treffen auf die im Buch nicht mal abschließend beschriebenen Unzulänglichkeiten und Fehler des verbreitetsten PDF-Readers.

Bisher war auf Stufe AA kein Umbrechen von Inhalten gefordert. Mit dem neuen Erfolgskriterium „Reflow“ (mit definierten Ausnahmen) der WCAG 2.1 wurden die AA-Karten neu gemischt. Wichtig: Auch dieses sieht für die Konformität nicht speziell den Adobe Reflow vor. Man wird sehen, wohin die Diskussion und vor allem die Umsetzungsreise hier gehen wird. Leider wird das neue Reflow-Erfolgskriterium im Buch nicht erwähnt, was an der Fehlinterpretation von 1.4.4 liegen könnte.

Welche Anforderungen an barrierefreie Dokumente sind in den WCAG und in PDF/UA deckungsgleich? Wo sind sie ähnlich, aber nicht deckungsgleich? Wo sind die Unterschiede? Welche Anforderungen von PDF/UA gelten auch für die WCAG und damit für die Europäische Richtlinie 2016/2102? Welche PDF/UA-Fehler sind auch WCAG-Fehler – und welche nicht? Dokumentersteller wollen (oder müssen) einfach nur ein barrierefreies Dokument erstellen; Auftraggeber müssen wissen, wann ein Dienstleister „richtig“ gearbeitet hat und was das eigentlich wann bedeutet. Das wird hoffentlich alles klarer, wenn die erwähnte externe Arbeitsgruppe ihre Ergebnisse für Reviews beim W3C einreicht und diese durch die üblichen W3C-Prozesse gegangen sind.

Natürlich gibt es gemeinsame Aspekte der Zugänglichkeit. Dazu gehören u.a. semantisch korrekte Tags, eine sinnstiftende Tag-Reihenfolge oder, dass informative Bilder beschrieben sind – eine nicht abschließende Liste. Andere Aspekte sind aktuell noch nicht geklärt. Wieder andere sind ähnlich, aber nicht deckungsgleich. Das Erstellen einer Checkliste mit gemeinsamen „Anforderungen an barrierefreie Dokumente nach PDF/UA und WCAG“ (Seite 251) ist aktuell kein leichtes Unterfangen. Herausgreifen möchte ich drei in der Checkliste auf Seite 251 genannte „Anforderungen“: „Einbetten von Schriften“, Auszeichnung des Sprachwechsels und „Lesezeichen“:

• PDF/UA sieht verbindlich das „Einbetten von Schriften“ vor. Deklariert wurde dies im Buch auch als WCAG-Anforderung, was im indirekten Widerspruch zu einer späteren Aussage im Office-Kapitel steht. Im Office-Kapitel wird (richtigerweise) gesagt, dass bei nicht-eingebetteten Schriften in der Regel keine Probleme der Barrierefreiheit entstehen. Die WCAG adressieren jedoch nur und ausschließlich Aspekte, die die Barrierefreiheit / Zugänglichkeit für Menschen mit Behinderungen betreffen. Es ist daher fraglich, ob sich diese PDF/UA-Anforderung als WCAG-Anforderung tatsächlich halten lässt. In jedem Fall wäre eine Kennzeichnung als Interpretation positiv gewesen.
• „Die verwendete Sprache muss auf Dokumenten- und Zeichenebene hinterlegt sein“ wurde als Anforderung beider Standards deklariert. Zwar sehen beide die Auszeichnung anderssprachiger Inhalte vor, aber bzgl. des ausreichenden Umfangs gibt es Unterschiede. Nach WCAG ist die Auszeichnung anderssprachiger Wortgruppen ausreichend (und wird so auch von vielen Screenreadernutzern empfohlen); nach PDF/UA nicht. Hier wäre ein kurzer Text mit Beschreibung der Unterschiede positiv gewesen. Ich erlaube mir zur Vertiefung auf einen eigenen Artikel zu verweisen.
• Lesezeichen bieten einen alternativen, schnellen und gezielten Zugriff auf die Inhalte eines Dokuments. Sie fördern Accessibility und Usability und werden oft vertraglich gefordert. Es ist guter Stil, Lesezeichen zur Verfügung zu stellen. Dass jedoch die WCAG Lesezeichen „vorschreiben“ (Seite 241, 251) würden und diese sichtbar sein müssen (Seite 251) lässt sich nicht ableiten. Lesezeichen sind als Technik optional. Das Erfolgskriterium 2.4.5 (Seite 241) ist bereits ausreichend erfüllt, wenn ein Inhaltsverzeichnis vorhanden ist (General Technique 64 zu 2.4.5 Beispiel 2). Schaut man in die Technikenliste von 2.4.5, so wird aktuell (Stand: Juli 2019) als „ausreichend“ angesehen, wenn eine der genannten Techniken umgesetzt wurde. Wenn man zusätzlich zu einem Inhaltsverzeichnis auch Lesezeichen zur Verfügung stellt (oder umgekehrt), dann ist das natürlich positiv, aber keine „WCAG-Anforderung“. Techniken sind nie WCAG-Anforderungen. Dies ist keine übergroße Detailverliebtheit, sondern kann sehr entscheidend sein – und zwar für Konformitätsprüfungen.

In den überleitenden Kapiteln zu den Praxiskapiteln werden Tags und korrekte Tagreihenfolge, Umgang mit Artefakten, Alternativtexte und anderes mehr besprochen und diese sowie darüber hinausgehende Umsetzungen und Vorbereitungen in späteren Kapiteln dann für MS Office, Libre Office und InDesign erläutert. Das Kapitel zur Semantik ist eingängig geschrieben und hätte sogar noch ausführlicher sein können. Korrekte Semantik ist einfach das A und O. Sehr gut hier die Übung zum Erkennen von Überschriften. Der Abschnitt zu Alternativtexten ist ausreichend, enthält aber einen Verweis auf ein gutes Tutorial. Auch die Abschnitte u.a. zu Tabellen und vor allem Formulare bieten viel Wissenswertes.

Über das Thema „Links“ wird hinsichtlich Umsetzung nach WCAG etwas schnell und ungenau „hinweggehuscht“ Hier wäre eine Konzentration nur auf PDF/UA besser gewesen – oder ein detaillierteres Beschreiben. Auch wurde nicht ausreichend beachtet, dass es zwei Erfolgskriterien gibt (eines für A, eines für AAA), wobei in keinem die „Hinterlegung von anderen Informationen als den dargestellten“ (Seite 229) gefordert wäre (möglicherweise hatte man hier eine bestimmte optionale Technik im Blick). Da ich mich mit dem Thema „Links“ nach WCAG und PDF im Rahmen einer Artikelserie näher befasst habe, verweise ich hier darauf.

Das Office-Kapitel ist gut geschrieben und adressiert das Arbeiten mit Word, PowerPoint und Excel sowie ein besonders interessantes und lohnenswertes Kapitel zur Arbeit mit Libre Office. Beschrieben werden die typischen, wichtigen und richtigen Arbeitsweisen – ergänzt durch aussagekräftige Screenshots. Darüber hinaus gibt es sehr praktische Suchen-Ersetzen-Tipps für Word, u.a. für leere Absätze, und damit auch über den Buchgegenstand hinausgehende Tipps, die noch zu wenig bekannt sind. Da es insgesamt recht wenig über Barrierefreiheit mit PowerPoint und Excel gibt und noch weniger zu Libre Office sind das wichtige und auch eingängig geschriebene Kapitel.

Das InDesign-Kapitel bietet Erläuterungen zum Anlegen von möglichst viel Zugänglichkeit direkt in InDesign und wartet zusätzlich mit zahlreichen Tipps, Tricks und praktischen Hinweisen auf. Ausgezeichnet ist die Tabelle auf den Seiten 349 bis 351 mit einer Darstellung der aktuellen Schwächen von InDesign hinsichtlich der Umsetzung von PDF/UA und jeweiligen Lösungswegen in verschiedenen (kostenpflichtigen) Programmen oder auch im Acrobat, wodurch sehr gut die Grenzen des technisch aktuell möglichen in InDesign aufgezeigt werden. Trotz des PDF/UA-Schwerpunktes wären kompakte Hinweise positiv gewesen, welche ein konkretes Problem der Barrierefreiheit für Menschen mit Behinderungen sind und welche nicht. Es ist jedoch – ebenso wie das Office-Kapitel – ein insgesamt gutes, hilfreiches Kapitel für die Praxis.

Wichtiges Credo aller Experten seit Jahren ist, dass Barrierefreiheit nicht vollständig automatisiert geprüft werden kann. Dies wird an mehreren Stellen wiederholt, kann aber nicht oft genug wiederholt werden – gerade angesichts der dereinst anstehenden Konformitätsprüfungen von Webinhalten des öffentlichen Dienstes mit der EU-Richtlinie. Das Kapitel „Prüfung“ und damit das letzte Kapitel des Buches ist wie auch andere Kapitel aus PDF/UA-Perspektive geschrieben, was in der Praxis, der Qualitätssicherung und der Prüfung berücksichtigt werden muss.

Wer vertraglich verpflichtet ist, PDF/UA umzusetzen oder sich auf PDF/UA konzentrieren möchte, der erhält in den letzten beiden Kapiteln viele wichtige Informationen zur Prüfung von PDF/UA-Konformität und für die Nacharbeitung. Vereinzelt finden sich auch Hinweise darauf, welche PDF/UA-Kriterien nach WCAG nicht umgesetzt werden müssen. Ein paar Aspekte finden sich auch eingestreut im Office-Kapitel. Eine vollständige Liste wäre positiv, kann aber schlicht zum aktuellen Zeitpunkt nur ansatzweise erstellt werden, weil die o.g. genannte Arbeitsgruppe noch nichts beim W3C eingereicht hat.

Empfehlenswert? Eingeschränkt empfehlenswert? Nicht empfehlenswert?

Aus eigener Erfahrung und Teil des Autorenteams eines Fachbuchs zum Thema Barrierefreiheit nach WCAG – seinerzeit noch WCAG 2.0 – weiß ich, wie viel Zeit und Arbeit in einem Buch steckt. Gerne hätte ich schon deswegen eine Empfehlung ausgesprochen. Gute bis sehr gute Abschnitte und gute Kapitel (die Office-Kapitel und das InDesign-Kapitel) sowie viele hilfreiche Tipps für ein barrierefreies Publizieren stehen im Kontrast zu den oben beispielhaft angeführten problematischen Aspekten, die sich teils durch das Buch ziehen und nicht nur ein Unterkapitel oder Kapitel betreffen.

Ob man ein Fachbuch bzw. Handbuch in einem ausgeprägten Ich-Stil schreibt mag Geschmackssache sein. Nach meinem Dafürhalten sollten sich jedoch in Fachbüchern (und Handbüchern) eigene Meinungen, Einstellungen und Vorlieben deutlich weniger mit der fachlichen Ebene vermischen, als hier über viele Abschnitte hinweg der Fall. Auch sollten Interpretationen konsequent gekennzeichnet und ggf. über Belege und Querverweise gestützt werden – auch, wenn es sich nicht um ein wissenschaftliches Werk, sondern ein Handbuch handelt.

Die Frage, ob ich eine Lese- oder Kaufempfehlung ausspreche und wenn ja für wen und wenn nein für wen nicht, hat mich lange beschäftigt. Meine Einschätzung ist letztlich:

Nur wer mit dem EU-Standard 301 549 und den WCAG gut vertraut ist, kann die oben nicht abschließend angesprochenen kritischen Aspekte für sich filtern und einordnen und erhält dann einen guten Einblick in die Umsetzung (nicht nur) nach PDF/UA sowie in das Arbeiten mit InDesign und Office sowie manch hilfreichen Tipp und Input. Wer diesen fachlichen Hintergrund hat, der sollte das Buch auch kennen. Für Personen ohne diesen fachlichen Hintergrund sowie Einsteiger in das Thema „Digitale Barrierefreiheit“ kann ich keine Empfehlung aussprechen. Die vorhandenen Fehler und Ungenauigkeiten vermitteln – und das war für mich letztlich entscheidend – keinen adäquaten Einblick in die im Zuge der Harmonisierung von Standards relevanten WCAG und damit letztlich auch nicht in den EU-Standard 301549 und die relevante EU-Richtlinie 2016/2102. Das Grundproblem ist, dass es kein WCAG-Fachkorrektorat gegeben haben kann. Dieses hätte es jedoch geben müssen. Dafür bleibt nun nur noch die Errata-Seite der Website zum Buch, die aber nur ein Bruchteil der Leser aufsuchen wird, oder eine zweite Auflage.