Weniger ist mehr: Wenn gut gemeinte Barrierefreiheit zur Barriere wird

Vor einigen Monaten habe ich ein WCAG-Audit einer Website für einen Kunden durchgeführt. Neben einigen anderen Fehlern ist mir vor allem ein Problem in Erinnerung geblieben, das beim Screenreader-Test deutlich wurde: ein sehr generischer Alternativtext für das Logo der Website.

Beim Blick in den Quelltext, der sich in etwa wie folgt darstellte, war die Sache schnell klar:

<a class="link-no-lightbox" href="https://www.kunde.de" aria-label="krzl_favicon" role="link">
  <img width="200" height="200" alt="Kundenname" src="https://www.kunde.de/pfad/zum/logo.png" class="img-responsive lazyloaded">
</a>

Auffällig sind hier die Textalternativen. Der Alternativtext für das Logo war korrekt der Firmenname des Kunden, so wie es empfohlen wird. Normalerweise gibt die Ausgabe in Kombination mit dem Link diesen Firmennamen aus. Bei meinem Test mit der Vorlesesoftware erhielt ich allerdings nur ein leicht kryptisches „krzl_favicon“.

Der Blick in den Code machte klar, woran das lag: Der Link trägt ein aria-label, das im Accessibility Tree alle anderen Textalternativen überschreibt. Das alt-Attribut aus dem Bild wurde dadurch verdrängt, sodass nur noch die Abkürzung des Kundennamens zusammen mit dem Zusatz „Favicon“ ausgegeben wurde.

Interessant ist außerdem die role="link". Die muss hier gar nicht vergeben werden, denn ein Anchor-Element (<a>) mit href wird ohnehin automatisch als Link erkannt. Schaden richtet das explizite role an dieser Stelle nicht an, es dupliziert nur, was schon da ist. Problematisch wird dasselbe Muster, sobald die Rolle nicht mehr zum Element passt, etwa role="button" auf einem Link. Dann verschwindet er aus der Link-Liste des Screenreaders, während die eigentliche Linkfunktion (neuer Tab per Mittelklick, Adressleiste und so weiter) unverändert bleibt. Angekündigt wird ein Verhalten, das nicht eintritt.

Ohne aria-label und role hätte der Code von sich aus getan, was er sollte:

<a class="link-no-lightbox" href="https://www.kunde.de">
  <img width="200" height="200" alt="Kundenname" src="https://www.kunde.de/pfad/zum/logo.png" class="img-responsive lazyloaded">
</a>

Textalternativen: die häufigste Fehlerquelle

Textalternativen und ihre korrekte Anwendung sind eine der häufigsten Fehlerquellen, wie das Beispiel oben zeigt. Beurteilen lässt sich ein Alternativtext dabei nur im Kontext. Wenn ein Bild oder eine Grafik bereits vollständig durch den umgebenden Text wiedergegeben wird und rein illustrativ ist, kann es als dekorativ gekennzeichnet werden. Dann wird es von Screenreadern ignoriert.

Häufiger ist das Gegenteil. Der Alternativtext ist zu umfangreich, beschreibt zu viel oder wiederholt den sichtbaren Text. Nehmen wir eine Teamübersicht, in der die Namen ohnehin als Text neben dem Bild stehen. Dort braucht das Bild keinen eigenen Alternativtext, der Name würde sich doppeln und eine Beschreibung des Portraits bringt in der Regel nichts.

Ähnlich läuft es bei Produktbildern in Onlineshops oder bei automatisch erzeugten Alternativtexten, die den Bildinhalt beschreiben, obwohl der begleitende Text das Bild schon vollständig abbildet.

Wenn die Alternative mehr erzählt als das Original

An anderer Stelle habe ich schon darüber geschrieben, dass Barrierefreiheit auch heißt: nicht alles muss barrierefrei sein. Entscheidend ist, dass Inhalte über eine Alternative erreichbar sind.

Diese Alternative darf weder mehr noch weniger Informationen bieten als der nicht barrierefreie Inhalt selbst. Bestimmte Informationen oder Funktionen gesondert zu erklären oder zugänglich zu machen, kann durchaus sinnvoll sein. Nur darf der Umfang nicht so groß werden, dass Lesende mit unnötigen Zusatzinformationen überfordert werden.

Ein typischer Fall sind Inhalte, die ausschließlich für Screenreader gedacht sind, also Text, den .sr-only oder ähnliche „visually hidden“-Klassen verstecken. Inflationär eingesetzt liefert das Screenreader-Nutzenden lauter Zusatzinformationen, die sehende Nutzende nie sehen. Geholfen ist damit niemandem, die Orientierung leidet eher.

Halbe Lösungen: ARIA ohne Tastaturbedienung

Grundsätzlich gilt hier das von der WAI empfohlene „No ARIA is better than bad ARIA“ (kein ARIA ist besser als schlechtes ARIA): Wo man auf ARIA verzichten kann, sollte man das tun und stattdessen Standard-HTML-Elemente nutzen.

Häufig wird aber angenommen, dass allein das Setzen eines tabindex oder eines Ankerlinks die Funktion bereits vollständig herstellt. Bei Ankerlinks etwa sollte man auf das Ziel-Element einen negativen tabindex setzen:

<a href="#hauptinhalt" class="skip-link">Zum Hauptinhalt springen</a>
...
<main id="hauptinhalt" tabindex="-1">

In Tests und bei Beratung und Begleitung von Entwicklungsteams begegnet mir häufig, dass zwar ein tabindex gesetzt, aber vergessen wird, dass mit JavaScript auch Klick- und Key-Events dazugehören:

element.addEventListener("click", handleActivate);
element.addEventListener("keydown", (event) => {
  if (event.key === "Enter" || event.key === " ") {
    event.preventDefault();
    handleActivate();
  }
});

Die Absicht stimmt in all diesen Fällen. Erledigt ist trotzdem nur die halbe Arbeit: Das aria-label wurde gesetzt, ohne zu prüfen, was es überschreibt. Der Alternativtext entstand, ohne dass jemand auf den Kontext geschaut hat. Der tabindex steht im Markup, aber das Verhalten dazu fehlt.

Wie barrierefrei eine Seite ist, zeigt sich nicht an der Zahl der gesetzten Attribute, sondern daran, was beim Screenreader ankommt. Herausfinden lässt sich das nur durch Testen.