Fakten und Meinungen zur Barrierefreiheit von PDF

PDF-Dateien im Web sind manchmal nervend und sehr oft unnötig. Sind sie aber weder das eine noch das andere, dann sollten wir sie aus den gleichen Gründen barrierefrei machen, aus denen wir andere Web-Inhalte barrierefrei gestalten.

Im Gegensatz zu der landläufigen Meinung – und auch im Gegensatz zu quasi-richterlichen Behauptungen an manchen Stellen – können PDF-Dokumente genauso barrierefrei sein wie HTML. Auch wenn dies eine schockierende Enthüllung sein mag, so ist sie dennoch wahr. Dieser Artikel erläutert, wie PDF Barrierefreiheit unterstützt oder eben nicht unterstützt.

Zusammenfassung

1. Die meisten PDFs im Web sollten eigentlich HTML sein.
2. Einige Dokumente sollten wirklich PDFs sein.
3. Sie können XML-ähnliche Tags hinzufügen, um einem PDF eine Struktur zu geben.
   1. Tags standen bis zu einer erst seit kurzem verfügbaren Aktualisierung im PDF-Dateiformat nicht zur Verfügung
4. Die am häufigsten verwendeten Screenreader können PDFs lesen.
   1. Screenreader mussten aktualisiert werden um Tags zu verstehen.
   2. Screenreader wurden in ihrer gesamten Geschichte immer wieder aktualisiert und auch heute noch können manche Screenreader Teile der HTML-Spezifikationen nicht verstehen.
5. Ein PDF kann sogar ohne Tags barrierefrei sein, wenn Sie die richtige Technologie anwenden.
6. Ein PDF ohne HTML-Alternative online zu stellen bedeutet nicht automatisch eine Diskriminierung.

Widmungen

Lassen Sie mich diese Diskussion zwei Ländern widmen, die mit Unwahrheiten und Missverständnissen in Bezug auf die Barrierefreiheit von PDFs zu kämpfen haben.

1. Erstens, für die Menschen in Australien, deren staatliche Menschenrechtsorganisation, die Human Rights and Equal Opportunity Commission (HREOC), die offizielle Haltung einnimmt, dass die Veröffentlichung eines Dokumentes nur in Form eines PDFs nicht barrierefrei ist und daher eine Verletzung des Disability Discrimination Act darstellt.

   Ich habe dies auf die harte Tour von Bruce Maguire gelernt. Er bezwang Juan Antonio Samaranch in einer Anhörung mit genau dieser HREOC über die mangelnde Barrierefreiheit der Website zu den olympischen Spielen in Sydney und nun arbeitet er für HREOC. Als ich ihn 2004 getroffen habe, hat Maguire endlose Monologe über dieses Thema geführt. Als ich dann zu Wort kam konnte Maguire mir, wie die meisten von uns, zustimmen, dass HTML das bevorzugte Format ist, aber er schlug auch vor, Microsoft Word als Alternative zum PDF zu benutzen. Das sagt schon alles, was Sie über HREOC's Verständnis von Barrierefreiheit und Interoperabilität wissen müssen.

   Ich habe es Maguire damals gesagt und sage es Ihnen allen heute: Glauben Sie der HREOC nicht, wenn Sie hinter Ihnen her sind und behaupten, dass Ihre PDFs nicht barrierefrei und damit illegal sind. Wenn Sie Ihre PDFs falsch erstellt haben, dann mag HREOC Recht haben, aber auch nur manchmal und es gibt viele Fälle, in denen Ihre PDFs ganz prima sind.

   Wenn Sie wegen »illegaler, nicht barrierefreier« PDFs vor die HREOC geschleppt werden, dann sehen Sie diesen Artikel als Fall für die Verteidigung, um Christopher Hitchens zu umschreiben. (Sehen Sie dazu die Diskussion weiter unten.)

2. Zweitens, für die Menschen in Kanada, wo die Richtlinien der Bundesregierung für ihre eigenen Webseiten – euphemistischerweise bekannt als Common Look and Feel und die Quelle großen Unbills – fälschlicherweise besagen, dass ein PDF »für Personen mit (hauptsächlich) visuellen Behinderungen nicht barrierefrei ist« und dass nur die »Minimalversion 2.1« benutzt werden sollte. Komischerweise gibt es gar keine solche PDF-Version 2.1.

   Die Allianz für die Gleichstellung von blinden Kanadiern (The Alliance for the Equality of Blind Canadians), eine Lobby-Gruppe, die sicher nicht das Kanadische Nationale Institut »für« Blinde ist (Canadian National Institute »for« the Blind), hat während seines jährlichen Treffens 2005 eine Resolution verabschiedet die besagt, dass das Portable Document Format (PDF) weiterhin eine Barriere für blinde, taubblinde und sehbehinderte Menschen und ihre assistiven Technologien darstellt; daher sei beschlossen, dass es die AEBC befürwortet, dass das PDF nicht als Standard benutzt wird, um Dokumente auf allen Webseiten zur Verfügung zu stellen. Tja, wer hat so etwas denn überhaupt vorgeschlagen?

Ein Blick in die Landschaft

Lassen Sie uns am Anfang beginnen und die gesamte PDF-Landschaft im Web diskutieren bevor wir lernen, was ein PDF barrierefrei oder auch nicht barrierefrei macht.

Das Erste, was man mit einem PDF machen sollte

…ist es den URL in Google einzugeben. Ernsthaft. Meistens schafft Google es einigermaßen gut, ein PDF in HTML lesbar zu machen. Schlechte Zeichen-Kodierung, schlecht konstruierte mehrspaltige PDFs und Sicherheitsfunktionen in Dokumenten können dazu führen, dass Google ein PDF überhaupt nicht indiziert oder dies auf unlesbare Art und Weise macht. Trotzdem mache ich dies immer als erstes.

