Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Die etwas besseren Listen - Teil 1

Wir haben noch nicht alle älteren Artikel nachbearbeitet. Das bezieht sich in der Regel nur auf die Codebeispiele, die noch nicht optimal dargestellt werden.

Die etwas besseren Listen - Teil 1

Listen sind mittlerweile eine Selbstverständlichkeit in standardkonformem Webdesign, aber Liste ist nicht gleich Liste. Dieser Beitrag von Jan Eric Hellbusch geht auf konkrete Aspekte der Barrierefreiheit von Aufzählungen ein.

Standardkonformes HTML ist mitunter eine Voraussetzung für barrierefreies Webdesign. Dabei sind HTML-Elemente nur dafür zu verwenden, wofür sie gedacht sind. Absätze sollen mit dem P-Element, Überschriften mit einem der sechs Überschriftenelemente H1 bis H6 und Listen mit einer der drei Listentypen UL, OL und DL strukturiert sein. Soweit wird jeder folgen können, aber Liste ist nicht gleich Liste und Standardkonformität erst recht nicht gleich Barrierefreiheit.

Verschiedene Listentypen

Die HTML-Listenelemente sollen für die Auszeichnung von Listen im Inhalt eines Webdokuments genutzt werden. HTML bietet dabei genau drei Listentypen:

Aufzählung
UL = unordered list mit LI-Elementen für die einzelnen Listeneinträge
Nummerierung
OL = ordered list mit LI-Elementen für die einzelnen Listeneinträge
Definitionsliste
DL = definition list für Begriffe (DT = definition term) und Erklärungen (DD = definition data)

Für alle drei Listentypen gibt es zahlreiche Aspekte der Barrierefreiheit, die berücksichtigt werden sollten. In diesem Beitrag wird allerdings nur die Aufzählung behandelt.

Listen ohne definierte Ordnung

Wenn mindestens 2 Texte aufgelistet werden und diese keine klar definierte Ordnung haben, so sind diese Texte als Aufzählung auszuzeichnen. Das folgende Beispiel ist eine einfache Aufzählung:

<ul>
  <li>HTML</li>
  <li>CSS</li>
  <li>JavaScript</li>
</ul>

Eine solche Liste ist standardkonform, aber wie sieht es mit der Barrierefreiheit aus? Eben, je nach dem, wie die Aufzählung gestaltet werden soll oder was sie beinhaltet. An einigen einfachen Beispielen werden im Folgenden Anforderungen der Barrierefreiheit vorgestellt.

Gestaltung von Aufzählungszeichen

In einem grafischen Browser werden standardmäßig die einzelnen Aufzählungspunkte mit einem ausgefüllten Kreis vorangestellt und die Texte eingerückt. Selbstverständlich können die Listen mit CSS gestaltet werden, einschließlich des Aufzählungszeichens. Mit der CSS-Eigenschaft list-style-type können verschiedene standardmäßige Aufzählungspunkte für Listeneinträge bestimmt werden:

Verschiedene Aufzählungszeichen mit list-style-type Der Standardwert für das Aufzählungszeichen ist disc. Mit dem Wert circle wird ein Kreis und mit square ein gefülltes Quadrat erzeugt. Der Wert none unterdrückt das Aufzählungszeichen.

Normalerweise stellt die Verwendung verschiedener Aufzählungszeichen kein Problem dar, allerdings werden die Aufzählungszeichen in Screenreadern unterschiedlich behandelt. Während die Screenreader JAWS und Supernova die einzelnen Aufzählungspunkte nicht unterscheiden, ersetzt Window Eyes 6.1 den Standardwert mit einem "s", den Kreis mit einem "k", den Quadrat mit einem "q" und unbekannte Zeichen mit einem "?". Der Webformator 2.3 für die Screenreader Blindows und Virgo unterscheidet Listen nicht von anderen Texten und stellt die einzelnen Listeneinträge ohne Aufzählungszeichen quasi als eigener Absatz dar.

Mit der CSS-Eigenschaft list-style-image können auch eigene Grafiken als Listenpunkte eingebunden werden:

.myclass {
  list-style-image: url(bild.gif);
}

