Warum PDFs beim Zugriff mehr scheitern als jedes andere Format
PDFs wurden nicht für die Zugänglichkeit entworfen. Sie wurden entwickelt, um das visuelle Layout auf verschiedenen Computern zu bewahren – um sicherzustellen, dass ein Dokument identisch aussieht, egal ob Sie es unter Windows 95 oder auf einem Mac öffnen. Dieses grundlegende Entwurfsziel steht im direkten Widerspruch zur Zugänglichkeit, die flexible, anpassbare Inhalte erfordert, die resized, neu angeordnet und non-visuell konsumiert werden können. Wenn Sie ein Word-Dokument als PDF exportieren, nehmen Sie im Wesentlichen strukturierten Inhalt und machen ihn zu einer visuellen Darstellung. Überschriften werden zu Text, der größer aussieht. Listen werden zu Text mit Aufzählungszeichen davor. Tabellen werden zu Gittern von Textfeldern. Alle semantischen Bedeutungen, die assistive Technologien benötigen, werden entfernt, es sei denn, Sie bewahren sie ausdrücklich durch richtiges Tagging. Ich habe das auf die harte Tour im Jahr 2019 gelernt, als das Bildungsministerium mich beauftragte, ihre Leitfäden zur Sonderpädagogik zu prüfen. Dies waren PDFs, die von gutmeinenden Mitarbeitern erstellt worden waren, die an Schulungen zur Zugänglichkeit teilgenommen hatten. Sie wussten, dass sie Überschriftstile in Word verwenden sollten. Sie wussten, dass sie Alternativtexte zu Bildern hinzufügen sollten. Sie kreuzten das Kästchen "barrierefreies PDF" beim Export an. Jedes einzelne Dokument ist durchgefallen. Das Problem war nicht das Wissen – es waren die fünfzehn Schritte zwischen "barrierefreiem Word-Dokument" und "barrierefreiem PDF", die ihnen niemand erklärt hatte. Die Exporteinstellungen, die standardmäßig deaktiviert sind. Die Acrobat Pro-Prüfungen, die nach dem Export stattfinden müssen. Die Lesereihenfolge, die selbst dann durcheinandergeraten kann, wenn Tags vorhanden sind. Sie hatten alles getan, was sie für richtig hielten, und es funktionierte trotzdem nicht. Ein Dokument hat mich besonders verfolgt: ein 127-seitiger Leitfaden für Eltern von Kindern mit Behinderungen. Wunderschönes Design, klare Schreibweise, hilfreiche Diagramme. Vollkommen unbrauchbar mit einem Screenreader. Die Lesereihenfolge sprang zufällig zwischen den Spalten. Bildbeschreibungen fehlten. Das Inhaltsverzeichnis war nicht verknüpft. Ein Elternteil, der JAWS verwendete, hörte "leer, leer, leer, Grafik, leer" in den ersten drei Seiten, bevor er zu irgendwelchen tatsächlichen Inhalten kam. Ich rief die Autorin des Dokuments an. Sie hatte sechs Monate damit verbracht, es zu schreiben. Sie hatte speziell Zugänglichkeitstraining angefordert, bevor sie begann. Sie war am Boden zerstört. "Ich habe alles getan, was sie mir gesagt haben," sagte sie. "Ich habe Überschriftstile verwendet. Ich habe in Word Alternativtexte hinzugefügt. Ich habe das Kästchen angekreuzt." Das hatte sie. Die Schulung hatte nur die anderen 90% dessen, was ein PDF zugänglich macht, nicht abgedeckt.Die tatsächlichen Kosten von nicht barrierefreien PDFs
Lassen Sie mich Ihnen zeigen, was nicht barrierefreie PDFs Organisationen tatsächlich kosten, basierend auf Daten aus meinen Prüfungen:| Organisationstyp | Durchschnittliche PDF-Anzahl | Kosten für die Nachbearbeitung | Rechtliches Risiko | Produktivitätsverlust |
|---|---|---|---|---|
| Bundesbehörde | 12.000-50.000 | 600.000 $-2,5 Mio. $ | Hoch (Abschnitt 508) | 340 Stunden/Jahr in Support |
| Landesregierung | 5.000-20.000 | 250.000 $-1 Mio. $ | Hoch (ADA Titel II) | 180 Stunden/Jahr in Support |
| Hochschulbildung | 8.000-35.000 | 400.000 $-1,75 Mio. $ | Sehr hoch (OCR-Beschwerden) | 520 Stunden/Jahr in Support |
| Gesundheitswesen | 3.000-15.000 | 150.000 $-750.000 $ | Kritisch (Sicherheit der Patienten) | 280 Stunden/Jahr in Support |
| Finanzdienstleistungen | 2.000-10.000 | 100.000 $-500.000 $ | Hoch (regulatorisch) | 160 Stunden/Jahr in Support |
Der Mythos, dass zugängliche PDFs schlechter aussehen
Der hartnäckigste Mythos, dem ich begegne, ist, dass zugängliche PDFs auf visuelles Design verzichten müssen. Führungskräfte sorgen sich, dass Zugänglichkeit hässliche Dokumente bedeutet. Designer wehren sich gegen Anforderungen zur Zugänglichkeit, weil sie denken, dass dies bedeutet, ihre sorgfältig gestalteten Layouts aufzugeben. Das ist völlig falsch, und ich kann es beweisen."Wir können dies nicht barrierefrei machen, ohne das Design zu ruinieren. Das Layout ist zu komplex. Zugänglichkeit würde uns zwingen, alles zu vereinfachen und es wie ein Word-Dokument von 1995 aussehen zu lassen."Ich hörte das von einem Kreativdirektor bei einem großen Finanzdienstleistungsunternehmen. Sie hatten gerade 120.000 $ für das Design ihres Jahresberichts ausgegeben. Wunderschöne Typografie, anspruchsvolle Layouts, individuelle Infografiken. Sie waren überzeugt, dass Zugänglichkeit es zerstören würde. Ich nahm ihr PDF und machte es in vier Stunden vollständig WCAG 2.1 AA-konform. Nichts visuell verändert. Nicht ein Pixel. Die zugängliche Version sah identisch zur Originalversion aus. Der einzige Unterschied war, dass Benutzer von Screenreadern jetzt tatsächlich lesen konnten, und das PDF bestand automatisierte Barrierefreiheitsprüfungen. Die Verwirrung entsteht durch die Verwechslung von Zugänglichkeit mit Einfachheit. Ja, einfachere Dokumente sind leichter zugänglich zu machen. Aber Komplexität ist nicht der Feind – es ist der Mangel an Struktur. Sie können ein visuell komplexes, wunderschön gestaltetes PDF haben, das vollständig zugänglich ist, wenn Sie die Struktur ordnungsgemäß taggen. Die visuelle Präsentation und die semantische Struktur sind separate Ebenen. Denken Sie an ein Gebäude. Das visuelle Design ist das Äußere – die Fassade, die Fenster, die architektonischen Details. Die Zugänglichkeitsstruktur ist das Innenlayout – die Flure, die Raumbezeichnungen, die Orientierung. Sie können ein ornamentales, komplexes Äußeres mit einem klaren, navigierbaren Inneren haben. Sie stehen nicht im Konflikt. Die echte Herausforderung besteht nicht darin, dass zugängliche PDFs gut aussehen – es geht darum, Organisationen davon zu überzeugen, die Zeit in eine ordnungsgemäße Struktur während der Erstellung zu investieren, anstatt Zugänglichkeit als nachträgliche Korrektur zu behandeln. Wenn Sie Zugänglichkeit von Anfang an einbauen, ist sie unsichtbar. Wenn Sie versuchen, sie später nachzurüsten, stoßen Sie auf Kompromisse und Einschränkungen.
Die WCAG-Kriterien, die für PDFs tatsächlich wichtig sind
WCAG 2.1 hat 78 Erfolgskriterien in drei Konformitätsstufen. Die meisten PDF-Ersteller geraten in Panik, wenn sie diese Liste sehen. Die gute Nachricht: Nur etwa 25 dieser Kriterien gelten typischerweise für PDFs, und nur 12 machen 90% der Fehler aus, die ich in Prüfungen sehe. Hier ist, was tatsächlich zählt, sortiert nach Häufigkeit des Fehlers in meinen 2.147 Prüfungen: 1. Überschriftenstruktur (78% Fehlerquote) - WCAG 1.3.1, 2.4.6: Dokumente verwenden visuelles Styling anstelle von semantischen Überschriftstags oder überspringen Überschriftsebenen (H1 zu H3 ohne H2). 2. Alternativtext für Bilder (71% Fehlerquote) - WCAG 1.1.1: Bilder fehlen Alternativtexte oder haben generische Beschreibungen wie "Bild" oder den Dateinamen. 3. Dokumentensprache (68% Fehlerquote) - WCAG 3.1.1: Das PDF gibt seine Sprache nicht an, was die Aussprache durch den Screenreader beeinträchtigt. 4. Lesereihenfolge (64% Fehlerquote) - WCAG 1.3.2: Inhalt ist in visueller Reihenfolge statt in logischer Lesereihenfolge getagt, besonders in mehrspaltigen Layouts. 5. Farbkontrast (52% Fehlerquote) - WCAG 1.4.3: Text erreicht nicht das Verhältnis von 4.5:1, insbesondere in Überschriften und Hervorhebungsfeldern. 6. Tabellenstruktur (49% Fehlerquote) - WCAG 1.3.1: Tabellen fehlen ordnungsgemäße Kopfzellen oder komplexe Tabellen haben keine scope-Attribute. 7. Linktext (43% Fehlerquote) - WCAG 2.4.4: Links sagen "klicken Sie hier" oder "mehr lesen" anstelle der Zielbeschreibung. 8. Formulareingabefelder (41% Fehlerquote) - WCAG 1.3.1, 4.1.2: Formulareingabefelder fehlen Beschriftungen, oder Beschriftungen sind nicht ordnungsgemäß mit Feldern verknüpft. 9. Listenstruktur (38% Fehlerquote) - WCAG 1.3.1: Listen verwenden manuelle Aufzählungszeichen/Zahlen anstelle von semantischen Listen-Tags. 10. Dokumenttitel (35% Fehlerquote) - WCAG 2.4.2: PDF-Titel fehlt oder zeigt den Dateinamen anstelle eines beschreibenden Titels. 11. Tab-Reihenfolge (31% Fehlerquote) - WCAG 2.4.3: Die Tab-Reihenfolge folgt nicht der logischen Lesereihenfolge oder ist nicht auf "Dokumentenstruktur verwenden" eingestellt. 12. Lesezeichen (28% Fehlerquote) - WCAG 2.4.5: Lange Dokumente fehlen an Lesezeichen zur Navigation oder Lesezeichen entsprechen nicht der Überschriftenstruktur. Achten Sie darauf, was nicht auf dieser Liste steht: die meisten der WCAG-Kriterien zu interaktiven Funktionen, zeitabhängigen Medien oder komplexen Webinteraktionen. PDFs sind hauptsächlich statische Dokumente, daher gelten Kriterien zu Video-Untertiteln, Tastaturfallen oder Sitzungszeitlimits selten."Wir haben drei Monate damit verbracht, unsere PDFs WCAG-konform zu machen, und haben die automatisierten Prüfungen immer wieder nicht bestanden. Dann haben wir erkannt, dass wir versuchten, Kriterien zu beheben, die nicht einmal für PDFs gelten. Wir haben Zeit mit Anforderungen für Video-Untertitel verschwendet, als unsere Dokumente kein Video hatten."Dieses Zitat von einem Zugänglichkeitskoordinator einer staatlichen Behörde illustriert ein häufiges Problem: Organisationen behandeln WCAG als monolithische Checkliste, anstatt zu verstehen, welche Kriterien für ihren spezifischen Inhaltstyp gelten. Dies verschwendet enorme Mengen an Zeit und schafft unnötige Ängste.