X Nur am Bildschirm zugänglich – Unsichtbare Texte — mit HTML, CSS oder ARIA? – [barrierefreies-webdesign.de]

Barrierefreies Webdesign ein zugängliches und nutzbares Internet gestalten

Unsichtbare Texte veröffentlicht in 2012zuletzt bearbeitet in 2018

Nur am Bildschirm zugänglich

Im barrierefreien Webdesign gilt normalerweise, dass sichtbare Inhalte genauso auf der HTML-Ebene nachvollziehbar sein müssen. Das gilt nicht nur für Strukturen (etwa Überschriften oder Listen), sondern für alle Informationen und visuell erkennbare Beziehungen.

Dennoch gibt es Situationen, in denen Informationen redundant eingesetzt werden. Es kann sinnvoll sein, redundante Inhalte vor allem für Screenreadernutzer zu vermeiden. Für solche Fälle gibt es verschiedene Techniken. Insbesondere bieten Accessible Rich Internet Applications (ARIA) das aria-hidden-Attribut. Dieses Attribut ist mit äußerster Vorsicht einzusetzen, was im Übrigen auch für role="presentation" bzw. role="none" gilt.

Vorab: Eine HTML-Technik

Wann Inhalte vor dem Accessibility-Tree verborgen werden müssen, lässt sich nicht eindeutig abgrenzen. Es gibt einige Inhalte, in denen Informationen doppelt vorkommen. Ein typisches Beispiel ist ein Link mit einem vorangestellten Icon.

Suchfeld mit Suchbutton, wobei der Suchbutton aus einem Lupensymbol und den Text 'Suchen' besteht

In diesem Beispiel benötigt das Symbol keine Textalternative. Symbol und Text bilden eine Einheit für die Schaltfläche und der Text "Suchen" stellt einen geeigneten Namen für die Schaltfläche dar. Sofern die Grafik im HTML steht, kann sie mit einem leeren Alternativtext vor dem Accessibility-Tree verborgen werden:

<button>
  <img alt="" src="lupe.png"> Suchen
</button>

Damit Screenreader die Grafik ignorieren, ist in diesem Beispiel die HTML-Technik mit einem leeren Alternativtext zu bevorzugen. In anderen Situationen stehen HTML-Techniken nicht zur Verfügung und CSS- oder ARIA-Techniken müssen zum Einsatz kommen.

Das aria-hidden-Attribut

Das aria-hidden-Attribut dient dazu, Inhalte vor dem Accessibility-Tree zu verbergen, unabhängig davon, ob sie am Bildschirm sichtbar sind oder ob es sich um interaktive Elemente (wie Links) handelt. Ein Element mit aria-hidden="true" und alle seine Kindelemente werden nicht an den Accessibility-Tree übertragen:

<p aria-hidden="true">Dieser Inhalt ist nur am Bildschirm zugänglich.</p>

Beim Einsatz von aria-hidden gibt es zwei Aspekte, die besonders beachtet werden müssen:

  1. Interaktive Elemente dürfen nicht auf diese Weise versteckt werden, denn die Elemente bleiben nach wie vor in der Fokus-Reihenfolge (der Fokus ist eine Browserfunktion und das Drücken der Tab-Taste setzt den Fokus auf das nächste interaktive Element auch dann, wenn das Element mit aria-hidden="true" nicht im Accessibility-Tree steht).
  2. Derzeit kann ein Element innerhalb eines anderen Elements mit aria-hidden="true" nicht mit aria-hidden="false" für Screenreader wieder zugänglich gemacht werden. aria-hidden="false" ist von Browsern nicht implementiert.

Analog zu dem Beispiel mit der Schaltfläche oben, aber dieses Mal ohne ein IMG-Element, kann aria-hidden genutzt werden, um einen Inhalt vor dem Accessibility-Tree zu verbergen:

<button>
  <svg class="icon-search" aria-hidden="true" focusable="false">
    <!-- SVG-Code -->
  </svg> Suchen
</button>

Mit aria-hidden="true" wird die Grafik nicht mehr im Accessibility-Tree abgelegt. Das focusable-Attribut ist eigentlich nicht notwendig; im Internet Explorer verursacht eine SVG in einem aktiven Element einen weiteren Tab-Stopp.

Ein weiteres Beispiel ist die Beschriftung von Regionen, eine Region könnte eine sichtbare Überschrift enthalten. Da Regionen beschriftet werden sollten (um sie voneinander unterscheidbar zu machen), stellt sich die Frage, ob in einem Screenreader die Region anhand des Überschriftentextes identifiziert werden soll:

<nav id="breadcrumb" aria-labelledby="breadcrumb-header">
  <header>
   <h2 id="breadcrumb-header">Sie sind hier:</h2>
  </header>
  <ul>
   <li><a href="/">Startseite</a> →</li>
    <li><a href="/knowhow/">Wissen</a> →</li>
    <li><a href="/knowhow/nuetzerfuehrung/">Nutzerführung</a> →</li>
    <li><strong aria-current="true">Breadcrumbs</strong></li>
  </ul>