Das PDF-Format wird zu häufig benutzt

Es gibt zu viele PDFs im Web. Die nahezu meisten PDFs sollten ein anderes Format als PDF haben. Jedes einfache Text- und Grafik-Dokument, das einspaltig gesetzt ist, sollte als einfache HTML+CSS+JavaScript-Webseite zur Verfügung gestellt werden. Mir fällt wirklich keine einzige Ausnahme für einfache Dokumente ein.

Es gibt nicht viele Kategorien von Online-Dokumenten, die wirklich im PDF-Format und nicht in irgendeinem anderen Format vorliegen sollten. Und die Liste wurde im letzten Jahr um eine Kategorie reduziert, seitdem Präsentationen nun adäquat von Eric Meyers S5-Methode gehandhabt werden (daher habe ich keine Entschuldigung mehr dafür, meine eigenen Präsentationen im PDF-Format zu veröffentlichen, also werde ich dies auch nicht mehr tun).

Wenn Ihr Dokument aber zu einer der folgenden Kategorien gehört, dann kann das PDF-Format durchaus in Ordnung sein:

1. Dokumente mit Fußnoten, Endnoten oder Randnoten, da es keine Möglichkeit gibt, diese Strukturen in HTML auszuzeichnen. (Sie können einen Hack wie sub oder sup für die Fußnotenreferenz benutzen, aber es gibt keine footnote, endnote, sidenote oder einfach nur note-Elemente. Dieser Hack mag für einfache, mit Fußnoten versehene Dokumente adäquat sein, aber versuchen Sie mal David Foster Wallaces Fußnoten innerhalb von Fußnoten in HTML 4 darzustellen.)
2. Ein interaktives Formular, da PDF mehr Interaktivität zulässt als HTML. (Benutzen Sie dies mit Vorsicht und nur dann, wenn HTML wirklich nicht das kann, was Sie benötigen.) Sehen Sie sich beispielweise mal Jeremy Tankard's Bestellformulare an, besonders das für TypeBookOne (PDF).
3. Eine multimediale Präsentation, da neuere PDF Versionen wirklich Multimedia einbinden können statt sich einfach nur darauf zu verweisen oder diese Inhalte aufzurufen, so wie dies in HTML geschieht (es gilt die gleiche Warnung wie oben). PDF-Multimedia kann Untertitel und/oder Audio-Beschreibungen enthalten.
4. Kombinierte barrierefreie und nicht barrierefreie Versionen. Ein typischer Fall ist der Scan eines historischen Dokumentes, der auch echten Text beinhaltet. (Sie brauchen wirklich diesen echten Text. Die gescannten Gerichtsdokumente von Smoking Gun wären hier nicht akzeptabel.) Ein anderes Beispiel – eines, das in Kanada unter Befreiung vom Copyright rechtmäßig ist – ist die Übersetzung von Gebärdensprache in oder neben einem geschriebenen Text oder einer Audio-Aufnahme.
5. Spezielle Druckversionen. Ich meine wirklich genau das und nicht ein Dokument, das so schlecht gestaltet ist, dass man keine andere Wahl hat als es auszudrucken, da das Lesen vom Bildschirm so langwierig ist. Ihre Belichtungsdateien für die Druckvorstufe können, sofern Sie im Web überhaupt vorhanden sind, im PDF-Format bleiben.
6. Dokumente, die für Anmerkungen und »Hin- und Rückreise« (also den Informationsaustausch) gestaltet wurden: Wenn Sie etwas einstellen, damit Kommentare abgegeben werden können, die dann an Sie zurückgeschickt werden, dann hat PDF nützliche Strukturen, die HTML nicht hat.
7. Schriftmuster, die man definitiv nicht in HTML erstellen kann, außer das betroffene Beispiel ist eine »Schrift« wie die Arial.
8. Ein Beispiel eines Formats, das nicht in einem Browser gerendert werden kann (z. B. Illustrator- oder Photoshop-Dokumente) oder das nur sehr unbefriedigend dargestellt werden kann (CAD-Zeichnungen, bei denen GIF und JPEG nicht genügend Auflösung bieten). (Theoretisch könnten Sie SVG für CAD benutzen, aber SVG bleibt hauptsächlich theoretisch, oder?) Dieser Fall beinhaltet auch PDF-Dateien, die als Beispiel für PDF-Dateien gedacht sind.
9. Ein Beleg für den Status eines Dokumentes zu einem bestimmten Zeitpunkt. In diesem Zusammenhang ist PDF als Archivformat sinnvoll, sogar für HTML-Webseiten.
10. Ein Dokument in einer Sprache, deren geschriebene Form keine zufriedenstellende Unterstützung in Webbrowsern hat. Dieses Beispiel ist mit Vorsicht zu genießen: im Jahre 2005 gibt es nicht mehr viele »exotische« Sprachen, die nicht in einem Browser dargestellt werden können. Dieser Fall muss vielleicht auf Schriften begrenzt werden, die noch nicht von Unicode erfasst wurden (davon gibt es einige). Hierbei kann es sich auch um eine Teilmenge des Falles mit dem Schriftmuster handeln, wenn Ihr PDF als Illustration oder Dokumentation des von einer Sprache benutzten Schriftsystems dienen soll.
11. Mathematische Dokumente, da noch nicht einmal MathML bestimmte Notationen darstellen kann.
12. Dokumente mit einem gesetzlich beschränkten Format wie beispielsweise US-amerikanische Steuerformulare.
13. Dokumente mit Kopierschutz (Digital Rights Management), die jeder hasst und die wahrscheinlich Barrieren haben. (Die Benutzung von 128-bit-Verschlüsselung mit PDF ist kompatibel mit Screenreadern.)
14. Mehrspaltige Dokumente, besonders wenn Bilder und Illustrationen enthalten sind, da mehrspaltige Web-Layouts ein reiner Hack sind und unzuverlässig als Methode, um Druck-Layouts zu reproduzieren. (Ihr mehrspaltiges Dokument sollte in HTML sein, wenn es nur so dargestellt wird, um Papier zu sparen und es als einspaltiges Dokument ebenso funktioniert. Es kann schwierig sein, diesen Fall von einem Dokument zu unterscheiden, das strukturell mehrspaltig ist und diese Kategorie ist nur unscharf zu definieren.)

