PDFs auf der Website: das übersehene Drittel

Fast jede Unternehmenswebsite verteilt PDFs. Preislisten, Datenblätter, Anmeldeformulare, Speisekarten, Wartungsverträge, Jahresberichte. Sie stehen als Download-Link auf der Seite, und in der Diskussion über Barrierefreiheit kommen sie fast nie vor.

Dabei gilt für sie dasselbe wie für die Website: Ein PDF, das ein Screenreader nicht vorlesen kann, ist für einen Teil deiner Kunden nicht vorhanden. Und der Anteil unzugänglicher PDFs ist deutlich höher als der Anteil unzugänglicher Webseiten — weil bei PDFs nie jemand hinschaut.

Die erste Frage: muss es überhaupt ein PDF sein?

Bevor es um Technik geht, die wichtigste Entscheidung.

Die Faustregel lautet: Wo es geht, HTML statt PDF. Eine normale Webseite ist barrierefreier, besser auffindbar, auf dem Telefon lesbar und lässt sich pflegen, ohne jedes Mal ein Dokument neu zu erzeugen.

Was gegen PDF auf einer Website spricht:

• Es ist eine Sackgasse. Wer im PDF gelandet ist, kommt schlecht weiter. Verlinkung nach vorn ist umständlich, und responsives Verhalten gibt es praktisch nicht — ein A4-Layout auf einem Telefon bleibt ein A4-Layout.
• Es taucht in der Auswertung nicht auf. Übliche Analysewerkzeuge können nicht verfolgen, was im PDF passiert.
• Es wird selten aktualisiert. Weil die Änderung im Ursprungsdokument gemacht, neu exportiert und neu hochgeladen werden muss, stehen auf vielen Websites PDFs mit Preisen von vorgestern.

Wofür PDF hingegen richtig ist:

• Dokumente, die überall exakt gleich aussehen müssen.
• Dokumente, die unverändert bleiben sollen — Rechnungen, unterschriebene Verträge, Bescheinigungen.
• Alles zum Ausdrucken.

Die Speisekarte, die Leistungsübersicht und die Anfahrtsbeschreibung gehören auf eine Seite. Der Wartungsvertrag darf ein PDF sein.

(Rheinwerk, Barrierefreie Webseiten, Kap. 11.1)

Was ein PDF zugänglich macht: Tags

Ein PDF ist ohne Weiteres nur eine Anordnung von Zeichen auf einer Fläche. Dass eine Zeile ganz oben steht und größer ist, macht sie nicht zu einer Überschrift — sie ist nur größer.

Die Bedeutung kommt über Tags. Das sind Strukturangaben im Dokument, die genau die Rolle spielen, die HTML-Elemente auf einer Webseite spielen: Diese Zeile ist eine Überschrift erster Ebene, dieser Block ist ein Absatz, das hier ist eine Liste mit vier Einträgen, das ist eine Tabelle mit einer Kopfzeile.

Die wichtigsten Tags, wenn man sie einmal gesehen hat, sind vertraut:

Bereich	Tags
Überschriften	<H1> bis <H6>
Text	<P> Absatz, <Span> Textabschnitt, <Quote> Zitat, <Note> Fußnote
Listen	<L> Liste, <LI> Eintrag, <Lbl> Beschriftung, <LBody> Inhalt
Tabellen	<Table>, <TR> Zeile, <TH> Kopfzelle, <TD> Datenzelle
Sonstiges	<Figure> Grafik, <Link> Verweis, <Form> Formularfeld

Der schnellste Test überhaupt: Öffne das PDF, geh in die Dokumenteigenschaften und schau nach dem Eintrag „PDF mit Tags". Steht dort Nein, ist das Dokument nicht barrierefrei. Punkt. Alles Weitere erübrigt sich dann erst mal.

Der zweitschnellste Test: Such im PDF nach einem Wort, das du auf der Seite siehst. Kommt „Keine Übereinstimmung" zurück, ist der Text kein Text, sondern ein Bild — ein Scan oder eine als Grafik platzierte Textfläche. Für einen Screenreader ist das Dokument dann komplett leer. Das kommt bei eingescannten Formularen und alten Prospekten sehr häufig vor.

(Rheinwerk, Barrierefreie Webseiten, Kap. 11.2 und 11.4)

Der Standard dahinter

Was die WCAG für Webinhalte sind, ist PDF/UA für PDF-Dokumente — festgehalten in der Norm ISO 14289. Die aktuelle Fassung UA-2 stammt von März 2024.

Vier Kernforderungen:

• Auszeichnung. Das Dokument muss Struktur-Tags enthalten.
• Navigation. Es muss Navigationshilfen bieten — Lesezeichen, Verweise — damit man sich nicht linear durcharbeiten muss.
• Alternativtexte. Alle Nicht-Text-Elemente brauchen eine Textalternative.
• Interoperabilität. Das Dokument muss mit unterschiedlicher Software und Hardware funktionieren.

Ein Punkt aus EN 301 549, den man kennen sollte: Kapitel 5 verlangt, dass Barrierefreiheitsinformationen bei einer Umwandlung erhalten bleiben. Wenn also eine Website ein PDF live erzeugt — ein Datenblatt aus den Produktdaten, eine Rechnung, eine Bestätigung —, dann müssen Überschriften, Tabellen und Bilder im erzeugten PDF weiterhin ausgezeichnet sein.

Das trifft genau die Fälle, an die niemand denkt: die automatisch erzeugte Auftragsbestätigung, das dynamisch generierte Angebot. Für separat erstellte Download-PDFs greift dieses spezielle Kriterium nicht — zugänglich sein sollten sie trotzdem.

(Rheinwerk, Barrierefreie Webseiten, Kap. 11.1)

Wie ein zugängliches PDF entsteht

Der wichtigste Satz zuerst: Es entsteht im Ursprungsdokument, nicht nachträglich.

Word, PowerPoint und InDesign erzeugen die passenden Tags automatisch — wenn im Dokument sauber gearbeitet wurde. Ein völlig unstrukturiertes PDT nachträglich zu reparieren, ist mühsam, und die automatische Auszeichnungsfunktion von Acrobat liefert in der Praxis schlechtere Ergebnisse als die Erzeugung aus dem Ursprungsprogramm.

Was das für die Arbeit in Word konkret heißt:

Formatvorlagen benutzen, nicht formatieren. Eine Überschrift wird über die Formatvorlage „Überschrift 1" gesetzt, nicht dadurch, dass man den Text fett und größer macht. Nur die Formatvorlage erzeugt später das <H1>-Tag. Die Tastenkürzel dafür sind Alt+1, Alt+2, Alt+3, und Strg+Umschalt+N für Standardtext.

Wie im Web gilt: keine Ebene überspringen.

Keine leeren Absätze. Ein Seitenumbruch wird mit Strg+Enter gesetzt, nicht durch fünfzehnmal Enter. Leere Absätze werden vom Screenreader als „leer, leer, leer …" vorgelesen — im schlimmsten Fall nimmt der Zuhörer an, das Dokument sei zu Ende. Bestehende leere Absätze lassen sich über Suchen und Ersetzen entfernen: ^p^p suchen, ^p ersetzen, alle ersetzen.

Nichts Wichtiges in Kopf- und Fußzeile. Sie werden bei der PDF-Umwandlung vor Screenreadern verborgen, damit sie den Lesefluss nicht auf jeder Seite unterbrechen. Was dort steht, kommt nicht an.

Alternativtexte an Bildern, kurz — maximal etwa 150 Zeichen, weniger ist besser. Dekorative Bilder lassen sich in Word 365 über „Als dekorativ markieren" ausnehmen.

Sprechende Linktexte. Nicht „mehr", nicht die nackte URL. Word wandelt eingetippte Adressen automatisch in Verweise um, und der Screenreader liest dann die vollständige Adresse Zeichen für Zeichen vor. Über Rechtsklick, Link bearbeiten, lässt sich der angezeigte Text ändern.

Tabellen mit Kopfzeile. Die Kopfzeile muss ausdrücklich als solche festgelegt sein, sonst kann der Screenreader keine Beziehung zwischen Wert und Bedeutung herstellen. Hat die Tabelle zusätzlich eine Merkmalsspalte links, gehört auch „Erste Spalte" aktiviert. Sinnvoll ist außerdem, das Umbrechen von Zeilen über Seitengrenzen abzuschalten.

Und ein Grundsatz dazu: Keine Tabellen fürs Layout. Eine Adresse gehört nicht in eine Tabelle, nur damit sie ordentlich untereinandersteht.

Dokumenttitel setzen. Der Screenreader sagt ihn als Erstes an. In Word unter Datei, Informationen. Ein Dokument mit dem Titel „Dokument1" ist eine verpasste Gelegenheit — auch für die Auffindbarkeit.

Dokumentsprache setzen. Sonst wechselt der Screenreader unter Umständen in die falsche Aussprache. Einzelne fremdsprachige Passagen lassen sich gesondert kennzeichnen — aber nicht für einzelne Wörter, weil der Sprachwechsel jedes Mal eine störende Pause erzeugt.

Farbe nicht als einziges Mittel. Derselbe Grundsatz wie im Web. Ein guter Test dafür: Würde die Information einen Schwarzweiß-Ausdruck überleben?

