Barrierefreie PDFs: worauf es ankommt, wann HTML besser ist
Viele Websites bieten Speisekarten, Preislisten, Formulare und Broschüren als PDF an. Für Menschen mit Screenreader, Vergrößerung oder nur mit Tastatur ist ein PDF ohne Struktur oft eine verschlossene Tür. Hier steht, was ein PDF barrierefrei macht, was ein Check findet und wann eine Webseite die bessere Wahl ist.
Wann ein PDF zur Barriere wird
Ein PDF kann perfekt aussehen und trotzdem unbenutzbar sein. Ein Screenreader sieht das Layout nicht. Er braucht Struktur: welcher Text eine Überschrift ist, welcher eine Liste, welcher eine Tabelle, und in welcher Reihenfolge alles gelesen wird. Fehlt diese Information, kommt der Inhalt als ein langer Textstrom an, in falscher Reihenfolge oder gar nicht.
Typische Probleme: eine gescannte Seite, die nur ein Bild ist, ein zweispaltiges Layout, das quer über beide Spalten gelesen wird, eine Tabelle ohne Kopfzellen, ein Formular, dessen Felder keinen Namen haben, und Bilder ohne Textalternative. Das W3C beschreibt in seinen PDF-Techniken zu WCAG, wie du jedes davon vermeidest. Die Techniken sind Beispiele, wie man WCAG erfüllen kann, keine eigene Pflicht.
Was ein PDF barrierefrei macht
- Tags: Ein getaggtes PDF hat einen Strukturbaum, in dem Überschriften, Absätze, Listen und Tabellen als solche ausgezeichnet sind. Ohne Tags fehlt assistiver Technik fast alles.
- Lesereihenfolge: Die Reihenfolge der Tags bestimmt, was zuerst gelesen wird. Prüfe sie besonders bei Spalten, Textkästen und Randspalten. Die Tab-Reihenfolge von Links und Formularfeldern sollte derselben Logik folgen.
- Dokumenttitel: Setze in den Eigenschaften einen aussagekräftigen Titel und lass ihn statt des Dateinamens anzeigen.
- Dokumentsprache: Setze die Hauptsprache, damit ein Screenreader richtig ausspricht. Kennzeichne Abschnitte in einer anderen Sprache gesondert.
- Alt-Texte für Abbildungen: Informative Bilder bekommen eine Textalternative an ihrem Figure-Tag. Rein dekorative Bilder werden als Artefakt markiert, damit Screenreader sie überspringen.
- Echter Text statt Scan: Eine gescannte Seite ist ein Bild von Text. Erstelle das PDF wenn möglich aus der Quelldatei. Gibt es keine, macht eine Texterkennung (OCR) aus dem Scan echten Text. Prüfe danach, ob der ganze Text da ist und in der richtigen Reihenfolge steht.
- Tabellenköpfe: Datentabellen bestehen aus Tabellen-, Zeilen-, Kopf- und Datenzellen. Kopfzellen müssen als Kopfzellen ausgezeichnet sein, nicht nur fett gedruckt.
- Lesezeichen: Dokumente mit mehr als ein paar Seiten bekommen Lesezeichen, am besten aus den Überschriften erzeugt. So behalten alle den Überblick.
- Formularfelder: Jedes Feld hat einen Namen, der technisch mit ihm verknüpft ist, zum Beispiel über die Quickinfo des Feldes. Eine Beschriftung, die nur daneben gedruckt ist, reicht nicht.
Was ein automatischer Check findet und was nicht
Ein Werkzeug kann technische Eigenschaften auslesen: Gibt es einen Titel, eine Sprache, einen Strukturbaum, haben Abbildungen einen Alt-Eintrag? Das sind gute erste Fragen, und eine fehlende Antwort ist ein klarer Befund.
Ein Werkzeug kann nicht beurteilen, ob ein Alt-Text das Richtige sagt, ob die Lesereihenfolge sinnvoll ist, ob die richtigen Zellen als Kopfzellen markiert sind oder ob die Texterkennung jede Zahl richtig gelesen hat. Das W3C sagt es deutlich: Prüfwerkzeuge können Barrierefreiheit nicht feststellen, sie können nur dabei helfen, und es braucht menschliches Urteil. Vier Prüfungen von Hand dauern nur ein paar Minuten:
- 1Öffne das PDF. Zeigt das Fenster einen echten Titel statt des Dateinamens?
- 2Hör dir die ersten Seiten mit einem Screenreader oder einer Vorlesefunktion an. Werden Überschriften, Spalten und Tabellen in sinnvoller Reihenfolge gelesen?
- 3Speichere das PDF als Text. Ist der ganze Text da, in der richtigen Reihenfolge, und stimmen die Zahlen?
- 4Geh mit der Tab-Taste durch Links und Formularfelder. Ist die Reihenfolge sinnvoll, und nennt jedes Feld seinen Namen?
Wann eine HTML-Seite die bessere Wahl ist
Frag dich, was Besucher mit dem Inhalt tun wollen. Öffnungszeiten, Speisekarten, Preislisten, kurze Anleitungen und alles, was sich oft ändert, funktioniert meist besser als normale Webseite. Eine Seite passt sich kleinen Bildschirmen und der Vergrößerung an, lässt sich direkt finden und verlinken, und du hältst nur eine Fassung aktuell.
Ein PDF ist weiter sinnvoll für Dokumente, die man druckt, unterschreibt oder ablegt oder die ein festes Layout behalten müssen. Behältst du das PDF, biete die wichtigsten Inhalte zusätzlich als Webseite an, oder sorge mindestens dafür, dass das PDF getaggt und geprüft ist.
Mit Do4U arbeiten
Das Werkzeug PDF-Barrierefreiheit prüfen liest ein PDF bis 2 MB und meldet Titel, Sprache, Strukturtags und Abbildungen ohne Alternative. Die Lesereihenfolge ist immer zur manuellen Prüfung markiert, weil ein Werkzeug sie nicht beurteilen kann.
Dokumente in HTML umwandeln erstellt einen Entwurf aus jeweils einer PDF-Seite oder einem Bild: semantisches HTML mit Überschriften, Listen und Tabellen sowie Klartext. Prüfe jedes Wort, jede Zahl und jede Tabelle am Original und wiederhole den Auftrag für jede Seite in Lesereihenfolge.
Beide Werkzeuge liefern Befunde und Entwürfe. Sie ersetzen keine Prüfung durch Menschen, am besten auch durch jemanden, der einen Screenreader nutzt. Prüfe nach jeder neuen Fassung des Dokuments noch einmal.
Quellen
- W3C: Techniques for WCAG 2.2, PDF-Techniken PDF1 bis PDF23 (englisch) (www.w3.org)
- W3C: PDF3, richtige Tab- und Lesereihenfolge in PDF-Dokumenten (englisch) (www.w3.org)
- W3C: PDF7, Texterkennung (OCR) für gescannte PDFs (englisch) (www.w3.org)
- W3C: PDF6, Tabellenelemente in PDF-Dokumenten (englisch) (www.w3.org)
- W3C WAI: Werkzeuge zur Prüfung der Barrierefreiheit auswählen (englisch) (www.w3.org)