Lassen Sie mich das Gleiche noch einmal sagen: Wenn Ihr Dokument nicht einer dieser Kategorien zuzuordnen ist oder nicht wirklich auf irgendeine Art und Weise außergewöhnlich ist, dann liegt es in Ihrer Verantwortung das zu tun, was der Rest von uns getan hat. Das ist, die korrekte Benutzung von HTML, CSS und JavaScript zu lernen. Benutzen Sie diese Technologien, außer Sie haben einen wasserdichten Grund, dies nicht zu tun.

PDF ist nicht Acrobat und noch nicht einmal Adobe

Lassen Sie uns noch etwas aus dem Weg räumen: Acrobat ist nicht gleich PDF und PDF ist nicht gleich Acrobat. Neben Acrobat können viele Programme PDFs darstellen. GSview ist eine bekannte Wahl und funktioniert unter Windows, Mac, OS/2 und Linux. Andere Optionen:

• Unter Windows: Jaws PDF Editor (nicht der Screenreader)
• Unter MacOS X: Vorschau, Graphikkonverter, Safari und OmniGraffle
• Unter Linux oder Unix: OpenOffice / StarOffice
• Unter PocketPC und Windows CE: Primer PDF Viewer
• Unter Symbian: PDF+
• Auf Amiga (!): APDF

Neben Acrobat können viele Programme auch PDFs erstellen. Beispielsweise kann beinahe jede Anwendung unter MacOS X ein PDF sichern. Hilfsprogramme zum Export von PDF ohne Acrobat auf Plattformen wie Windows und Linux sind zu zahlreich, um sie zu erwähnen, aber Websites wie VersionTracker führt sie alle auf. Darüber hinaus brauchen Sie nicht einmal eine Anwendungssoftware, um ein PDF zu erstellen; einige geniale Entwickler schreiben ihre eigenen PDF-Dateien direkt.

Versionen

Ihre Acrobat-Versionsnummer und die Versionsnummer des PDF-Dateiformats sind zwei verschiedene Dinge. Es mag eine Überraschung sein, dass PDF tatsächlich eine Versionsnummer hat, aber so ist es. Es gibt genauso wenig ein einzelnes PDF-Format wie es ein einziges HTML-Format gibt.

• Die letzte Version des Adobe PDF-Dateiformates ist Version 1.6 (veröffentlicht im November 2004).
• Jede neue Version hat einige Funktionen und Merkmale hinzubekommen, hauptsächlich struktureller Art. PDF Tags, die ziemlich wichtig für die Barrierefreiheit sind, wurden in PDF 1.4 hinzugefügt.
• PDF-Versionen für die Archivierung (PDF/A) und zum »Austausch von druckfertigen Seiten« (PDF-X1a) wurden bereits standardisiert oder sind im Begriff, von den internationalen Standardisierungsorganisationen ratifiziert zu werden.
• Es gibt eine Arbeitsgruppe, die sich um die Definition eines »barrierefreien« PDF-Formats kümmert (darin arbeite ich mit) und eine andere für Ingenieurwissenschaften.

Der einfachste Weg, dies eindeutig zu verstehen ist, die aktuelle Acrobat Versionsnummer zu nehmen, 1 abzuziehen und das Ergebnis hinter das Komma zu schreiben. Acrobat 7 kann zum Beispiel PDF 1.6 Dokumente lesen.

Proprietär versus offen

Sie können nicht kategorisch sagen, dass PDF »proprietär« und HTML »offen« ist. Das World Wide Web Consortium schützt beispielsweise seine Empfehlungen urheberrechtlich, allerdings mit vernünftigen Nutzungsbedingungen. Adobe veröffentlicht seine Versionen des PDF-Formats und macht dies schon seit Version 1.3.

Ich habe den Einwand, dass Adobe das PDF-Format über Nacht ändern und Ihre Dokumente damit nutzlos machen könnte, noch nie verstanden. Dieser Einwand trifft auf das mysteriöse Microsoft Word-Dateiformat zu, aber nicht hierauf. (Die Word XML Schemata wurden veröffentlicht, aber über diese reden wir hier nicht. Microsofts PR-Apparatschiks in den U.S.A und Kanada haben mir versprochen, mich über den aktuellen Stand der Veröffentlichung des Word-Dateiformates zu informieren, haben dies aber nie getan.) PDF-Spezifikationen hingegen werden veröffentlicht und all Ihre Dokumente, die sich nach den veröffentlichten Spezifikationen richten, werden unverändert bleiben, wenn die Spezifikationen aktualisiert werden. Genauso wie ein Dokument, das gegen HTML 3.2 validiert wurde, unverändert blieb, als XHTML 1.1 herauskam, so werden Ihre PDF 1.4-Dokumente (zum Beispiel) weiterhin bis in unbegrenzte Zukunft funktionieren.

Die gesamte Diskussion über proprietär im Vergleich zu offen ist eine Scheindiskussion. Der relevante Unterschied ist zwischen veröffentlicht und geheim. PDF und HTML sind beides veröffentlichte Formate, Ende der Diskussion.

Sämtliche Formate müssen barrierefrei sein

Das Ziel aller, die sich um Barrierefreiheit bemühen ist es, die Zugänglichkeit für Menschen mit Behinderungen zu verbessern, Punkt. Wir sind nicht daran interessiert, nur HTML-Seiten barrierefrei zu machen. Die Gesamtheit der Inhalte im Web ist unser Arbeitsbereich und das beinhaltet Formate wie PDF und tatsächlich auch Flash (das Gleiche gilt für Multimediale Inhalte).