Die eingebaute Prüfung laufen lassen. Word hat eine Barrierefreiheitsprüfung unter „Überprüfen" beziehungsweise „Datei, Informationen, Auf Probleme überprüfen". Sie listet die wichtigsten Punkte, springt auf Klick zur Fundstelle und bietet Lösungen an.

(Rheinwerk, Barrierefreie Webseiten, Kap. 11.3)

Der Export — hier geht es am häufigsten kaputt

Das ist der Punkt, an dem monatelange saubere Arbeit in einer Sekunde verlorengeht.

Beim Speichern als PDF aus Word gibt es zwei Optionen:

• Standard (Onlineveröffentlichung und Drucken) — richtig.
• Minimale Größe (Onlineveröffentlichung) — falsch. Diese Einstellung erzeugt keine Tags. Sämtliche Strukturinformation ist weg.

Der Name der falschen Option klingt harmlos und wird deshalb häufig gewählt, gerade wenn jemand die Datei klein halten will. Zur Sicherheit lässt sich zusätzlich in den Optionen prüfen, ob „Dokumentstrukturtags für Barrierefreiheit" aktiviert ist.

Merksatz: Wer „minimale Größe" wählt, hat gerade alles verloren, was er vorher aufgebaut hat.

Wie du ein PDF prüfst

PAC — der PDF Accessibility Checker. Kostenlos von axes4, für Windows. Er prüft gegen die Kriterien des Matterhorn-Protokolls, dazu wahlweise gegen WCAG. Etwa zwei Drittel der Kriterien werden automatisch geprüft, ein Drittel bleibt manuelle Arbeit.

PAC hat außerdem eine Screenreader-Vorschau — sie zeigt, was ein Screenreader aus dem Dokument macht. Das ist die aufschlussreichste Ansicht überhaupt, weil man sofort sieht, ob die Reihenfolge stimmt.

Was PAC nicht kann: Fehler beheben. Korrigiert wird im Ursprungsdokument oder in Adobe Acrobat Pro.

Der Online-Prüfer von axes4 unter check.axes4.com funktioniert ohne Installation. Bei vertraulichen Dokumenten ist das Hochladen allerdings zu bedenken.

Adobe Acrobat Pro hat eine eigene Prüfung und einen Assistenten, der durch die Einstellungen führt. Er erkennt Text per Texterkennung, setzt Tags, ergänzt Alternativtexte und erlaubt vor allem, die Vorlesereihenfolge zu ändern, ohne das Aussehen anzutasten. Acrobats Prüfung deckt aber nicht den vollen Umfang des Matterhorn-Protokolls ab.

Was keine Maschine prüfen kann: ob ein Alternativtext sinnvoll ist, ob die Vorlesereihenfolge dem entspricht, was gemeint war, ob eine Tabelle die richtigen Tags hat. Vom Matterhorn-Protokoll mit seinen 31 Prüfschritten und 136 Fehlerbedingungen sind 87 maschinell erkennbar, 47 brauchen menschliches Urteil.

Der Anteil ist bemerkenswert ähnlich zu dem bei Webseiten — und er ist der Grund, warum ein grünes Prüfergebnis kein Beweis für ein zugängliches Dokument ist.

(Rheinwerk, Barrierefreie Webseiten, Kap. 11.4)

Zwei Randthemen mit praktischen Folgen

Schutz und Screenreader. PDFs lassen sich umfangreich schützen — Drucken sperren, Kopieren sperren, Verschlüsselung. Wichtig dabei: Der Textzugriff für Screenreader muss erlaubt bleiben. Wird er mitgesperrt, ist das Dokument für blinde Nutzer vollständig unzugänglich, egal wie sauber es ausgezeichnet ist. Das ist eine einzelne Einstellung, die gern versehentlich mit abgeschaltet wird.

Gescannte Dokumente. Ein Scan ist ein Bild. Er wird erst durch Texterkennung zu Text. Danach gehört die Erkennung kontrolliert — Texterkennung produziert Fehler, und ein Screenreader liest sie vor, ohne dass jemand es merkt. Bei Formularen und Dokumenten mit Zahlen ist das ein echtes Problem.

Was zu tun ist

Mach eine Bestandsaufnahme. Wie viele PDFs liegen auf deiner Website? Bei den meisten Kunden ist die Antwort deutlich höher als geschätzt — es sammelt sich über Jahre an.

Sortier sie in drei Stapel:

1. Kann weg. Veraltete Preislisten, Prospekte von 2019, Formulare, die niemand mehr braucht. Der billigste Fortschritt in diesem Feld.
2. Gehört auf eine Seite. Alles, was eigentlich Webinhalt ist: Leistungsübersichten, Anfahrt, Speisekarten, Öffnungszeiten. Diese Umstellung verbessert Barrierefreiheit, Auffindbarkeit und Handybedienung in einem Zug.
3. Bleibt PDF. Verträge, Bescheinigungen, Formulare zum Ausdrucken, alles mit Unterschrift.

