accessBlog

Aktuelles zum Thema Barrierefreies Webdesign.

03 Mai 2012

Glaubt man unseren Statistiken, so ist das Thema »Barrierefreie PDF« einer der Suchbegriffe, der mit den meisten Traffic auf dieses Angebot und die bereitgestellten Anleitungen bringt. Was nicht weiter verwunderlich ist, angesichts der schieren Masse an PDFs, die täglich im Web veröffentlicht werden. Hinzu kommt, dass die Produktion barrierefreier PDF nicht gerade einfach ist, wenn man die falschen Werkzeuge benutzt oder keinen geeigneten Workflow beachtet. Und selbst mit den geeigneten Werkzeugen ist die Bearbeitung oftmals wenig intuitiv und die Programme sind nicht unbedingt frei von Bugs (so kann Acrobat Professional auch in der neuesten Version immer noch kein Undo für viele Operationen).

Grund genug, sich mal die PDF-Techniken anzusehen, die Adobe als Ergänzung zu den Web Content Accessibility Guidelines 2.0 (WCAG2) beigesteuert hat und die Autoren helfen sollen ihre Inhalte auch jenseits von HTML & CSS barrierefreier zu machen. Anfang diesen Jahres wurden diese auf den Seiten der Web Accessibility Initiative des W3C veröffentlicht und wir haben diese nun ins Deutsche übersetzt.

Den Anfang macht heute die Einleitung zu den PDF-Techniken; die eigentlichen Techniken (insgesamt 23 an der Zahl) folgen dann in loser Folge. Die Aktualisierung und Erweiterung dieser unterstützenden WCAG-Dokumente ist ein laufender Prozess und wir freuen uns über Ihre Beiträge und Verbesserungsvorschläge in den Kommentaren.

Weiterlesen …

Möglichkeiten zur Beteiligung

Ein Wort zu den Techniken

Anders als die BITV 2 fälschlicherweise verordnet sind ausschließlich die Erfolgskriterien aus den WCAG 2.0 die Grundlage für die Feststellung der Konformität zu diesem Standard – nicht die Techniken. Das Techniken-Dokument stellt eine Handlungsempfehlung zur Verfügung, die »informativ« ist – Sie müssen diese Techniken nicht benutzen, um die WCAG zu erfüllen! Web-Inhalte können andere Methoden benutzen, um die WCAG-Erfolgskriterien zu erfüllen. Web-Inhalte könnten sogar bei einem bestimmten Techniken-Test durchfallen und trotzdem noch die WCAG 2 auf eine andere Art erfüllen. Außerdem erfüllen Inhalte, die die veröffentlichten Techniken benutzen, nicht notwendigerweise alle WCAG-Erfolgskriterien.

PDF und die WCAG-Erfolgskriterien

WCAG 2.0-Erfolgskriterien und anwendbare Techniken für PDF
ErfolgskriterienStufeTechniken
1.1.1 Nicht-Text-Inhalte (non-text content)A
1.2.1 Reine Audio- und Videoinhalte (aufgezeichnet)A
1.2.2 Untertitel (aufgezeichnet)A
1.2.3 Audiodeskription oder Medienalternative (aufgezeichnet)A
1.2.4 Untertitel (Live)AA
1.2.5 Audiodeskription (aufgezeichnet)AA
1.3.1 Info und BeziehungenA
1.3.2 Bedeutungstragende ReihenfolgeA
1.3.3 Sensorische EigenschaftenA
1.4.1 Benutzung von FarbeA
1.4.2 Audio-SteuerelementA
1.4.3 Kontrast (Minimum)AA
1.4.4 Textgröße ändernAA
1.4.5 Bilder eines TextesAA
2.1.1 TastaturA
2.1.2 Keine TastaturfalleA
2.2.1 Zeiteinteilung anpassbarA
2.2.2 Pausieren, beenden, ausblendenA
2.3.1 Grenzwert von dreimaligem Blinken oder wenigerA
2.4.1 Blöcke umgehenA
2.4.2 Seite mit Titel versehenA
2.4.3 Fokus-ReihenfolgeA
2.4.4 Linkzweck (im Kontext)A
2.4.5 Verschiedene MethodenAA
2.4.6 Überschriften und LabelsAA
2.4.7 Fokus sichtbarAA
3.1.1 Sprache der SeiteA
3.1.2 Sprache von TeilenAA
3.2.1 Bei FokusA
3.2.2 Bei EingabeA
3.2.3 Konsistente NavigationAA
3.2.4 Konsistente ErkennungAA
3.3.1 FehlererkennungA
3.3.2 Beschriftungen (Labels) oder AnweisungenA
3.3.3 FehlerempfehlungAA
3.3.4 Fehlervermeidung (rechtliche, finanzielle, Daten)AA
4.1.1 SyntaxanalyseA
  • Nicht zutreffend: PDF wird nicht durch die Benutzung von Auszeichnungssprachen implementiert
4.1.2 Name, Rolle, WertA

Kommentare zu dieser Meldung: 2

Permalink Ute Helmich meinte am 23.05.2012:

In: PDF8: Bereitstellung von Definitionen für Abkürzungen per E-Eintrag für ein Strukturelement ist angegeben, das alle Abkürzungen bei ihrem 1. Auftreten im Text per Span-Tag ausgezeichnet werden sollen.

Wir gestalten häufig PDF-Dateien barrierefrei. Bei einer Vielzahl der Dokumente handelt es sich um Fachtexte mit sehr vielen Abkürzungen. Um nicht jedesmal einen Span für eine Abkürzung generieren zu müssen sind wir dazu übergegangen die jeweilige Abkürzung im Alternativtext des Tags, z.B. P-Tag, auszuzeichnen.

Weder im Ausgabehilfebericht von Adobe noch von PAC wird diese Vorgehensweise bemängelt.
Spricht etwas gegen diese Vorgehensweise?

Permalink Olaf Drümmer meinte am 02.07.2013:

Die Frage ist zwar schon mehr als ein Jahr alt, aber ich antworte hier trotzdem mal:

Das "Alt" Attribut (für alternative Texte/Beschreibungen) ist vor allem als text-basierte Erläuterung von nicht-text-basierten Inhalten, also vor allem bildlichen Darstellungen, gedacht. Die Nutzung des Alt-Attributes für die Erklärung von Abkürzungen halte ich für keine gute Idee.

Ohnehin sollte man das Problem "Abkürzungen" vor allem auf redaktioneller Ebene lösen, in gleicher Weise für alle Nutzer eines Dokuments, nämlich durch Erläuterung der Abkürzung im Text selbst bei deren erstem Vorkommen. Weitere Vorkommen der Abkürzung im weiteren Text sind damit abgedeckt. Außer in Ausnahmefällen (wenn das Dokument redaktionell sehr schwach aufgestellt ist), ist das E (Expansion) Attribut eigentlich eher nicht zu verwenden, außer man möchte seinen Lesern einen zusätzlichen Dienst erweisen (die Zeit ist dann aber in der Regel anderweitig besser investiert - beispielsweise indem man ein Abkürzungsverzeichnis im Dokument integriert und ggf darauf verlinkt, da haben dann auch alle Nutzer etwas davon; hierbei ist allerdings auch zu beachten, dass eine Schwemme an redundanten Links bestimmten Nutzerkreisen auch eher nicht hilft).