Um einen historischen Vargleich anzubringen: Als wir es in Kanada und den U.S.A. geschafft hatten, eine oder zwei untertitelte Fernsehsendungen in den Siebzigern zu senden, haben wir da nicht aufgehört. Wir erfanden ein System, das man auf alle Programme anwenden konnte (und die Europäer benutzen ihr existierendes Videotext-System für den gleichen Zweck). Dann stellten wir sicher, dass Leihvideos und Laserdiscs (erinnern Sie sich an diese?) mit Untertiteln versehen wurden. Dann begannen wir, einige wenige Ausdrucke von untertitelten Filmen herauszugeben.

Dann fanden wir einen Weg, um Audiobeschreibungen für blinde Menschen in Fernsehprogramme einzubauen. Dann tüftelten wir einen Weg aus, um Leihvideos mit Beschreibungen herzustellen. Dann entwickelten wir Closed-Captioning- und Deskriptionssysteme für neu erschienene Filme (und neue Systeme für Untertitelungen). Dann benutzten wir geschlossene Untertitel, Einblender und Audiospuren, um DVDs barrierefrei zu machen. Dann entwickelten wir Methoden, um Online-Videos mit Untertiteln zu versehen und zu beschreiben. Wir blieben auf dem neuesten Stand der Technik und machten jedes neue Format barrierefrei.

Auch wenn Sie nie selber PDFs erstellen, so werden Sie sicher zugeben dass es notwendig ist, dieses weit verbreitete Format aus den gleichen Gründen barrierefrei anzubieten, aus denen wir das weit verbreitete Format HTML barrierefrei machten.

Wir sprechen nicht nur von blinden Menschen

Und bedenken Sie, dass Barrierefreiheit nicht bedeutet, dass Dinge für blinde Menschen funktionieren und für niemand anderen. Jeder tritt irgendwann einmal in diese Falle, die Web Accessibility Initiative nicht ausgenommen. Bei der Barrierefreiheit von PDFs stellen auch gehörlose oder schwerhörige Nutzer und Menschen mit Lernbehinderungen zusätzliche wichtige Gruppen dar. Motorische oder feinmotorische Beeinträchtigungen werden beim Scrollen eines PDFs zu einem Thema.

Denken Sie daran, wenn sich das nächste Mal jemand beschwert, dass ein bestimmtes PDF nicht barrierefrei ist, weil er oder sie es mit einer bestimmten Version von JAWS nicht zum Laufen bringen konnten. Wir arbeiten nicht nur für diese Zielguppe.

Inhalt versus Benutzeragenten

Um diese einleitende Diskussion zu beenden müssen wir die Interaktion zwischen Inhalt und »Benutzeragenten« verstehen. Letzteres ist ein Begriff für Browser, Media Player und andere Dinge, die dem Nutzer Inhalte präsentieren. Als Web-Autoren sind wir mit HTML und CSS so beschäftigt, dass wir entweder die Rolle der Benutzeragenten komplett vergessen – oder wir vergessen sie bis es uns in den Allerwertesten beißt, wie zum Beispiel mit CSS-Bugs in Browsern. Wir tendieren dazu, die Tatsache zu vergessen, dass Web-Inhalte (in fast allen Fällen) von einem Browser gerendert werden; der Benutzeragent wird unsichtbar.

Weil wir aber meistens zu einem anderen Programm wechseln müssen, um ein PDF zu lesen, werden wir plötzlich daran erinnert, dass tatsächlich ein Benutzeragent mit im Spiel ist. Auch das ist eine Ursache für die Verwirrung zwischen Acrobat und PDF. Wie wir noch sehen werden ist die Interaktion von Benutzeragent und PDF-Inhalt hier genauso wichtig wie dies bei HTML der Fall ist. Wir sind uns dieser Interaktion einfach nur bewusster.

Die Beschwerde, dass man ein »spezielles Programm« benutzen muss, um ein PDF-Dokument zu lesen ist unsinnig. Sie benutzen bereits ein spezielles Programm um dieses HTML-Dokument zu lesen. Es ist lediglich so, dass Sie dieses Programm so oft benutzen, dass es nicht länger etwas Besonderes zu sein scheint.

Tags und Struktur

Genau wie bei HTML ist es die Struktur, die PDFs »robust«, umformatierbar und anderweitig barrierefrei für viele Menschen mit Behinderungen macht. Ein unstrukturiertes Binärformat wie ein JPEG-Bild kann nur schwerlich barrierefrei gemacht werden, zumindest für blinde Menschen. Wenn Sie dieses aber in die HTML-Struktur eines img-Tags einbinden, dann wird Barrierefreiheit plötzlich zu einer echten Option.

Ein PDF ist eine Datenbank aus verschiedenen Datentypen. Sie können eine große Bandbreite von Text, Grafiken und Multimedia-Formaten in einem PDF einschließen; eine Tatsache, die zu dem allgemeinen Missverständnis führte, dass PDFs bloß aufgehübschte Bilder sind (sie können dies sein, sind es aber nicht notwendigerweise). Es gab bei PDFs eigentlich nie so etwas wie eine Struktur, bevor Tags in PDF 1.4 eingeführt wurden. Es ist volkommen in Ordnung, diese Tags und nicht Elemente zu nennen.