Probleme mit der Darstellung von Grafiken als Aufzählungszeichen sind bekannt: Insbesondere werden die Ersatzgrafiken unterschiedlich ausgerichtet. Während Internet Explorer die Grafiken oben ausrichtet, wird beispielsweise in Firefox ein grafisches Symbol vertikal mittig angezeigt. Screenreader werden naturgemäß mit der CSS-Grafik nichts anfangen können.

Eine Alternative ist das Ausblenden des Aufzählungszeichens und die Verwendung eines exakt positionierbaren Hintergrundbildes. Der Nachteil von Hintergrundbildern ist aber, dass sie für Sehbehinderte mit benutzerdefinierten Bildschirmeinstellungen nicht wahrnehmbar sind. Auch hier gilt: Screenreader können mit CSS-Grafiken nichts anfangen.

Zwei Listen jeweils bei Standardeinstellungen und benutzerdefinierten Farben Die ersten beiden Bilder zeigen Listen, die mit list-style-image gestaltet wurden; bei invertierten Bildschirmdarstellungen sind die Bilder noch zu sehen. In den letzten beiden Bildern wurden die Grafiken als Hintergrundgrafik eingebunden; bei benutzerdefinierten Farben sind die Grafiken nicht mehr erkennbar.

Wenn also Listenpunkte mit CSS gestaltet werden, dann sollten die Grafiken als Ersatz für Listenpunkte und nicht als Hintergrundgrafiken eingebunden werden. Probleme mit der Positionierung sollten durch den Zuschnitt der Grafik kompensiert werden.

Die Zugänglichkeit für Screenreader ist allerdings noch nicht gelöst. Handlungsbedarf besteht dann, wenn die Grafiken eine Information vermitteln.

Symbole als Informationsträger

Nun können solche Grafiken unterschiedlich eingesetzt werden und — je nach dem — können sie eine Barriere bedeuten oder nicht. Wenn die Listenpunkte alle einheitlich "aufgehübscht" werden, dann sind die einzelnen Grafiken normalerweise keine Informationsträger und müssen nicht unbedingt weiter verarbeitet werden.

Im letzten Beispiel mit den Hintergrundgrafiken handelt es sich offenbar um eine seiteninterne Navigation. Obwohl die Grafiken alle die gleiche Bedeutung haben ("seiteninterner Link"), so handelt es sich bei der Liste um eine Navigationsleiste, die im Sinne der strukturellen Navigation auch ansteuerbar sein sollte. Eine Möglichkeit ist die Berücksichtigung einer Überschrift (die selbstverständlich unsichtbar gestaltet werden kann):

<h6>Abschnitte dieser Seite</h6>
  <ul class="ueberblick">
  <li><a href="#abschnitt1">HTML</a></li>
  <li><a href="#abschnitt2">CSS</a></li>
  <li><a href="#abschnitt3">JavaScript</a></li>
</ul>

Insbesondere wenn unterschiedliche Symbole für eine Liste eingesetzt werden, d.h. mittels verschiedener Grafiken werden die einzelnen Listeneinträge unterschieden, dann müssen weitere Maßnahmen berücksichtigt werden, um die Barrierefreiheit sicherzustellen.

Eine Linkliste mit vier Links Während die ersten drei Links offensichtlich zu deutschsprachigen Seiten führen, führt der vierte Link zu einer englischsprachigen Seite.

Das, was am Bildschirm mittels CSS visualisiert wird, sollte für textbasierte Ausgaben wie Sprachausgabe und Braille auch in Textform vorliegen. Das kann mit unsichtbarem Text erfolgen:

<ul class="linkliste">
  <li class="de"><a href="http://www.barrierekompass.de">
      www.barrierekompass.de</a></li>
  <li class="de"><a href="http://bf-w.de">
      www.barrierefreies-webdesign.de</a></li>
  <li class="de"><a href="http://www.einfachfueralle.de">
      www.einfach-fuer-alle.de</a></li>
  <li class="en"><a href="http://www.webaim.org">
      <span class="unsichtbar">Englisch: </span>
      www.webaim.org</a></li>
</ul>

