accessBlog

Aktuelles zum Thema Barrierefreies Webdesign.

Wie üblich haben uns auch beim letzten Relaunch viele Rückmeldungen und kritische Anmerkungen (und in seltenen Fällen sogar Lob) per E-Mail oder über die Kontakt- und Kommentarformulare erreicht. Zu einigen Punkten hatten wir ja bereits ausführlich was geschrieben; heute geht es um einen Teil des HTML-Codes dieser Seiten, der schon öfter Anlass zu Diskussionen war: die »Tag Cloud«, auch Schlagwort- oder Stichwortwolke genannt.

Laut Wikipedia ist eine Tag Cloud »eine Methode zur Informationsvisualisierung, bei der eine Liste aus Schlagworten alphabetisch sortiert flächig angezeigt wird, wobei einzelne unterschiedlich gewichtete Wörter größer oder auf andere Weise hervorgehoben dargestellt werden.« Lustigerweise ist die Tag Cloud in der linken Spalte eines der wenigen Code-Fragmente, die nicht nur den letzten Relaunch, sondern auch einige Relaunches davor unbeschadet überstanden hat – das zu Grunde liegende Konstrukt hat sich also seit Jahren nicht geändert. Aber wie bei jedem Relaunch erreichen uns wohl-gemeinte Tipps, wie man diese Tag Clouds besser umsetzen und semantisch anreichern könnte (womit sich mal wieder die alte Regel bewahrheitet, dass die Menge des Diskussionsbedarfs immer umgekehrt proportional zur Komplexität des Problems ist).

Weiterlesen …

So auch diesmal:

»… die Größe eines Links in der Tag-Cloud habt Ihr ja mit "strong in strong in strong …" realisiert. Ich habe gerade mal mit JAWS etwas herumgespielt, vor allem mit dem Konfigurationsmanager, und da keine Einstellung gefunden, mit der ich mir die Anzahl der strong-Tags vorlesen lassen kann. Daher mein Tipp: Schreibt doch die Nummer der strong-Tags als Zahl in Klammern hinter den jeweiligen Link und schiebt das dann per CSS aus dem Viewport. In der Überschrift ›Themen:‹ schreibt Ihr das halt als ›(Beliebtheit als Zahl in Klammern)‹, ebenfalls versteckt, dahinter. Das ist zwar so knapp, dass man erst nicht weiß, ob der Zahlenwert mit der Beliebtheit steigt oder ob es hier umgekehrt proportional gesehen werden muss, aber das wird spätestens bei der vier für HTML klar.«

(Detlef Girke per E-Mail)

Zum Hintergrund des ganzen: unsere Tag Cloud besteht aus einer Liste von Einträgen, die alphabetisch sortiert als Unordered List (UL) angelegt sind, jeder Eintrag steht in einem separatem List Item (LI). Wir bekamen auch einige Mails mit Vorschlägen, statt der UL doch eine geordnete Liste (OL) zu nehmen – danke für die Vorschläge, aber das Kriterium zur Sortierung der Einträge ist das Alphabet – damit sind die (zusätzlichen) Ordnungszahlen komplett überflüssig und bringen dem Nutzer keine brauchbaren Erkenntnisse.

Eine Sortierung nach Häufigkeit würde ebenfalls keinerlei Vorteile für den Nutzer bringen. Zum einen wäre für den Nutzer die Orientierung entlang des Alphabets dahin; zum anderen würde sich diese Sortierung auch laufend ändern. Ein weiteres Problem bleibt dadurch ebenfalls ungelöst: in den vergangenen Jahren haben wir sehr viel über HTML & CSS gebloggt, entsprechend viele Treffer gäbe es bei einer Sortierung nach diesen Tags. Nun gibt es aber Techniken wie z.B. WAI-ARIA, die relativ neu sind und daher in Summe nicht so häufig im Blog vorkommen – aber genau von diesen Beiträgen möchten wir, dass sich unsere Leser damit beschäftigen und eine alleinige Sortierung nach Häufigkeit käme einer Abwertung gleich und ginge somit am Ziel vorbei. Im Ernstfall würde man damit höchstens den Digg-Effekt erreichen, bei dem alle User auf das Ding mit der höchsten Zahl draufklicken.

Im Urzustand sieht unsere listenförmige Tag Cloud folgerichtig so aus:

  1. <div id="tagcloud">
  2. <h4>Themen:</h4>
  3. <ul>
  4. <li><a href="/blog/tags/ajax/" rel="tag">AJAX</a></li>
  5. <li><a href="/blog/tags/atag/" rel="tag">ATAG</a></li>
  6. [...]
  7. </ul>
  8. </div>

Allerdings ist dies noch nicht alles, und genau daran entzündet sich die Kritik: je nach Häufigkeit des Tags enthält der Link noch ein oder mehrere <strong> – je häufiger, desto mehr <strong> sind dort hineingeschachtelt:

  1. <li><a href="/blog/tags/bitv/" rel="tag"><strong><strong>BITV</strong></strong></a></li>

Durch geschicktes Ausnutzen der Vererbungen in CSS wird der enthaltene Linktext immer größer, je öfter strong ineinander verschachtelt ist:

  1. #tagcloud li strong {
  2. font-size: 1.1em;
  3. }