PDF-Tags sind XML-ähnlich und sind für jeden, der HTML-Kenntnisse besitzt, sofort verständlich. Viele Tags sind funktional gleichbedeutend zu ihrem Gegenüber in HTML wie P, headings (einschließlich eines generischen, unnummerierten Heading-Elementes) und Figure (Grafik). Aber einige dieser Tags haben mehr mögliche Eigenschaften als ihre Entsprechungen in HTML. Für Bilder haben Sie drei Ebenen von Ersatztexten – »echter Text«, nützlich für Text, der als Bild gerendert wird, hängende Initialen oder ein illustriertes Manuskript; »Alternativtext« genau wie in HTML und »title«, ebenso wie in HTML. Sie können und sollten immer noch eine natürliche Sprache für Ihr PDF angeben, genau wie in HTML.

PDF-Tags sind erweiterbar und Sie können zusätzlich Ihre eigenen Tags erstellen. Es gibt allerdings auch einen vordefiniertes Satz.

Ein zentraler Unterschied ist, dass Sie nicht einfach einen Texteditor anwerfen können, um Tags zu ihrem Dokument hinzuzufügen, wie man das mit (X)HTML machen kann. Derzeit müssen Sie eine spezielle Anwendungssoftware, und hier vor allem Acrobat, benutzen, um Tags hinzuzufügen; da PDF ein binäres Format ist, wird sich das wahrscheinlich auch nicht ändern.

Ein getaggtes PDF kann, genau wie bei semantischem HTML, anders benutzt und neu formatiert werden, da die Anwendungssoftware weiß, was Sie mit den Daten in Ihrem Dokument meinten. Sie weiß, dass dieser Text eine Überschrift und der andere Text ein Absatz ist, so dass die Software zum Beispiel Ihren zweispaltigen Textfluss in ein einspaltiges Dokument umwandeln kann. Umfließen verwandelt Ihr mehrspaltiges PDF in ein Zoom Layout.

Allgemein können wir sagen, dass ein PDF wahrscheinlich barrierefrei ist, wenn es getaggt ist. Genau wie bei HTML können Sie Dinge falsch oder unsemantisch taggen, allerdings gibt es kein Konzept zum validen Tagging bei PDFs. Die bloße Präsenz von Tags garantiert keine Barrierefreiheit, da Sie diese vielleicht falsch benutzen, aber die Abwesenheit von Tags garantiert, dass das PDF selbst nicht barrierefrei ist. Beachten Sie die Betonung auf selbst, das ist nicht das Ende der Geschichte.

Die Aufgabe des Benutzeragenten

Hier kommt der Benutzeragent ins Spiel. Genau wie Webbrowser mit großem Aufwand und Kosten programmiert werden mussten, um mit nicht validem »Tag-Soup« HTML klar zu kommen, so musste Acrobat besonders programmiert werden, um mit den real vorhandenen PDFs klar zu kommen. Dies ist ein größeres Problem, da wenige PDFs getaggt sind und der freien Datenbank-Struktur von PDFs fehlt sogar die Quasi-Struktur vom »Tag-Soup« HTML.

In diesem Fall überwindet der Benutzeragent die fehlende Barrierefreiheit des Inhalts und so sollte es auch mit HTML sein. Die gesamte Kette vom Autor bis zum Leser muss barrierefrei sein, und jedes Bindeglied in der Kette kann die Fehler des anderen ausbügeln. In Übereinstimmung mit dem klassischen Rat »strikt zu sein mit dem, was man sendet und nachsichtig mit dem, was man akzeptiert« sollte es so sein: Wenn der Autor eines PDF keinen barrierefreien Inhalt erstellt, dann sollte die Vorlese-Software versuchen, dies auszubügeln.

• Acrobat-Versionen seit 4.05 (mit einem reinen Windows Plug-in) waren zumindest teilweise adäquat in der Lage, »nicht barrierefreie« PDFs funktionell barrierefrei zu machen.
• Acrobat 5 und später kann eine Lesereihenfolge erschließen und Text neu umbrechen.
• Acrobat 6 und später kann Text unter Windows und Macintosh vorlesen und dient damit de facto als Screenreader.

Beachten Sie, dass sich diese Diskussion hauptsächlich auf blinde oder lernbehinderte Leser bezieht. Ein gehörloser Mensch könnte dieses Dokument ohne Probleme einfach lesen. Bewegungs- und feinmotorische Behinderungen werden hier auch bedient: neuere Acrobat Versionen können ein Dokument automatisch scrollen, ohne dass man andauernd wieder klicken oder einen Scrollbalken in Bewegung setzten muss, falls man ein ausgesprochen langsames adaptives Werkzeug benutzt.

Daher ist es unmöglich zu sagen, dass auch ein ungetaggtes PDF nicht barrierefrei ist. Acrobat (oder ein anderes Programm) mag seine künstliche Intelligenz nutzen, um sich seinen Weg durch ein Dokument zu bahnen, um es entsprechend barrierefrei zu machen. Wenn sich jemand beschwert, dass Ihr PDF nicht barrierefrei ist, dann müssen Sie die Person fragen, welches Programm sie benutzt, um es zu lesen. In Anbetracht der Tatsache dass Adobe Reader (vormals Acrobat Reader) für Windows, MacOS, und Linux kostenlos ist und alle oben genannten Funktionen der Barrierefreiheit hat, und darüber hinaus auch noch mit vielen Screenreadern kompatibel ist, ist es ein bisschen weit hergeholt zu sagen, dass ein ungetaggtes PDF auf keinen Fall auf barrierefreie Art gelesen werden kann. Einige PDFs werden auch mit einem wirklich guten Vorleseprogramm nicht barrierefrei sein, aber viele werden entsprechend gut funktionieren.

Screenreader

Eine andere wiederkehrende Beschwerde zum Thema PDF-Barrierefreiheit – ebenfalls unsinnig – ist, dass Screenreader entweder PDFs nicht handhaben können oder es teurer Upgrades bedarf, damit diese damit umgehen können.

Alle führenden Screenreader unter Windows können PDFs lesen, einschließlich JAWS, Window-Eyes, IBM Home Page Reader und Hal.

