sprungmarker testet

Der Knackpunkt: Verlinkungen

Im Text haben wir mehrere Kombinationen und Positionen zu Testzwecken verlinkt, wie die gesamte Überschrift, nur einen Teil der Überschrift und einen Teil im Absatz.

Seit jeher sind Verlinkungen bei diesen Techniken problematisch, meisthin empfiehlt der Anbieter selbst, keine Verlinkungen zu setzen. Sieht man sich jedoch die Praxis an, werden sehr wohl Überschriften verlinkt oder im Fließtext Verlinkungen genutzt. Selbst beim Einsatz von lettering.js, das sich gerne als hübsche Einzelanwendung sieht, ist in den Beispielseiten zu erkennen, dass Links da eine große Rolle spielen. So werden etwa durchaus Überschriften von Teasern verlinkt und die Beispiele sind weit entfernt von einem nur wortweisen Schmuckeinsatz.

Bei lettering.js ist es problematisch im Kontext zu verlinken, den man auch mit der Technik bearbeitet. Dabei treten Effekte auf wie, dass der Link gar nicht mehr vorhanden ist oder nur ab und an. Der Link innerhalb der Überschrift wird erkannt, aber nicht der im Absatz. Das dürfte wohl daran liegen, dass der Link nur dann erkannt wird, wenn er auch bei der Manipulation direkt angesprochen wird. Wird in einem Absatz, der insgesamt manipuliert wird, eine Verlinkung gesetzt, wird diese schlicht ignoriert.

Bei cufón muss man explizit den Hover-Effekt für ein Element angeben, per Default ist der deaktiviert, bei typeface.js hat es ne Weile gedauert, bis der Hover-Zustand implementiert wurde.

Wir sehen uns nun folgende Problemstellen bei Verlinkungen an:

• Visuelle Darstellung der Verlinkungen
• Fokus mit Tastatur
• Bedienung mit Screenreadern

Problem: Visuelle Darstellung

Die Verlinkungen wurden mit Hilfe von CSS auf unterstrichen gesetzt. Dann wurde ohne CSS getestet, ob die Verlinkungen mit Hilfe des Browser-Defaults auf unterstrichen gesetzt werden – beispielhaft wurde das im FF 4 und Safari 5 getestet. Und dazu immer im Vergleich ein Textbeispiel ohne Schriftersetzung oder Schriftmanipulation.

Technik	Link	unterstrichen mit CSS FF	unterstrichen mit CSS Safari	Default FF	Default Safari
cufón	ja	ja	nein	ja	nein
typeface.js	ja	ja	2 x	ja	2 x
lettering.js	ja	ja	nein	ja	nein

Man könnte sicherlich noch weitere Browser hinzuziehen, aber was erkennbar ist, jeder Browser interpretiert Verlinkungen anders, egal ob mit CSS gekennzeichnet oder nicht. Also ein ziemlich willkürliches Unterfangen. Dazu kommt noch, dass typeface.js nicht funktioniert, wenn man Überschriften verlinkt. Der Hover-Effekt greift in beiden Browsern.

Problem: Fokus mit Tastatur

Mit keiner der Schriftersetzungs- und manipulations-Techniken lässt sich der Fokus bei Tastaturnutzung gut setzen. Wir haben bei Fokussetzung auf den Link per CSS den Hintergrund auf rot und die Schriftfarbe auf weiß gesetzt. Verändert sollte also werden: Hintergrundfarbe und Textfarbe bei Linkzustand :focus und :active und für :visited sollte nur die Textfarbe greifen.

Technik	Zustand focus	Zustand active	Zustand visited
cufón	nein (nur Hintergrund)	nein (nur Hintergrund)	nein (nur Hintergrund)
typeface.js	nein (nur Hintergrund)	nein (nur Hintergrund)	nein (nur Hintergrund)
lettering.js	ja	ja	ja

Einzig lettering.js zeigt den Farbwechsel von Hintergrund und Textfarbe richtig für alle Linkzustände an. cufón und typeface.js reagieren nur mit der Hintergrundfarbe, die Textfarbe bleibt eisern bei der einmal per CSS gesetzten, ist also für alle Linkzustände unveränderbar gleich. Und weil sich die Textfarbe nicht mit ändert, ist man in der Auswahl der Kontrastkombinationen dann sehr eingeschränkt. In Verbindung mit der je Browser unterschiedlichen Setzung von Unterstreichungen ist man dann schnell am kombinatorischen Ende.

