PDF/UA-1 unter der Lupe – Teil 9: Alternative Beschreibungen für alle Links zwingend

Wichtiger Hinweis (16.06.2019): Aussagen zur BITV beziehen sich auf die Fassung der BITV 2.0 vor dem 21. Mai 2019. Mit der Verordnung zur Änderung der BITV 2.0 fand inzwischen eine Angleichung an die internationalen Richtlinien im Zuge der Umsetzung der EU-Richtlinie zur digitalen Barrierefreiheit statt. Aussagen zu den WCAG 2.0 gelten auch für die im Juni 2018 veröffentlichte WCAG 2.1 Inwiefern das neue WCAG-Erfolgskriterium 2.5.3 Label in Name zu weiteren Unterschieden zwischen WCAG und PDF/UA führt wird in den kommenden Wochen näher untersucht.

In Abweichung zu den WCAG 2.0 und der Europäischen Norm EN 301549 verlangt PDF/UA-1 für alle Links zusätzliche alternative Beschreibungen – auch, wenn die Linktexte bereits für jeden und damit auch für Menschen mit Behinderungen eindeutig, aussagekräftig und sprechend sind. Dabei wirft nicht nur die Anforderung selber Fragen auf, sondern auch die geforderte technische Umsetzung sowie die im Matterhorn-Protokoll vorgesehene Prüfung durch Software.

Linktexte in WCAG 2.0 und BITV 2.0

Die Web Content Accessibility Guidelines 2.0 (WCAG 2.0) arbeiten bei einigen Aspekten der Barrierefreiheit mit einem Stufenmodell. Ein Beispiel sind Kontraste: Die Stufe AA ist erfüllt, wenn Texte ein Kontrastverhältnis von 4,5:1 haben; die Stufe AAA, wenn es bei mindestens 7:1 liegt. Auch bei Links oder besser gesagt bei Linktexten gibt es ein Stufenmodell. Stufe A ist erfüllt, wenn Linkziele bzw. Zweck von Links aus dem Linktext zusammen mit dem Kontext deutlich sind. Die Stufe AAA wird erreicht, wenn die Linktexte selber sprechend sind. Für beide Erfolgskriterien gibt es eine eng gefasste Ausnahme. Sie greift, wenn Links für jeden Benutzer mehrdeutig sind.

Die Erfolgskriterien lauten gemäß der autorisierten deutschen Übersetzung:

2.4.4 Linkzweck (im Kontext): Der Zweck jedes Links kann durch den Linktext allein oder durch den Linktext zusammen mit seinem durch Software bestimmten Link-Kontext bestimmt werden außer in Fällen, in denen der Zweck des Links mehrdeutig für Benutzer im Allgemeinen wäre. (Stufe A)

und

2.4.9 Linkzweck (reiner Link): Es gibt einen Mechanismus, um den Zweck jedes Links durch den Linktext allein zu erkennen, außer der Linkzweck wäre mehrdeutig für Benutzer im Allgemeinen. (Stufe AAA)

Was wird in den WCAG 2.0 unter „Kontext“ verstanden? Der „Kontext“ ist eine Kombination aus Linktext und dem direkt umgebenden Inhalt bei gleichzeitiger korrekter Auszeichnung. Drei Beispiele:

• Ein Link befindet sich in einem Absatz, der über das P-Element bzw. den P-Tag ausgezeichnet ist. Spätestens aus dem gesamten Absatz wird das Linkziel klar.
• Links befinden sich in der zweiten Ebene einer korrekt ausgezeichneten verschachtelten Liste. Die übergeordneten Listenpunkte informieren über Ziel oder Zweck. Ein Beispiel dafür ist ein Literaturverzeichnis, in welchem übergeordnete Listenpunkte den Titel nennen und die zugeordneten Listenpunkte verfügbare Formate als Download-Links (HTML, PDF, Epub) aufführen.
• Ein Link befindet sich in einem Satz. Das Linkziel wird spätestens aus dem Satz deutlich.

Auf Stufe AAA reicht der Kontext nicht mehr aus, sondern die Linktexte selber sollen aussagekräftig sein.