In diesem Beispiel wird nur der Link zur englischsprachigen Seite mit zusätzlichem Text gekennzeichnet. Das ist solange sinnvoll, wie der restliche Text der Seite in deutsch ist: Konkret soll Änderungen der Sprache verdeutlicht werden. Auf einer französischsprachigen Seite wäre die Kennzeichnung auch der Links zu deutschsprachigen Seiten sinnvoll.

Der zusätzliche Text soll insbesondere in Screenreadern ausgegeben werden, aber nicht unbedingt am Bildschirm erkennbar sein. Hierzu wird die Klasse "unsichtbar" im CSS wie folgt definiert:

.unsichtbar {
  position:absolute;
  left:-1000px;
  top:-1000px;
  width:0;
  height:0;
  overflow:hidden;
  display:inline;
}

Obwohl davon auszugehen ist, dass die Flaggen gut visualisieren, dass es sich um deutsch- bzw. englischsprachigen Links handelt, so bergen Symbole immer die Gefahr, dass ihre Bedeutung nicht vermittelt wird. Ein title-Attribut für die Listeneinträge sollte den Informationsgehalt der Symbole zusätzlich vermitteln und die Maßnahmen zur barrierefreien Gestaltung abrunden.

Schlussbemerkungen

Während die Barrierefreiheit von Aufzählungen eine vermeintlich überschaubare Aufgabe darstellt, wird es bei Nummerierungen etwas schwieriger. Die Aufzählungszeichen in OL-Listen werden standardmäßig mit arabischen Ziffern im Browser angezeigt. Mittels der CSS-Eigenschaft list-style-type können andere Aufzählungszeichen (verschiedene Buchstaben, Zahlen oder Zeichen …) anstelle der arabischen Ziffern angegeben werden. Die Mehrheit der Screenreader-Browser-Kombinationen zeigen gestaltete Aufzählungszeichen in Nummerierungen aber nicht richtig an, wie die nachstehende Kompatibilitätstabelle zeigt.

Unterstützung von Aufzählungszeichen in gängigen Web- und Screenreadern
  Firefox 21 Internet Explorer 72
JAWS 7.1 Bis auf griechische Buchstaben werden die Aufzählungszeichen richtig ausgelesen. Es werden ausschließlich arabische Ziffern vorgelesen.
JAWS 8.0 Bis auf griechische Buchstaben werden die Aufzählungszeichen richtig ausgelesen. Es werden ausschließlich arabische Ziffern vorgelesen.
Window Eyes 6.1 Bis auf griechische Buchstaben werden die Aufzählungszeichen richtig ausgelesen. Es werden ausschließlich arabische Ziffern vorgelesen.
Supernova 9 nicht kompatibel Listeneinträge werden "nur" als Objekt in einer nummerierten Liste erkannt.
Webformator 2.3 für Blindows und Virgo nicht kompatibel Listen werden nicht erkannt.

1 Firefox 2 unterstützt u.a. decimal-leading-zero (arabische Ziffern mit einer führenden Null), lower-latin (Kleinbuchstaben), lower-alpha (Kleinbuchstaben), upper-latin (Großbuchstaben), upper-alpha (Großbuchstaben), lower-roman (kleine römische Zahlen), upper-roman (große römische Zahlen) und lower-greek (griechische Buchstaben). Firefox unterstützt auch zahlreiche weitere Werte.

2 Internet Explorer 7 unterstützt arabische Ziffern, lower-alpha und upper-alpha sowie die römischen Zahlen. Alle anderen Werte werden als arabische Ziffern angezeigt.

Wir sind es gewohnt, dass alle Browser ihre Macken haben. Screenreader sind ebenfalls Anwendungen, die Probleme mit der Einhaltung von Webstandards haben. Bei der Umsetzung der Barrierefreiheit darf allerdings nicht alleine auf Softwarefehler geschaut werden, sondern es müssen die tatsächlichen Arbeitsweisen von Menschen mit Behinderungen berücksichtigt werden.