Erinnern Sie sich an Bruce Maguire? Seine Präsentation auf der Web Essentials 2004-Konferenz in Sydney – auf der wir zwei uns im Speisesaal unterhielten – besagte das Folgende:

Das PDF-Format wird häufig benutzt, um Dokumente auf Webseiten zur Verfügung zu stellen. Trotz der beträchtlichen Arbeit, die Adobe unternommen hat, bleibt das PDF weiterhin ein ziemlich mit Barrieren behaftetes Format für Menschen die blind oder sehbehindert sind. Es gibt Software, die ein wenig Zugang zu dem Text einiger PDF-Dokumente bietet, aber damit ein PDF-Dokument für diese Software zugänglich wird muss es in Übereinstimmung mit den Richtlinien, die Adobe entwickelt hat, erstellt werden. Auch wenn man diesen Richtlinien folgt (es sind immerhin 32 Seiten), wird das daraus resultierende Dokument nur für die Personen barrierefrei sein, die die benötigte Software und die Fähigkeit zu deren Nutzung haben. Viele blinde oder sehbehinderte Menschen haben nicht die finanzielle Freiheit, die $1.000 und mehr auszugeben, die man typischerweise benötigt, um seine Screenreader-Software so zu aktualisieren, dass man die Vorteile der aktuellsten Barrierefreiheits-Funktionen nutzen kann. Dass ein Nutzer ein Upgrade in dieser Form benötigt, damit er ein Standarddokument lesen kann ist so als würde man die Präsentation von Webinhalten so erstellen, dass die meisten Menschen einen neuen Computer kaufen müssen, um es zu lesen. Dies ist sicher kein vernünftiger Weg zur Entlassung der Regierung aus der sozialen Verantwortung, ihren Bürgern relevante Informationen zur Verfügung zu stellen. In jedem Fall haben einige PDAs, die von blinden Menschen benutzt werden, keine Möglichkeit, auf PDF-Dateien zuzugreifen.

Lassen Sie uns mal mit diesen Einwänden aufräumen.

• PDFs gemäß der Richtlinien, die Adobe entwickelt hat vorzubereiten ist in keinster Weise etwas anderes als HTML-Seiten gemäß der Richtlinien, die das W3C entwickelt hat, vorzubereiten. (Wollen Sie diese ausdrucken? Es ist ein 34-seitiges PDF!)
• Es ist nicht so als ob PDFs das Einzige auf Ihrem Computer wären, wofür Sie Software und Fähigkeiten benötigen. Sie benötigen beides, um im Web zu surfen und HTML-Seiten zu benutzen.
• Es ist falsch zu behaupten, dass Blinde »normalerweise« […] »$1.000 und mehr« bezahlen müssen, um ihre Screenreader zu aktuualisieren. Einige Hilfsmittel, die PDFs laut vorlesen können, sind kostenlos, wie Adobe Reader. Niemand benötigt ein teures Software-Upgrade.
• Lassen Sie uns einen Blick auf die Upgrade-Preise für Screenreader unter Windows werfen. Annahmen: Alle Preise in U.S. Dollar; Sie besitzen bereits eine Lizenz eines Screenreaders, der keine PDFs lesen kann (wird immer unwahrscheinlicher).
  1. Die JAWS für Windows Software Maintenance Agreement (eine Wartungsvereinbarung) gibt Ihnen die zwei folgenden Releases für $180 oder $260. Daher könnte mit dieser Vereinbarung ein Upgrade auf eine PDF -fähige Version »kostenlos« sein.
  2. Eine ähnliche Vereinbarung sorgt für drei Window-Eyes Upgrades für $299.
  3. Ein Upgrade des Home Page Reader von jeder Version 2.5 oder 3 auf Version 3.04 ist kostenlos. Ansonsten kauft man das gesamte Paket erneut zu einem vergünstigten Preis von $79.
  4. Ein Hal-Upgrade von Version 5 auf Version 6 kostet $160 oder $220.
• »PDAs, die von blinden Menschen benutzt werden« müssen aktualisiert werden, wenn sie kein PDF verstehen. Im Grunde läuft dieser Einwand darauf hinaus, dass »wenn es nicht mit dem funktioniert, was ich bereits habe, dann funktioniert es nicht, Punkt«. Ich denke, dass die Zeit für diese Leute stehen geblieben ist. In diesem Fall hoffe ich, dass Sie HTML 2.0 und Ihre Geocities-Homepage genießen.

Die Annahme scheint zu sein, dass Blinde überhaupt nur Windows benutzen, benutzen können oder benutzen sollen. Wie wir alle wissen sind Windows-Screenreader überteuert. Ja, das sind sie, aber blinde Menschen haben mittlerweile viele Alternativen in der barrierefreien Informationstechnik.

Natürlich mag es sein, dass Sie Ihren Windows-Screenreader aktualisieren müssen und natürlich könnte es sein, dass Sie das Geld kostet. Man kann sich aber nicht beschweren, dass PDF nicht barrierefrei ist (wie es viele Jahre lang tatsächlich war) und sich dann so verhalten, als wäre dieses Problem nicht angegangen worden. Adobe hat die PDF-Spezifikationen umgeschrieben, um das Tagging für die Barrierefreiheit aufzunehmen und Screenreader mussten, wie das bei allen verbesserten Technologien der Fall ist, aktualisiert werden, um mit Funktionalitäten umzugehen, die vorher nicht existiert hatten. Sie haben nach etwas Neuem gefragt und Sie brauchen etwas, damit dies dann funktioniert.

Es erscheint mir meistens, wenn ich mit dieser Beschwerde konfrontiert werde, als ein missmutiger Versuch sich an der diskreditierten Idee festzuhalten, dass PDF nicht barrierefrei ist und dass speziell Adobe das Problem herzlich egal ist. Wir brauchen diese Beschwerden wirklich, um erwachsen zu werden und den Fakten ins Gesicht zu sehen. Sie können nicht darum bitten, dass ein Format aktualisiert wird, damit die Barrierefreiheit mit eingeschlossen wird und sich dann beschweren, dass Ihre eigene Software aktualisiert werden muss.