Man mag den WCAG 2.0 hier „Laschheit“ konstatieren, jedoch erfüllt das Stufenmodell einen wichtigen Zweck. Wären generell und immer aussagekräftige Linktexte gefordert, dann kann das in vielen Szenarien bedeuten, dass Texte geändert werden müssten. Das aber kann und darf man nicht in jedem Fall. Auch die Ausnahme „mehrdeutig für jeden“ kann vor diesem Hintergrund betrachtet werden. Ihr eigentlicher Kern ist aber: Wenn ein Link für jeden mehrdeutig ist, dann ist er das für jeden – unabhängig von einer Behinderung und unabhängig davon, ob jemand Screenreader-Nutzer oder Nutzer anderer Assistiven Technologien ist oder nicht. Die Ausnahme lautet zitiert aus der autorisierten deutschen Übersetzung des Glossars:

Mehrdeutig für Benutzer im Allgemeinen (ambigous to users in general). Der Zweck kann nicht durch den Link und die gesamten Informationen auf der Webseite, die dem Benutzer gleichzeitig mit dem Link gezeigt werden, bestimmt werden (…). Beispiel: Das Wort Guave in folgendem Satz „Eines der bedeutendsten Exportgüter ist die Guave“ ist ein Link. Der Link könnte zu einer Definition von Guave führen, zu einem Diagramm, in dem Menge der an exportierten Guaven aufgelistet ist oder zu einer Fotografie von Menschen bei der Guavenernte. Bevor der Link nicht aktiviert wird, sind sich alle Benutzer darüber im Unklaren und die Person mit Behinderung hat keinen Nachteil.

Unabhängig von formalen Erwägungen und Aspekten gehört natürlich das Thema „sprechende Linktexte“ aus Gründen der Accessibility sowie der Usability nicht nur in jeden Redaktionsleitfaden. Das Thema ist für jeden relevant, der in irgendeiner Weise mit der Erstellung von Inhalten für Web und Intranet zu tun hat – unabhängig vom Format. Generell gilt: Je aussagekräftiger und „sprechender“ Linktexte sind, desto besser für jeden.

Bestimmte Links sind für jeden eindeutig, aussagekräftig und sprechend. Dazu gehören Links in Inhaltsverzeichnissen, wenn sie – und das ist Usus – aus Überschriften und Zwischenüberschriften erzeugt werden. Beispiele findet man in Wikipedia-Artikeln, wo auf Basis der Überschriften klickbare Inhaltsverzeichnisse generiert werden. Auch in Word und anderen Textverarbeitungsprogrammen kann aus Überschriften und Zwischenüberschriften automatisch ein solches klickbares Inhaltsverzeichnis erstellt werden – sofern korrekt mit Formatvorlagen gearbeitet wurde. Sind Überschriften und Zwischenüberschriften aussagekräftig (Erfolgskriterium 2.4.6 der WCAG 2.0, Bedingung 2.4.6 der BITV 2.0), dann sind es auch die Links im Inhaltsverzeichnis. Zudem korrespondieren sie durch das 1:1-Verhältnis von Überschrift zu Linktext miteinander und sind eindeutig identifizierbar. Aber auch ohne Kontext sind Links oft bereits für jeden klar. Kommt ein Link allerdings so daher

Weitere Informationen unter: www.internetseite.de

dann bietet weder der Linktext allein noch zusammen mit dem Kontext ausreichende Informationen. Entweder muss der Text ergänzt werden oder er muss in den vorherigen Absatz platziert werden (sofern dieser vermittelt, um welche „weiteren Informationen“ es geht) oder und für PDF der Linktext erhält eine ergänzende alternative Beschreibung im Alternativtext (Technik PDF13). In diesem Fall wird von Screenreadern der Alternativtext vorgelesen. Woraus sich auch ergibt, dass man mit dem Alternativtext sorgsam umgehen muss. Alternativtexte sind dafür gedacht, dass Links sprechender und aussagekräftiger werden. Sie können allerdings auch das Gegenteil bewirken, z.B. wenn der Alternativtext einfach nur „klicken Sie hier“ lauten würde. Die in diesem Abschnitt genannte WCAG-Technik wird sehr gut von Screenreadern unterstützt und befindet sich seit inzwischen fast einem Jahrzehnt im Technikendokument für PDF. Stets besser für alle ist aber natürlich, wenn Links von vornherein aussagekräftig sind.

Die BITV 2.0 weicht bei Bedingungen für Links erheblich von den WCAG 2.0 ab, denn die Ausnahme „mehrdeutig für Benutzer im Allgemeinen“ wurde nicht übernommen. Als Grund nennt die Begründung zur BITV 2.0 auf S. 13 (Abschnitt 2.3.2.19):