In diesem Sinne kann nur geschlussfolgert werden, dass Barrierefreiheit mit Webstandards alleine nicht erreicht werden kann. Barrierefreiheit muss getestet und erprobt werden, und die Nutzbarkeit wird stets abhängig von vielen einzelnen Faktoren sein. Die Standardkonformität ist aber ein Vehikel, um besser nutzbare Seiten und Anwendungen anzubieten.

Kommentare

Torsten
am 10.12.2008 - 10:13

Schöner Artikel! Bei dem Beispiel mit den Links zu deutschen bzw. englischen Seiten, könnte da nicht auch das Attribut "hreflang" sinnvoll sein? Ist jetzt nur auf dieses Beispiel bezogen, aber mich würde interessieren, ob Screenreader dieses Attribut auslesen und verwerten.

Permanenter Link

Gunnar Bittersmann
am 10.12.2008 - 11:32

Obwohl davon auszugehen ist, dass die Flaggen gut visualisieren, dass es sich um deutsch- bzw. englischsprachigen Links handelt, […]

Warum sollte davon auszugehen sein? Flaggen stehen für Staaten, nicht für Sprachen. Es gibt keine Symbole für Sprachen.

Flaggen als Sprachsymbol – Dummheit oder Beleidigung?

Torsten schrieb:

Bei dem Beispiel mit den Links zu deutschen bzw. englischen Seiten, könnte da nicht auch das Attribut "hreflang" sinnvoll sein?

Das 'hreflang'-Attribut trüge aber das 'a'-Element, nicht das 'li'-Element. Dummerweise gibt es IrgendEinen Browser, der Attributselektoren à la 'a[hreflang="en"]' nicht versteht.

Permanenter Link

Torsten
am 10.12.2008 - 14:37

@Gunnar: Ja, die dumme Sache mit den Attributselektoren im IE ist mir bekannt, aber meine Frage war, ob damit die Screenreader vielleicht etwas anfangen können. Da kenne ich mich nämlich nicht mit aus, im Gegensatz zum Autor des Artikels.

Permanenter Link
Sylvia Egger

Sylvia Egger
am 10.12.2008 - 16:02

@Gunnar & Torsten
Hier muss unterschieden werden: hreflang ist ein Attribut des Link-Elements, das den Sprachwechsel anzeigt. Daher würde man in dem Beispiel mit der externen englischen Verlinkung tatsächlich semantisch korrekt hreflang=en angeben müssen. Ich habe das gerade mit JAWS getestet, im Link wird das hreflang nicht angesagt. Ich muss aber jetzt für eine genauere Analyse gerade passen.

Was Hellbusch hier macht, ist also einen versteckten SPAN mit dem Sprachhinweis einzubauen. Ich würde dann lieber auf das TITLE-Attribut des Links zurückgreifen und ein semantisches hreflang für den User-Agent verwenden. Auch wenn in Screenreadern das auch wieder problematisch ist, weil das TITLE-Attribut nicht immer in der Default-Einstellung ausgegeben wird.

Aber mir widerspricht es dann doch - und etwa in Blogs kommen fremdsprachige Verlinkungen en masse vor -, dafür immer einen SPAN mit dem Sprachhinweis zu verwenden. Vielleicht könnte man hier dann doch mal einräumen, "until user-agents" das hreflang korrekt ansagen.

Permanenter Link
Peter Rozek

Peter Rozek
am 12.12.2008 - 09:11

JAWS, Windows-Eyes und der frei verfügbare Screenreader NVDA können das Attribut hreflang nicht lesen.

Permanenter Link

Jan Eric Hellbusch
am 06.01.2009 - 15:11

@Torsten: hreflang wäre richtig, wird von Screenreadern allerdings nicht unterstützt. Auch wenn es funktionieren würde, wäre der Nutzen von hreflang erstmal sehr eingeschränkt, denn eigentlich müssten Browser das Attribut unterstützen, damit jeder den Zugriff auf die Information hat.

Obwohl manche die Flaggen als Beleidigung empfinden(s.o.), so dienen die Flaggen auch den Sehenden bei der Entscheidungsfindung. Die Angabe der natürlichen Sprache ist nicht nur für Screenreadernutzer sinnvoll.

Permanenter Link

Die Kommentare sind geschlossen.