Prüf den dritten Stapel mit PAC. Bei jedem Dokument zuerst: Ist es getaggt? Ist der Text durchsuchbar?

Repariere im Ursprungsdokument. Wenn du die Word-Datei noch hast, ist der Weg klar: Formatvorlagen setzen, Alternativtexte ergänzen, Tabellenkopf festlegen, richtig exportieren. Wenn du sie nicht mehr hast, ist Neuerstellen oft schneller als Reparieren.

Und für die Zukunft: Wenn dein Betrieb regelmäßig Dokumente veröffentlicht, ist die Word-Vorlage der Hebel. Eine einmal sauber aufgesetzte Vorlage mit definierten Überschriftenebenen sorgt dafür, dass jedes künftige Dokument die Struktur automatisch mitbringt. Das ist eine Stunde Arbeit und danach für immer erledigt.

Der Bund stellt dazu eine ausführliche Handreichung für barrierefreie Dokumente bereit, die neben Word auch PowerPoint und InDesign abdeckt.

Quellen

• Rheinwerk, Barrierefreie Webseiten, Kap. 11.1 (Warum PDFs barrierefrei sein müssen) — PDF als ISO 32000 und ISO 32000-2, die Vor- und Nachteile von PDF einschließlich Sackgassen-Eigenschaft und fehlender Auswertbarkeit, die Faustregel HTML vor PDF, das Speisekarten-Beispiel, der Hinweis auf Texterkennung bei Scans, PDF/UA als ISO 14289 mit der Fassung UA-2 vom März 2024 und seinen vier Kernforderungen, sowie die Anforderung aus EN 301 549 Kap. 5 Prüfschritt 5.4 zur Erhaltung von Barrierefreiheitsinformationen bei der Umwandlung, mit der Abgrenzung zu separat erstellten Download-PDFs.
• Rheinwerk, Barrierefreie Webseiten, Kap. 11.2 (PDF-Tags) — Tags als Entsprechung der HTML-Semantik, die vollständige Tabelle der Standardtags, der Test über die Dokumenteigenschaft „PDF mit Tags", die Möglichkeit, Sprache je Tag festzulegen, Lesezeichen als Navigationshilfe, das Vorgehen zum Setzen von Alternativtexten in Acrobat und die Kennzeichnung dekorativer Bilder.
• Rheinwerk, Barrierefreie Webseiten, Kap. 11.3 (Schritt für Schritt: barrierefreies PDF mit Word) — die Empfehlung, aus dem Ursprungsprogramm zu erzeugen statt nachträglich auszuzeichnen, Formatvorlagen und die Tastenkürzel Alt+1 bis Alt+3, der Umgang mit Umbrüchen und leeren Absätzen samt der Suchen-und-Ersetzen-Anleitung, der Hinweis auf verborgene Kopf- und Fußzeilen, Alternativtexte mit etwa 150 Zeichen als Obergrenze, sprechende Linktexte und die Autokorrektur von URLs, Tabellenkopfzeile und Merkmalsspalte, das Abschalten des Zeilenumbruchs über Seitengrenzen, Dokumenttitel und Dokumentsprache, der Umgang mit fremdsprachigen Passagen, die Farbregel, die eingebaute Barrierefreiheitsprüfung von Word, und die Exporteinstellungen mit der ausdrücklichen Warnung vor „Minimale Größe".
• Rheinwerk, Barrierefreie Webseiten, Kap. 11.4 (Barrierefreiheit eines PDFs prüfen) — der Suchtest als Hinweis auf Text-als-Bild, das Matterhorn-Protokoll mit 31 Prüfschritten und 136 Fehlerbedingungen, davon 87 maschinell erkennbar und 47 mit menschlichem Urteil, PAC als kostenloses Werkzeug mit etwa zwei Dritteln automatischer Abdeckung und der Screenreader-Vorschau, der Online-Prüfer von axes4, die Möglichkeiten von Adobe Acrobat Pro einschließlich Änderung der Vorlesereihenfolge ohne Änderung des Aussehens, die Aspekte manueller Prüfung, und der Hinweis, beim Schutz von PDFs den Textzugriff für Screenreader zu erlauben.
• Eigene Prüfpraxis — die Drei-Stapel-Sortierung der vorhandenen PDFs, die Beobachtung, dass die Anzahl vorhandener PDFs regelmäßig unterschätzt wird, die Einschätzung, dass Neuerstellen ohne Ursprungsdatei meist schneller ist als Reparieren, und die Empfehlung, die Word-Vorlage als dauerhaften Hebel aufzusetzen.