„Die WCAG 2.0 lassen bei dieser Bedingung eine Ausnahme zu (wenn Ziel und Zweck eines Links für alle Nutzerinnen und Nutzer unklar wären), die nicht in die Anlage 1 übernommen wurde. Ziel dieser Abweichung ist es, die Bereitstellung von Informationen zu Ziel und Zweck eines Links insbesondere für lern- und geistig behinderte Nutzerinnen und Nutzer sicherzustellen, die keinen Screenreader benutzen.“

Sie verwundert in mehrfacher Hinsicht, denn es geht bei der Ausnahme der WCAG 2.0 nicht um „unklare“ Links, sondern um mehrdeutige Links. Sie liest sich, als habe man folgenden Fall im Sinn gehabt: Es gibt mehrere Möglichkeiten, um speziell für Screenreader-Nutzer Texte zu hinterlegen. Ein Link „mehr“ etwa kann um einen versteckten Text ergänzt werden, der von Screenreadern vorgelesen wird (HTML). Weitere Möglichkeiten bietet WAI-ARIA für das Format HTML. Typische Anwendungsbereiche solcher Techniken für Screenreader-Nutzer sind z.B. „mehr“-Links in Teasern. Der entscheidende Punkt ist in diesem Zusammenhang: Wenn Texte für Screenreader-Nutzer hinterlegt sind, dann sind sie nicht mehr für jeden mehrdeutig und die Ausnahme der WCAG 2.0 greift dann nicht. Darüber hinaus kritisch: Folgt man der Begründung, dann wären auch Alternativtexte für Links nicht gestattet, denn diese richten sich vor allem an Screenreader-Nutzer.

In vielen praktischen Situationen kann das empfindliche Konsequenzen haben: Man erhält als Redakteur den Artikel eines Autors zum Einpflegen auf eine Webseite, für einen Sammelband, das Intranet oder oder. Der Artikel enthält Links und damit auch Linktexte. Wäre ein Link tatsächlich mehrdeutig, dann müsste wegen des Wegfalls der Ausnahme letztlich der Text umgeschrieben werden. Abgesehen von Aspekten des Urheberrechts, die dem entgegenstehen können, oder wenn Texte aus anderen Gründen nicht mehr geändert werden dürfen, z.B. wenn ein Jahresbericht bereits in Druck gegangen ist und das PDF auch im Web veröffentlicht werden soll: Was, wenn ein Redakteur keine ausreichende Expertise hat und sich ungewollt fachliche Fehler einschleichen? Das mag bei dem Beispiel zur Guave weniger der Fall sein. Aber was ist mit juristischen Texten? Was, wenn für den Text eine Zeichenbegrenzung vorgesehen ist und die Änderung von evtl. mehreren Sätzen diese übersteigt? Abgesehen davon, dass generell mehrdeutige Links ein Aspekt der Usability sind und kein Aspekt der Accessibility: Es sprechen zahlreiche Gründe dafür, tatsächlich Ausnahmen zuzulassen und zwar in den engen Grenzen der WCAG 2.0, die auch in die WCAG 2.1 übernommen werden.

Links in PDF/UA

Nach PDF/UA-1 muss jeder Link grundsätzlich eine zusätzliche alternative Beschreibung erhalten. Ein Stufenmodell oder Unterschiede zwischen aussagekräftigen und eindeutigen Linktexten und solchen, die es nicht sind, werden nicht gemacht. Auch spielen weder der Kontext eine Rolle noch Mehrdeutigkeit für jeden Nutzer. Diese zwingende alternative Beschreibung muss sich lt. Matterhorn-Protokoll im sogenannten Contents-Schlüssel befinden. Die Fehlerbedingung lautet:

„Eine Link-Annotation weist im Contents-Schlüssel keine alternative Beschreibung auf.“

Vorgesehen ist die Prüfung über „Software“. Voraussichtlich wird dies in PDF/UA-2 insofern geändert, als zukünftig auch der Alternativtext verwendet werden kann. An der grundsätzlichen Verpflichtung, jede Link-Annotation zusätzlich mit einer alternativen Beschreibungen versehen zu müssen, wird sich – unter Vorbehalt und mit Stand vom 10.05.2018 – jedoch offenbar nichts ändern.