</nav>

Die Überschrift sollte zur Beschriftung der Region herangezogen werden. Das verursacht eine Redundanz: Screenreader würden die Region anhand der Überschrift identifizieren und dann die Überschrift selbst ausgeben. Daher darf die Überschrift für Screenreader unzugänglich gemacht werden.

<nav id="breadcrumb" aria-labelledby="breadcrumb-header">
  <header aria-hidden="true">
   <h2 id="breadcrumb-header">Sie sind hier:</h2>
  </header>
  <ul>
   <li><a href="/">Startseite</a> →</li>
    <li><a href="/knowhow/">Wissen</a> →</li>
    <li><a href="/knowhow/nuetzerfuehrung/">Nutzerführung</a> →</li>
    <li><strong aria-current="true">Breadcrumbs</strong></li>
  </ul>
</nav>

Das aria-hidden-Attribut kann sehr viel Schaden anrichten:

  1. Zum einen werden Elemente mit aria-hidden="true" und ihre Inhalte nicht nur vor Screenreadern verborgen. Es können verschiedene weitere Hilfsmittel auf den Accessibility-Tree zugreifen, etwa Vergrößerungssysteme oder Spracheingaben; es kann leicht passieren, dass der Versuch, auf sichtbaren Inhalt zuzugreifen, fehlschlägt, weil Nutzer den Bildschirm, aber Software den Accessibility-Tree benutzen. In der Regel sollte daher der Accessibility-Tree den sichtbaren Inhalt abbilden.
  2. Zum anderen ist die Überprüfung des Accessibility-Trees mit Bordmitteln des Browsers nicht möglich – es können nur die Attribute im DOM untersucht werden. Wenn Inhalte mit aria-hidden="true" vor dem Accessibility-Tree verborgen werden, sollten Entwickler zumindest ausführlich testen, ob das Attribut richtig gesetzt wird. Das kann beispielsweise im CSS wie folgt visualisiert werden:

    [aria-hidden] {
      visibility:hidden;
    }

role="presentation" und role="none"

Die beiden Rollen "presentation" und "none" haben die gleiche Auswirkungen. Die Rolle "presentation" ist der spezifizierte Wert aus ARIA 1.0, der in ARIA 1.1 in "none" umbenannt wurde. Im Folgenden kann daher role="none" wie role="presentation" gelesen werden.

Mit role="none" für ein Element wird die Rolle des Elements nicht an den Accessibility-Tree übertragen, aber die Inhalte und weitere Kindelemente schon. Im Allgemeinen sollten die richtigen HTML-Elemente von vorneherein eingesetzt werden und die Entfernung einer Rolle sollte vermieden werden. Das gilt insbesondere für interaktive Elemente. Es gibt nur wenige Situationen, in denen die Rolle eines Elements tatsächlich für den Accessibility-Tree entfernt werden sollte: Das sind zum einen Layout-Tabellen und zum anderen dekorative Grafiken (die aber auch mit einem leeren Alternativtext verborgen werden können).

Es gibt vereinzelte weitere Situationen für den Einsatz von role="none". Eine Registernavigation könnte beispielsweise im HTML wie folgt aufgebaut werden:

<ul>
  <li><a href="#inhalt1">Reiter 1</a></li>
  <li><a href="#inhalt2">Reiter 2</a></li>
  <li><a href="#inhalt3">Reiter 3</a></li>
</ul>

Dieser HTML-Konstrukt ist "lediglich" die Fallback-Lösung für den Fall, dass JavaScript nicht läuft. Mit JavaScript müsste das UL-Element die Rolle "tablist" zugewiesen bekommen und die interaktiven Elemente (hier: Links) können die Rolle "tab" erhalten. Die LI-Elemente wären dann überflüssig und– in einem Screenreader – wahrscheinlich auch störend. Die Listenrollen sollten dann entfernt werden:

<ul role="tablist">
  <li role="none">
    <a role="tab" href="#inhalt1">Reiter 1</a>
  </li>
  <li role="none">
    <a role="tab" href="#inhalt2">Reiter 2</a>
  </li>
  <li role="none">
    <a role="tab" href="#inhalt3">Reiter 3</a>
  </li>
</ul>

Auch wenn role="none" nicht ganz so viel Schaden anrichten kann wie aria-hidden="true", so ist diese Rolle dennoch sehr vorsichtig einzusetzen. Keinesfalls dard die Rolle für interaktive Elemente wie Links eingesetzt werden, denn die Elemente bleiben funktional. Links mit einer Rolle "none" wären "nur" fokussierbare Texte – die semantische Information, dass es sich um einen Link (oder ein Button oder was anderes) handelt, stünde im Accessibility-Tree nicht zur Verfügung.