Links mit ARIA verstecken  

Manchmal müssen (oder sollten) Inhalte vor Screenreadern versteckt werden, die am Bildschirm sichtbar sind. In diesem Beitrag geht es um redundante Links, die mit tabindex=“-1“ zwar im Browser nicht mehr fokussierbar werden, aber dennoch für Screenreader zugänglich bleiben. Die ARIA-Spezifikation sieht zwei Möglichkeiten vor, solche Links auch vor Screenreadern zu verstecken:

1. Mit aria-hidden=“true“ soll ein Element samt Kindelemente und enthaltener Text vor Screenreadern versteckt werden.
2. Mit role=“presentation“ (ARIA 1.0) bzw. role=“none“ (ARIA 1.1) soll die Semantik des Elements unterdrückt werden, aber Kindelemente und enthaltener Text für Screenreader zugänglich bleiben.

Hinweis: ARIA-Attribute beeinflussen die Darstellung und Funktionsweise von Inhalten in Browsern nicht. Sie stellen eine Anweisung an den Browser dar, wie der Accessibility-Tree des Betriebssystems zu befüllen ist.

Getestete Browser und Screenreader

Auf Windows 10 wurden die folgenden Browser getestet:

• Internet Explorer 11,
• Microsoft Edge 25,
• Firefox 47 und
• Chrome 52

Folgende Screenreader wurden getestet:

• JAWS 17
• Cobra 11
• Window Eyes 9.2
• NVDA 2016.2 und
• ChromeVox 53.0 (nur auf Google Chrome)

Darüber hinaus wurde Safari mit VoiceOver auf iOS 9.3 getestet.

Testszenarien

Auf einer Seite befinden sich zwei Links mit identischem Ziel (z.B. Überschrift und Grafik in einem Anreißertext). Beide Links sind anklickbar, aber für Tastaturnutzer und Screenreadernutzer soll es nur einen Link geben. Der erste Link soll per Tastatur und Screenreader nicht mehr zugänglich sein:

<p><a href="seite.html"><img src="bild.png" alt="Funktionaler Alternativtext"></a></p>
<h2><a href="seite.html">Überschriftentext</a></h2>

Folgende Tests wurden durchgeführt:

1. Um die Nutzbarkeit für Tastaturnutzer zu optimieren, wird der Link mit tabindex=“-1“ aus der Fokus-Reihenfolge entfernt:

   <p>
<a tabindex="-1" href="seite.html">
<img src="bild.png" alt="Funktionaler Alternativtext">
</a>
</p>

   Die erwarteten Ergebnisse sind:

   • Im Browser ist der Link mit tabindex=“-1“ per Tastatur (Tab-Taste) nicht zugänglich.
   • In Screenreadern wird nach wie vor ein Link mit Linktext erkannt.
   • Screenreadernutzer können den Link anspringen und mit der Eingabetaste aufrufen.

   [Testseite mit tabindex=“-1“]

2. Der Link mit tabindex=“-1“ wird ergänzt um aria-hidden=“true“:

   <p>
<a aria-hidden="true" tabindex="-1" href="seite.html">
<img src="bild.png" alt="Funktionaler Alternativtext">
</a>
</p>

   Erwartete Ergebnisse sind:

   • Screenreader erkennen weder den Link noch die Grafik.
   • Screenreader erkennen den Link und die Grafik auch nicht an, wenn aria-hidden=“true“ auf ein Elternelement des Links (z.B. auf das <p>) gesetzt wird.

   [Testseite mit aria-hidden=“true“]

3. Statt aria-hidden wird der Link mit role=“presentation“ ergänzt.

   <p>
<a role="presentation" tabindex="-1" href="seite.html">
<img src="bild.png" alt="Funktionaler Alternativtext">
</a>
</p>

   Erwartete Ergebnisse sind:

   • Screenreader erkennen den Link nicht, aber die Grafik wird semantisch und anhand ihres Alternativtexts identifiziert. Ist der Alternativtext leer, wird auch die Grafik ignoriert.
   • Der Link ist nicht mehr anspringbar, aber aufrufbar.

   [Testseite mit role=“presentation“]

4. Statt aria-hidden wird der Link mit role=“none“ ergänzt.

   <p>
<a role="none" tabindex="-1" href="seite.html">
<img src="bild.png" alt="Funktionaler Alternativtext">
</a>
</p>

   Erwartete Ergebnisse sind:

   • Screenreader erkennen den Link nicht, aber die Grafik wird semantisch und anhand ihres Alternativtexts identifiziert. Ist der Alternativtext leer, wird auch die Grafik ignoriert.
   • Der Link ist nicht mehr anspringbar, aber aufrufbar.

   [Testseite mit role=“none“]

Hinweis: Formal gibt es keinen Unterschied zwischen role=“presentation“ und role=“none“. Erster Wert wurde in der ARIA 1.0 Spezifikation festgelegt. Da es offenbar Unklarheiten über die Bedeutung des Werts gab, wird in ARIA 1.1 der Wert in „none“ umbenannt.

Ergebnisse

Ergebnisse – Unterstützung der Browser/Screenreader

Getestete Attribute
tabindex="-1"
aria-hidden="true"
presentation
none
CSS

Hinweise:

• Mit Cobra bleiben Links trotz tabindex=“-1“ fokussierbar (alle Browser). Erst mit aria-hidden=“true“ oder role=“presentation“ bzw. role=“none“ wird der Link aus der Fokus-Reihenfolge entfernt (außer in Chrome, wo mit einem role-Attribut der Link fokussierbar bleibt). Mit Window Eyes und NVDA stehen Links mit tabindex=“-1“ unter bestimmten Voraussetzungen ebenfalls in der Fokus-Reihenfolge (z.B. per Tab-Taste vorwärts und mit Pfeiltasten zurück navigieren und anschließend wieder mit Tab-Taste vorwärts navigieren).
• In Chrome und Firefox gab es mehrere Unregelmäßigkeiten mit JAWS beim Einsatz des role-Attributs. Die Links mit role wurden teilweise identifiziert und in bestimmten Situationen sogar per Tab-Taste fokussiert. Mit Window Eyes ist das gleiche Phänomen mit Internet Explorer festzustellen.
• Obwohl Microsoft Edge in den letzten 12 Monaten große Fortschritte in Sachen Zugänglichkeitsunterstützung gemacht hat, wird Edge allgemein noch nicht von Screenreadern unterstützt. NVDA ist der einzige Screenreader, der eine minimale Bedienung von Edge erlaubt. Cobra teilt dem Nutzer mit, dass es keine Unterstützung gibt.
• Mit VoiceOver auf iOS werden die Links immer erkannt. Auch mit aria-hidden=“true“ kann der Link per Tastatur aufgerufen werden.

Schlussfolgerungen

Die zuverlässigste Technik, einen Link aus der Fokus-Reihenfolge zu entfernen, ist sowohl tabindex=“-1“ als auch aria-hidden=“true“ auf den Link zu setzen. Mit role=“presentation“ oder role=“none“ in Verbindung mit tabindex=“-1“ werden Links nicht zuverlässig aus der Fokus-Reihenfolge entfernt.

Statt mit tabindex und aria-hidden zu arbeiten gibt es auch andere Techniken, doppelte Links zu vermeiden. Sowohl Event-Handler als auch CSS kommen dafür in Frage.