Laut dem Mapping „Achieving WCAG 2.0 with PDF/UA-1“ korrespondieren die Abschnitte 7.18.1 Absatz 2 und 7.18.5 der PDF/UA-1-ISO mit dem Erfolgskriterium 2.4.4 der WCAG 2.0 und 7.18.5 mit dem erweiterten Erfolgskriterium 2.4.9 der WCAG 2.0. Allerdings geht es in 7.18.1 Absatz 2 von PDF/UA-1 um die technisch-korrekte Lese-Reihenfolge (z.B. für Screenreader), die man nach WCAG 2.0 eher in Erfolgskriterium 1.3.2 „Bedeutungstragende Reihenfolge“ ansiedeln würde. Das Mapping ist aus noch einem weiteren Grund fragwürdig. Da PDF/UA-1 die alternative Beschreibung immer fordert entspricht das weder dem Erfolgskriterium 2.4.4 noch dem Erfolgskriterium 2.4.9 – zumal PDF/UA-1 die Ausnahme für mehrdeutige Links ebenfalls nicht zulässt.

PDF/UA wirft mehrere Fragen auf

Die Anforderungen von PDF/UA sowie die im Matterhorn-Protokoll vorgesehene Prüfung durch Software werfen zahlreiche Fragen auf:

• Warum sollen eindeutige und aussagekräftige Linktexte überhaupt noch zwingende alternative Beschreibungen erhalten müssen, z.B. aus Überschriften erzeugte klickbare Inhaltsverzeichnisse?
• Was ist bei bereits eindeutigen, sprechenden Linktexten der konkrete Mehrwert für die Barrierefreiheit und vor allem: Was ist dann das konkrete Problem der Barrierefreiheit, das damit gelöst wird?
• Was soll in den alternativen Beschreibungen stehen, z.B. bei sprechenden Links in Inhaltsverzeichnissen und Fließtexten?
• Warum ist nur die Prüfung durch Software vorgesehen? Eine Software kann erkennen, ob der Contents-Schlüssel verwendet wurde. Eine Software kann aber nicht erkennen, ob die konkrete alternative Beschreibung überhaupt sinnvoll ist. Das kann nur ein Mensch.
• Warum muss eine Technik verwendet werden, die nicht von jedem Screenreader unterstützt wird? Der Screenreader NVDA ignoriert im Gegensatz zu JAWS den Contents-Schlüssel. Selbst, wenn tatsächlich aus Gründen der Barrierefreiheit eine alternative Beschreibung nötig wird, dann sind NVDA-Nutzer außen vor. Auch wenn hier die Antwort wohl in PDF 1.7 begründet ist.

Da das Matterhorn-Protokoll keine Antworten bietet, aber selber Links enthält, werfen wir einen Blick in das PDF des Matterhorn-Protokolls.

Alternative Beschreibungen von Link-Annotationen im Matterhorn-Protokoll

Das Matterhorn-Protokoll – gemäß Prüfung mit PAC 2.0 und PAC 3.0 ein 0-Fehler-Dokument – enthält 41 Links:

• 39 interne Links im Inhaltsverzeichnis, erstellt wie allgemein üblich aus den Überschriften und Zwischenüberschriften.
• Einen externen Link mit dem Linktext „www.pdfa.org“ und
• Einen weiteren externen Link mit dem Linktext „PDF/UA kompakt“

Die alternative Beschreibungen im Contents-Schlüssel sind:

• Für die 39 Links im Inhaltsverzeichnis werden die schon im Dokument vorhandenen Linktexte wiederholt.
• Für den ersten externen Link besteht die alternative Beschreibung ebenfalls aus einer Wiederholung des Linktexts – ergänzt um „http://“.
• Als Alternative Beschreibung für den Link wird der URI des Linkziels verwendet.

Die Umsetzungen beantworten die gestellten Fragen nicht, denn welcher Mehrwert für die Barrierefreiheit wird durch bloße Wiederholungen geschaffen? Vor allem aber: Welcher „Fehler der Accessibility“ wird damit korrigiert? Das betrifft nicht nur die Links im Inhaltsverzeichnis; auch für die anderen beiden Links stellen sich diese Fragen.

Schließlich ist der Contents-Schlüssel selber hinsichtlich des praktischen Nutzens für blinde Leser fragwürdig und dies auch und insbeesondere dann, wenn Links tatsächlich unklar sind. Wie oben erwähnt ignoriert der Screenreader NVDA den Contents-Schlüssel – im Unterschied zum Alternativtext. JAWS wertet den Contents-Schlüssel aus und zwar so (geprüft mit JAWS 17): Beim Ansteuern über die Tab-Taste wird der Linktext vorgelesen. Beim zeilenweise Lesen werden Linktext und Inhalt des Contents-Schlüssels vorgelesen. Das bedeutet allerdings für die bloßen Wiederholungen im Inhaltsverzeichnis des Matterhorn-Protokolls, dass zwei Mal exakt der gleiche Text vorgelesen wird.