Wenn Sie nicht das Geld für einen Windows-Screenreader locker machen wollen oder können, dann sollten Sie MacOS oder Linux benutzen. VoiceOver auf MacOS X 10.4 Tiger kann PDF Dateien der Version 1.5 und älter lesen, wenn auch nicht immer sehr gut. Das Barrierefreiheits-Paket von Sun für Linux (Teil von Solaris 10), welches kostenlos ist, beinhaltet einen eingebauten Screenreader. Es gibt eine neue Version von Adobe Reader 7 für Linux, wobei hier keine Sprachausgabe enthalten ist.

Wenn Sie sich wirklich Sorgen um die Kosten machen, dann installieren Sie die kostenlose Linux-Software oder installieren Sie Tiger auf einem gebrauchten Mac (tatsächlich kostet ein neuer Mac Mini mit Monitor weniger als eine neue Lizenz für JAWS). Wenn Sie glauben, dass die Hersteller der Windows-Screenreader zu viel Geld verlangen, dann beschweren Sie sich beim Hersteller oder wählen Sie mit ihren Füßen. Das eigentliche Problem – Barrierefreiheit von PDFs – ist gelöst.

Lassen Sie uns bei Fehlern von Screenreadern konsistent sein

Wenn Sie sich außerdem darüber beschweren wollen, wie lange Screenreader gebraucht haben, um PDF zu handhaben, auch wenn das Problem hinter uns liegt, lassen Sie uns einen Blick darauf werfen, wie gut Screenreader mit HTML umgehen können.

Die Wirklichkeit sieht so aus, dass HTML ein stabiler Standard ist und Screenreader lange Zeit hatten, es richtig hinzukriegen. (HTML 4.01 wurde 1999 veröffentlich, XHTML 1.0 in 2000 [überarbeitet 2002], XHTML 1.1 in 2001.) Aber in Wirklichkeit sind Screenreader immer noch bei der Aufholjagd. Wo ist der Unterschied zur Unterstützung von PDFs? Es gibt keinen, mal abgesehen davon, dass es schlimmer ist, weil es HTML schon länger gibt. PDF Unterstützung ging im Zeitraum von zwei Jahren von »überhaupt nicht« zu »ziemlich gut« während Screenreader immer noch trübsinnig herumschleichen und kaum in der Lage sind mit den vollen HTML Empfehlungen umzugehen.

Wenn Sie versuchen einzuwenden, dass die Kombination von PDF plus Screenreader ein Problem ist, was passiert dann, wenn HTML plus Screenreader auch ein Problem ist? Die Beschwerde, dass Screenreader Probleme mit PDFs aber keine Probleme mit HTML haben ist auf zwei Arten falsch. Warum hören wir keinerlei Beschwerden darüber, dass man Screenreader aktualisieren muss, damit sie mit HTML umgehen können?

Lassen Sie uns die Beweise ansehen.

JAWS

Window-Eyes

IBM Home Page Reader

Bemerkungen:

1. IBM und GW Micro haben die Angewohnheit, Dokumentationen von älteren Versionen zu entfernen, sobald eine neue Version herauskommt. Hier wurden die Dokumentationen zu Window-Eyes hauptsächlich über Internet-Archive gesammelt. Ein Review des W3C von HPR 2.5 wurde benutzt.
2. JAWS 5.0 ist oben nicht aufgeführt. Diese Version wurde nur in unzusammenhängenden Audiodateien dokumentiert (14 MB .exe). Augenscheinlich haben sie Unterstützung für Listen und blockquote hinzugefügt (genutzt für »Einrückungen«, wie wir in der Aufnahme erfahren).
3. Die HTML-Unterstützung in Hal ist schwierig zu ermitteln, selbst nachdem mir Dolphin Computer Access die verschiedenen Release Notes geschickt hat. Version 6.51 hat ein Flash-Problem und ein Problem mit ausserhalb des Fensters positionierten Skip-Links (nur marginal relevant für die Unterstützung der Spezifikationen) beseitigt; Mit Version 6.03 wurden Links, Frames und Überschriften, so wie abbr, acronym und label angekündigt und damit auch erkannt.

Sie sehen also, dass sich die Unterstützung von HTML in Screenreadern entwickelt hat und immer noch entwickelt. Aber urplötzlich, als Screenreader aktualisiert werden mussten, um mit PDFs umzugehen, tun manche Kritiker so, als wären solche Upgrades übertrieben und etwas ganz besonderes. Sie haben Ihre Screenreader die ganze Zeit aktualisiert nur um mit HTML-Dokumenten zurecht zu kommen, die sich auf bis zu sechs Jahre alte Spezifikationen stüzen.

Autorenwerkzeuge

Bei Autorenwerkzeugen, der Software, die zur Erstellung von PDFs benutzt wird, versagt die Barrierefreiheit von PDFs auf ganz peinliche Art und Weise. Nur wenige Programme können von sich aus eine getaggte PDF-Datei erstellen. Dazu gehören InDesign; PageMaker 7.0 (!); FrameMaker 6.0 und höher, und Microsoft Office mit einem Adobe Export Plug-In (nur Office 2000 und später, nur unter Windows). Produkte, die PDFlib 6.0 und höher benutzen, können getaggte PDFs erstellen. Es mag hier und dort noch einige weitere kleinere Hilfsprogramme geben.