Nun bezieht sich einige Kritik darauf, dass <strong> unsemantisch sei – leider konnte uns jedoch bisher noch niemand eine echte, passendere Alternative aufzeigen. Kurzfristig hatten wir über die Verwendung von <small> & <big> zur Gewichtung der Einträge nachgedacht, aber dann davon abgesehen. Nicht weil es unpassend wäre (wobei: eventuell wäre es sogar passender und damit ehrlicher gewesen), sondern weil dies wohl einen Sturm der Entrüstung hervorgerufen hätte. Das Problem bleibt also: HTML bietet kein 100%-ig passendes Element zur semantisch korrekten Auszeichnung von Gewichtungen in Tag Clouds an. Also läuft es (wie so oft in HTML) auf eine Annäherung hinaus, die nach den Prinzipien der Einfachheit diejenige sein sollte, die am wenigsten stört (›least obtrusive‹) und dem Nutzer nichts vorgaukelt, das effektiv nicht vorhanden ist bzw. die Handhabung für den Nutzer nicht unnötig verkompliziert. Eben einfach.

Daher hatten wir uns damals nach intensivem Nachdenken für <strong> entschieden, eben genau weil mit <strong> ausgezeichneter Text in sämtlichen uns bekannten Screenreadern nicht anders vorgelesen wird als herkömmlicher Text ohne <strong> (wie übrigens bei <big> & <small> auch nicht, neben einer ganzen Reihe anderer, seit über einem Jahrzehnt spezifizierter Elemente).

Gleich mehrere Mails und IMs beschäftigten sich mit der Frage, ob man die Gewichtung dem Screenreader-Nutzer dann nicht besser durch die Ansage der Zahl der gefundenen Treffer mit diesem Tag mitteilen sollte. Auch mit diesem Vorschlag haben wir ein paar Probleme:

  1. Wenn die Zahlen einen Nutzwert haben sollen, dann müsste sich der Nutzer beim durchhören der Tag Cloud die Zahlen merken, dann nochmals zurückgehen und dann auf Basis der Zahlen als Entscheidungskriterium (Welcher Zahl? Der höchsten? Der niedrigsten? Dem Mittelwert?) entscheiden, welchem Link er folgt. Was aber nicht das eigentliche Problem des Vorschlags löst, nämlich:
  2. Warum sollte ein Nutzer einen Link anklicken, nur weil ihm die (hohe oder niedrige) Zahl irgendwie zusagt? Wenn jemand nach Tipps zu CSS sucht, dann ist es für ihn vollkommen unerheblich, ob da nun 2 oder 20 oder 200 Einträge dahinter sind. Weder wir noch der Benutzer können wissen, ob das Gesuchte gefunden wird (und zwar vollkommen unabhängig von der Anzahl; und nein, die Wahrscheinlichkeit das Gesuchte zu finden steigt nur unwesentlich mit der Zahl der verlinkten Blog-Beiträge).

Die wesentliche Information ist auch jetzt schon der verlinkte Text (›BITV‹, ›CSS‹, …), alles darüber hinaus wäre nicht Beiwerk oder zusätzlicher Komfort, sondern akustischer Müll. Wir glauben nicht, dass allzu viele Nutzer zu EfA kommen nur um nachzulesen, wie viel wir über ein bestimmtes Thema berichten – das ist vielleicht später mal für Archäologen interessant, aber nicht hier und jetzt für die Nutzer, die sich über bestimmte Themen informieren wollen.

Daher können wir auch den Nutzwert einiger Tutorials nicht nachvollziehen, die man zu dem Thema im Netz findet. Mark Norman Francis hatte im Dezember 2006 im Adventskalender von 24 ways eine Anleitung veröffentlicht, die nach seiner Auffassung alle Probleme löst und somit absolut barrierefrei zugänglich sei. Im fertigen Code-Beispiel stehen zusätzliche Informationen über die Anzahl zwar im HTML innerhalb des Links, diese werden aber per CSS aus dem Viewport geschoben.

In die gleiche Richtung geht ein neuerer Artikel »Semantische Tag Cloud« im SELFHTML aktuell Weblog, auf den Wolfgang Wiese per IM hinwies: auch hier werden zusätzliche (für grafische Browser wiederum versteckte) Infos wie »eher selten«, »ausgesprochen häufig«, usw. in die Tag Cloud geschrieben – allerdings ausserhalb der Links:

  1. <ul>
  2. […]
  3. <li><span style="font-size:169%"><a href="linkziel">Arzt-Suchdienst</a></span><span class="ignore"> ausgesprochen häufig</span></li>
  4. […]
  5. </ul>

Leider zeigen beide Ansätze bei genauerem Hinsehen, dass sie wohl kaum mit echten Screenreader-Nutzern getestet sein können, denn beide Ansätze haben grundsätzliche Probleme:

  1. Entweder lässt der Screenreader-Nutzer sich das alles vorlesen – dann steigt der Nutzer nach unserer Erfahrung ob der Menge der unnützen Zusatzinfos nach der Hälfte der Tag Cloud aus; oder
  2. Der Screenreader-Nutzer tabbt durch die Tag Cloud (von Link zu Link) – dann wiederum bleibt ihm die Zusatzinfo verborgen, wenn diese ausserhalb der Links steht. Und nein, die Infos in die Links selbst reinzuschreiben ist wie gesagt auch keine Lösung, weil dann wieder Punkt 1 greift.

Und deswegen ist die Tag Cloud so wie sie ist.

Nachtrag:

(Tipp von Rainer Schlegel via E-Mail)