Auch wenn zukünftig der Alternativtext verwendet werden kann, bleiben grundsätzliche Fragen zu Sinn und praktischem Nutzen einer solchen generalisierten Anforderung bestehen.

Kompatibilität WCAG 2.0, BITV 2.0 und PDF/UA

Letztlich muss man wohl sagen, dass hier nichts mit nichts kompatibel ist und zudem sowohl die BITV 2.0 als auch PDF/UA-1 die WCAG 2.0 nicht ergänzen, sondern durch gravierende und wiederum nicht identische Anforderungen überschreiben. Enthält ein PDF Links, dann kann es nur konform mit WCAG 2.0 (und der europäischen Richtlinie), BITV 2.0 und PDF/UA-1 sein, wenn alle Linktexte immer aussagekräftig und eindeutig sind und sie zudem noch zusätzliche Einträge im Contents-Schlüssel bzw. Alternativtext haben.

Persönliche Bewertung

Für die Barrierefreiheit von PDF-Dokumenten löst eine generell-zwingende alternative Beschreibung – sei sie im Contents-Schlüssel oder im Alternativtext – in vielen Fällen weder ein Problem, noch wird ein Mehrwert geschaffen.

Würde PDF/UA verbindlich werden – sei es in Kombination mit WCAG 2.0 oder ohne – könnten die Folgekosten insbesondere bei Hochrechnung wohl deutlich werden. Das betrifft nicht nur, aber vor allem auch den oft und alltäglichen verwendeten Weg von Word zu PDF. Denn entweder man kauft eine weitere kostenpflichtige Software (für jeden Dokumentersteller?!), die das automatisch setzt oder arbeitet händisch in Acrobat Pro nach. (Hinweis: In Word 365 ist es möglich, einen Eintrag im Contents Key über Ausfüllen der QuickInfo eines Links zu erzeugen) Freilich, für bestimmte Fälle gibt es Workarounds. Ein Inhaltsverzeichnis muss nicht zwingend klickbar sein und der direkte Sprung zu einem bestimmten Inhalt kann über Lesezeichen sichergestellt werden. Will man keine überflüssigen Umsetzungen machen, dann bliebe einem noch der Verzicht auf jegliche Link-Annotationen – aus mehr als einem Grund ist das aber natürlich keine Alternative. Aber will man so arbeiten?

Muss immer eine zusätzliche alternative Beschreibung gegeben werden, dann schafft das für die redaktionelle Arbeit weder hinsichtlich sprechender Linktexte noch hinsichtlich aussagekräftiger Überschriften – relevant für klickbare Inhaltsverzeichnisse besondere Anreize.

Auch wenn zukünftig der leichter umsetzbare Alternativtext nach PDF/UA erlaubt sein sollte: Der „Zwang“ dazu kann sich als potenzielle Fehlerquelle entpuppen. Denn es besteht die Gefahr, dass eindeutige Linktexte durch weniger eindeutige überschrieben werden. Dies würde erst Screenreader-Nutzern auffallen, da das eine Software nicht prüfen kann.

Sind Linktexte eindeutig, dann werden sie ohne zusätzliche Beschreibung dennoch als „Fehler“ in der Prüfung mit PAC 2.0 und PAC 3.0 abgestraft. Das ist zwar formal-logisch, wenn PDF/UA das so vorgibt, hat aber nicht automatisch auch etwas mit Barrierefreiheit zu tun. Ein Dokument mit mehreren hundert Fehlern in PAC 2.0 oder PAC 3.0 für fehlende Beschreibungen von Link-Annotationen kann für Menschen mit Behinderungen und vor allem auch Screenreader-Nutzern völlig problemlos sein und müsste bei PDF/UA-Verbindlichkeit dennoch nachbearbeitet werden. Umgekehrt kann ein Dokument mit überflüssigen oder sogar unsinnigen zusätzlichen Beschreibungen mit 0 Fehlern aus einer solchen automatisierten Prüfung kommen.

Hinweis: Alle Artikel auf dieser Website sind kostenlos verfügbar. Ich freue mich jedoch über Zahlungen in meine Kaffeekasse über Paypal.