Die durchschnittliche Person aber steht vor der Aufgabe, ein ungetaggtes oder schlecht getaggtes Original aufzumöbeln. Sie haben eigentlich keine andere Chance als die Tagging Funktion, die in Adobe Acrobat eingebaut ist (die Vollversion, nicht nur der Reader; zusätzlich benötigen Sie für einige Funktionen die Pro-Version) zu benutzen. Es gibt bereits einige nicht sehr hilfreiche Tutorials zum Taggen mit Acrobat und ich werde, auch auf das Risiko hin, meine Leser zu enttäuschen, kein weiteres schreiben, da das Leben zu kurz ist. Die Grundlagen dessen, was Sie tun müssen, sind allerdings einfach aufzuführen:

1. Öffnen Sie Ihr PDF.
2. Der Reiter Beschreibung des Dialogs Dokumenteigenschaften (im Menü Datei) wird ihnen sagen, ob das Dokument getaggt ist oder nicht.
3. Wenn es nicht getaggt ist, dann verlassen Sie dieses Fenster. Gehen Sie zum Menü Erweitert und wählen Sie Ausgabehilfe → Tags zu Dokument hinzufügen.
4. Lassen Sie aus diesem Menü eine vollständige Prüfung laufen.
   
5. Wenn die Überprüfung Probleme angibt, dann öffnen Sie die wenig bekannte Tags-Palette (Anzeige → Navigationsregisterkarten → Tags). Benutzen Sie diese Palette, um durch die neue Tag-Struktur Ihres Dokumentes zu gehen. Sie sollten Inhalt markieren aus dem Menü Optionen der Palette auswählen, da Acrobat dann einen kaum zu sehenden Rahmen um das Objekt zieht, wenn Sie einen Tag auswählen.

Lösung der gängigsten Probleme:

• Wenn sich Acrobat beschwert, dass Ihrem Dokument die Angabe der Sprache fehlt, dann suchen Sie den obersten Tag in Ihrem Dokument (am Anfang des selbstreferentiellen Tags-Tags). Klicken Sie mit der rechten Maustaste oder mit Ctrl-Klick darauf und wählen Sie Eigenschaften. Wählen Sie eine Sprache aus dem PopUp-Menü im Feld Sprache oder geben Sie ihren eigenen Sprachcode, bestehend aus zwei Zeichen, ein.
• Machen Sie es so ähnlich bei Bildern, denen das Textäquivalent fehlt. Der Unterschied hier ist nur, dass Sie das Bild-Element bei dem der äquivalente Text fehlt, manuell suchen müssen. Klicken Sie auf das Bild, wählen Sie Eigenschaften aus dem Kontextmenü und füllen Sie den Alternativtext (genau wie das alt-Attribut in HTML) oder den tatsächlichen Text (für eine Abbildung eines Textes) ein.
  
  (Es gibt einen halbautomatischen Weg, um alle Bilder ohne Textäquivalente zu finden. Wenn Sie Erweitert → Ausgabehilfe → Vollständige Prüfung laufen lassen und dabei »Alternative Beschreibungen sind vorhanden« auswählen, dann findet Acrobat alle Bilder, bei denen der alternative Text fehlt und gibt Ihnen im Bericht Links zu diesen Stellen an.)
• Ein Dokument aus einer gedruckten Quelle kann »Artefakte« wie Kopf- und und Fußzeilen enthalten, die Nutzer von Screenreadern nicht jedesmal hören möchten. Sie können auf diese Punkte klicken (diese können Figure, Part, P oder irgendetwas anderes sein) und dann »Tag in aussertextliches Element ändern« auswählen, was dazu führt, dass Acrobat und kompatible Screenreader diese beim Vorlesen ignorieren. Sie können auch das Touch-Up Leserichtung-Werkzeug benutzen, um das Artefakt auf der jeweiligen Seite auszuwählen und als Hintergrund auszuzeichnen.

Wenn Ihnen diese Aufgabe langwierig erscheint, dann haben Sie Recht, das ist sie wirklich. Und diese Arbeit ist auch nicht sonderlich barrierefrei für viele Menschen mit Behinderungen. Denken Sie daran, dass wir nicht an einem Web arbeiten, in dem nichtbehinderte Menschen Inhalte für behinderte Menschen erstellen; Menschen mit Behinderungen müssen ebenfalls Ersteller sein.

Acrobat ist ein ungewöhnliches Programm insofern als dass es sich möglicherweise sowohl nach den Authoring Tools Accessibility Guidelines als auch nach den User Agent Accessibility Guidelines richten muss, da Sie mit Acrobat Inhalte erstellen und ansehen können (und PDFs selber sind abhängig von den Web Content Accessibility Guidelines; sie werden von den WCAG 2.0 abgedeckt, von denen man erwartet, dass sie Technologie-neutral sein werden). Acrobat und PDF richten sich nicht vollständig nach allen diesen Richtlinien, aber nur wenige Dinge sind komplett konform – und wenn es um ATAG geht, dann ist nichts konform.

Schlussfolgerung

Die Barrierefreiheit von PDFist nicht so geradlinig wie die Barrierefreiheit von HTML. Aber wir müssen uns den Unwahrheiten, die über das PDF verbreitet werden, entgegen stellen, besonders, da viele dieser Unwahrheiten von Behörden kommen, die mit der Macht ausgestattet sind, Autoren der Diskriminierung für schuldig zu befinden.

Die Barrierefreiheit von PDF ist teilweise in Ordnung, wenn sie von kompetenten Autoren mit den wenigen verfügbaren Werkzeugen gehandhabt wird. All diese Komponenten bedürfen der Verbesserung, aber lassen Sie uns nicht so tun, als hätten wir nicht die Möglichkeit, barrierefreie PDFs zu erstellen. Wir haben sie.

Danksagung

• Jacques Distler
• Andy Dulson
• Loretta Guarino Reid
• Phill Jenkins
• Greg Pisocky
• Ted Padova

Wir würden gerne Ihre Meinung wissen: Teilen Sie uns Ihre Erfahrungen mit und diskutieren Sie diesen Artikel mit anderen Experten.