Problem: Bedienung mit Screenreadern

Für Screenreader ist die Interpretation von Verlinkungen in Kombination mit cufón, typeface.js oder lettering.js eine Herausforderung. Einerseits wird die Verlinkung als Herkömmliches immer erkannt – Cobra erkennt ja nur die Verlinkungen des Textes -, andererseits entstehen durch die je unterschiedliche Technik Barrieren und Interpretationsunterschiede.

Wir testen ob:

• Link erkannt wird
• das TITLE-Attribut wiedergegeben wird
• alles flüssig vorgelesen wird

Verlinkungen und JAWS

Technik	Link erkannt	TITLE-Attribut	Vorlesegeschwindigkeit
cufón	ja	ja	flüssig
typeface.js	ja	ja	flüssig
lettering.js	ja	ja	flüssig

JAWS kommt auch bei den Verlinkungen am besten zurecht, hat keinerlei Probleme. Mit lettering.js wird die Verlinkung im Absatz nicht vorgelesen.

Verlinkungen und NVDA

Technik	Link erkannt	Vorlesegeschwindigkeit
cufón	ja (wortweise)	ja (wortweise)
typeface.js	ja	ja
lettering.js	nein (pro Buchstabe)	nein (pro Buchstabe)

NVDA hat die gleichen Probleme mit Verlinkungen wie auch mit dem Rest der Techniken. Am schlechtesten schneidet lettering.js ab, hier wird die Verlinkung Buchstabe für Buchstabe vorgelesen. Bei cufón wird die Verlinkung auch wortweise vorgelesen, nur wenn man per Tastatur von Link zu Link springt, dann wird der Linktext insgesamt vorgelesen.

Verlinkungen und VoiceOver (mittlere Ausführlichkeit)

Technik	Link erkannt	TITLE-Attribut	Vorlesegeschwindigkeit
cufón	ja	ja	flüssig (bleibt aber auch mitunter hängen)
typeface.js	ja	ja	flüssig
lettering.js	nein (pro Buchstabe)	ja	nein (pro Buchstabe)

VoiceOver hat ja grundsätzlich Probleme mit diesen Techniken und so treten auch bei den Verlinkungen ähnliche Probleme auf. Interessanterweise kommt VoiceOver mit cufón und typeface.js sonst nicht zurecht, nur die Verlinkungen werden korrekt wiedergegeben. Bei Verlinkung innerhalb der Überschrift bleibt er gerne mal stehen. Die Verlinkungen im Absatz werden ignoriert. Bei lettering.js werden die Verlinkungen pro Buchstabe vorgelesen.

Insgesamt ist die Unterstützung von Verlinkungen nicht wirklich besser, nur mitunter werden Verlinkungen eher unterstützt als der Rest – etwa wenn man mit der Tastatur unterwegs ist. Auch dass Screenreader – außer JAWS – immer mal an einem Element schlicht hängen bleiben, ist im Gesamtkontext nicht neu.

Einige Audiobeispiele zu den Verlinkungen:

• Verlinkungen: Tonbeispiel VoiceOver und lettering.js (141 Kb, 16 Sekunden)
• Verlinkungen: Tonbeispiel NVDA und cufón (102 Kb, 10 Sekunden)

Zusammenfassung

Wie bei anderen Schriftersetzungen auch ist also von einem Einsatz solcher Techniken im Hinblick auf die Barrierefreiheit abzuraten. Das mag jetzt ein erwartetes Ergebnis sein, aber im Einzelergebnis überrascht JAWS mit seiner umfassenden Unterstützung und lettering.js hat die meisten Vorteile hinsichtlich der Barrierefreiheit, eignet sich aber in der Summe letztlich dann auch nicht.

Es bleibt ohnehin zu hoffen und abzuwarten, dass sich die Schrifteinbindung mit Hilfe von font-face flächendeckend durchsetzt und wir auf solche Hilfskonstruktionen verzichten können. Was Manipulationen wie lettering.js angeht, bleibt die Hoffnung, dass sich ein Rückkanal bildet und sich Änderungen im Hinblick auf Barrierefreiheit einarbeiten lassen. Die Frage bei lettering.js ist halt, wo braucht man das konkret und wie kann man es ändern, damit es barrierefreier wird. Die Hauptprobleme dieser Technik ergeben sich vor allem durch die Nutzung mit Screenreadern.