accessBlog

Aktuelles zum Thema Barrierefreies Webdesign.

02 Mär 2009

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)

Kommentare zu dieser Meldung: 18

Permalink Michael meinte am 02.03.2009:

Schöne Abhandlung - Danke!

Permalink Lars meinte am 02.03.2009:

Ich wäre das Thema instinktiv auch anders angegangen, aber diese Erklärung bringt die wesentlichen Dinge auf den Punkt. Danke dafür.

Permalink molily meinte am 02.03.2009:

»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.«

Anscheinend werden hier völlig verschiedene Diskussionsebenen vermischt, anders kann ich mir nicht erklären, wie mittendrin so grundsätzliche Fragen aufkommen. Ist das nicht eher ein allgemeiner Einwand gegenüber einer Tag-Cloud mit unterschiedlicher Gewichtung (unterschiedlichen Schriftgrößen bei visueller Ausgabe)? Da besteht wohl sehr fundamentaler Diskussionsbedarf - und die technische Umsetzung, um die es vermeintlich geht, ist gar nicht die Kernfrage.

Vielleicht sollte man (jeder einzelne Webautor für eine Site) sich vorher darüber klar werden, was die Tagcloud kommunizieren soll und inwiefern sie die Bedienung vereinfachen soll. Soll sie bloß eine alphabetische Stichwortliste sein? Soll sie die Häufigkeit der Tagbenutzung wiedergeben? Wenn ja, warum und mit welchem Zweck? Soll es die Besucher dazu animieren, die häufigeren Stichwörter zu klicken? Tut es das überhaupt oder was suggeriert die Gewichtung?
Gut, einfach-fuer-alle.de hat Antworten auf diese Fragen gefunden, aber man kann auch andere darauf finden und dann sind weitere Infos nicht einfach nur »akustischer Müll«. Im Übrigen sehe ich kein Problem darin, bei wenigen (!) Links eine relative Kennzeichnung wie »sehr selten« oder »sehr häufig« hinzuzufügen.

Permalink Der Caspers meinte am 02.03.2009:

@molily: alles richtig, und letztendlich läuft es doch daraus hinaus, dass man sich
a. überhaupt Gedanken zu dem Thema macht und
b. noch viel wichtiger: diese dann konsequent bis zum Ende durchdenkt (daran entzündete sich unsere Kritik - dass es eben nur halbgare Lösungen sind).
Dass man dann je nach Angebot und Rahmenbedingungen zu unterschiedlichen Ergebnissen kommt ist normal und nicht schlimm - solange man das dann schlüssig begründen kann ist gut.

Bei wenigen Links mag das mit der relativen Kennzeichnung ein gangbarer Weg sein, aber wir haben hier mit Stand heute 2.475 Beiträge im Blog und da reicht manchmal selbst die bewusst schlank gehaltene Tagcloud mit ≈55 Tags nicht aus. Wir wollen aber auch nicht auf jeder Seite eine ausufernde Liste mit Zusatzinfos zu den Zusatzinfos (wie z.B. drüben bei netzpolitik.org zu sehen), denn das hört sich dann auch keiner mehr an.

Permalink hublo meinte am 03.03.2009:

wobei man sich fragen muss... braucht man überhaupt TagClouds?
was sagt das Tracking der User dazu? werden TagClouds genutzt?

Permalink Der Caspers meinte am 03.03.2009:

hublo meinte am 03.03.2009:
> werden TagClouds genutzt?

Ja, werden sie. Wir haben gerade noch mal in der Statistik nachgesehen, und sie werden tatsächlich in erheblichem Maße genutzt. Zum Vergleich hier mal die Tags sortiert nach der Häufigkeit der Klicks:

CSS, Barrierefreiheit, BITV, PDF, Werkzeuge, HTML, JavaScript, AJAX, Testen, Gesetze, Design, Barrieren, Flash, Sehbehinderung, Linux, Hilfsmittel, WCAG, Webstandards, Typografie, BIENE, Usability, best-practice, Mac, Windows, Browser, CMS, EfATagung, Zertifizierung, Hausmitteilung, web-2.0, Veranstaltungen, hoerbehinderung, motorische-behinderung, Lernbehinderung, Navigation, Ausbildung, ATAG, leichte-sprache, Podcast, DGS, W3C, Blogs, Microformats, Literatur, eGovernment, mobile-web, multimedia, eLearning, oesterreich, Schweiz, eCommerce, i18n, UAAG, wai-aria

Permalink Peter meinte am 03.03.2009:

Ich denke, das die Vorschläge wie können zusätzliche semantische Informationen in ein Tag-Wolke verpackt werden, wie der Artikel schon ausführt, nicht von nutzen sind. Ob nun über Zahlen oder zusätzliche Infos die vor grafischen Browser versteckt werden.
Hier trifft die visuelle Wahrnehmung und das daraus resultierende Nutzerverhalten auf ganz spezifische Formen der Informationswahrnehmung und Verarbeitung bei Screenreadernutzern.

Wer Informationen auf der visuellen Ebene verarbeitet, wird eher auf deutlich hervorgehobene Wörter in einer Tag-Wolke klicken, auch wenn er zu einem bestimmten Thema recherchiert. Vergleichbar mit einem ähnlichen Effekt wie bei Werbebannern oder Eyecatchern.
Sehr einfach ausgedrückt: Die visuelle Wahrnehmung beeinflusst das Nutzerverhalten.

Daher resultieren vielleicht auch die Vorschläge, visuelles auf eine semantische Informationsebene zu bringen. Was aber in Bezug Screenreadernutzer nicht der optimale Ansatz ist. Wer das Glück hat und vielleicht einen blinden Menschen in seinem Bekanntenkreis kennt, sollte ihn zu seiner Meinung fragen. Vielleicht einfach mal die Frage stellen, ob er nicht die Seite testen möchte.

Vielleicht mag es bei einer kleinen Tag-Wolke, ein möglicher Weg sein, zusätzliche Infos bereitzustellen. Aber wieso? Welchen effektiven Gewinn kann der Screenreadernutzer daraus ziehen. Wir leben ja nunmal in einer Welt in der tagtäglich Informationen, Eindrücke auf uns einprasseln. Wir können die Menge an Eindrücken selber nicht verarbeiten. Daher bin ich auch der Meinung weniger ist oft mehr.

Permalink Rainer meinte am 03.03.2009:

Vielleicht gibt's zu dem Thema ja auch mal den Originalton eines sehbehinderten und erfahrenen Screenreadernutzers. Erfahren heißt hier: ein Nutzer, der mit Tagclouds Erfahrung hat und diese ab und zu oder öfter nutzt.

Je mehr ich darüber nachdenke, frage ich mich auch, welchen Mehrwert eine sichtbare oder unsichtbare Gewichtung der Begriffe überhaupt bietet? Was sagt mir als Nutzer die Gewichtung, außer, dass höher gewichtete Begriffe eben häufiger vorkommen. Hilft mir das beim Navigieren über die Tagcloud? Brauche ich also eine semantische Unterscheidung, egal ob ich sehen kann oder nicht? Warum sollte jemand einen Begriff auswählen, der fetter/größer ausgezeichnet ist?

Wie oben erwähnt: suche ich einen Begriff gezielt, ist mir die Gewichtung wohl egal, wenn ich ihn sowieso nach alphabetischer Sortierung finde. Bin ich dagegen ziellos unterwegs und will mich auf der Site inspirieren oder unterhalten lassen, mag mir die Gewichtung eine eventuelle Hilfe sein.

Vielleicht ist die optische Gewichtung nur ein netter Effekt, eine Bauchnabelschau, ein "ich hab den größeren (Begriff)"? Was meint Ihr?

Permalink Der Caspers meinte am 03.03.2009:

Das Problem ist, dass man Nutzer so etwas nicht fragen kann, weil dann grundsätzlich alle sagen, dass sie immer alles haben wollen.

Das ist so wie wenn man die Specs für eine Intranet-Anwendung erstellt und erstmal alle Abteilungen der Firma befragt, was sie gerne in der Software drin hätten. Da kommt dann eine Liste von Anforderungen heraus, die zu einer komplett unbenutzbaren (weil überladenen) Software führt (sofern man die dann überhaupt ans Laufen kriegt). Manche Firmen bilden dann Komitees und Arbeitsgruppen, um diese Effekte abzumildern – da kommt dann in der Regel ein Zune statt eines iPods hinten raus.

Sehr schön beschreibt das Marissa Mayer von Google: in einem Experiment wurden Benutzer befragt, wie viele Treffer sie gerne in der Suche haben möchten. Die Nutzer wollten unbedingt mehr als die bisherigen 10 haben, weil mehr eben mehr ist. Also wurde im Test die Zahl der Treffer pro Seite auf 30 erhöht. Resultat:

»Traffic and revenue from Google searchers in the experimental group dropped by 20%.«

Quelle: http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html

Ich sehe keinen Grund warum Screenreader-Nutzer da eine Ausnahme bilden sollten - im Gegenteil. Bei unerfahrenen Screenreader-Nutzern ist oft zu beobachten, dass sie überwältigt sind, wenn die angebotenen Informationen zu viel sind und dann u.U. aussteigen; bei erfahrenen Screenreader-Nutzern wiederum passiert das genaue Gegenteil – hier werden oft optionale Infos unterdrückt, um die Menge des Vorgelesenen auf ein handhabbares Maß zu reduzieren.

Permalink molily meinte am 03.03.2009:

»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.«

Ein ol-Element (ordered list) zu verwenden, ist in erster Linie eine semantische Frage. Die Liste hat eine Ordnung, also ist ein solches Element angebracht. Die Ordnungszahlen sind eine Möglichkeit, diese Ordnung wiederzugeben. Wenn man sie nicht braucht, schaltet man sie mit list-style-type: none aus. Das beachten m.W. auch Screenreader, insofern verstehe ich das Argument nicht. Natürlich bringt diese Semantik dem Nutzer Erkenntnisse, wenn sie denn kommunziert wird.

Permalink Der Caspers meinte am 03.03.2009:

@molily Dann mal ganz konkret: welchen Nutzen hat der Anwender von der Information, dass sich das Tag »CSS« an Position Nummero 12 in der (alphabetisch sortierten) Liste befindet? Insbesondere wenn man genau diese Information dann per CSS unterdrückt?

Permalink Peter meinte am 04.03.2009:

@Der Caspers: Danke für den Hinweis auf das Google Experiment.

Ein schönes Beispiel. Zeigt es doch sehr praktisch wie der Wunsch nach mehr Informationen, praktische Auswirkungen auf das Nutzerverhalten hat.

Zu viel Semantik, oder auch "ausgeschmückte" Semantik, kann schnell zu einen Übermaß an Informationen führen. Ich würde vermuten, dass sich bei unerfahrenen Nutzern schnell das Phänomen der Orientierungslosigkeit einstellt ("Lost in Hypertext"). Der Nutzer ist letztlich nicht mehr in der Lage ein korrektes und vollständiges Modell der Hypertextstruktur zu skizzieren.

HTML bietet leider nicht für alle Anwendungsfälle das optimale Element. Im Zweifelsfall würde ich eher dazu tendieren, die einfachste Lösung zu wählen.

Accessibility heißt für mich, dem Nutzer nicht unnötige Steine in den Weg zu legen, sondern ganz im Gegenteil. Er soll schnell, ohne Umwege und nach Möglichkeit einfach, zum Ziel gelangen. Für Screenreadernutzer heißt das, scanbare Strukturen schaffen, damit der Nutzer einen guten Überblick bekommt.

Permalink molily meinte am 05.03.2009:

Thomas, darum gehts doch gar nicht bei dem Vorschlag, eine OL zu verwenden. OL und die Anzeige von Ordnungszahlen haben erstmal nichts miteinander zu tun. Es ist aus der Sicht irrelevant, dass man damit Ordnungszahlen anzeigen kann und welchen Nutzen das hätte. Es hätte in diesem Fall keinen sonderlichen, darin hat dir auch niemand widersprochen. Aber das hat mit der Wahl zwischen UL und OL m.E. nichts zu tun. Die Semantik, von der ich sprach, ist die der »geordneten Liste«, nicht die der Ordnungszahlen.

Permalink Rainer meinte am 06.03.2009:

Und was bringt eine geordnete Liste, wenn sie bereits alphabetisch geordnet ist? Wenn das Ordnungskriterium semantisch gesehen gar nicht die Reihenfolge der Links ist? Wieso hat eine Tagcloud überhaupt eine Ordnung (wo fängt denn eine Wolke an und wo hört sie auf)?

Permalink Kai Laborenz meinte am 10.03.2009:

Das grundlegende Problem ist doch, dass akustisch eben nicht die beiden visuell übermittelten Ordnungskriterien - alphabetisch und "nach Bedeutung" - gleichzeitig übermittelt werden können. Würden wir in einer besseren Welt leben, würden führende Screenreader vielleicht etwas mit passenden CSS-Tags zur akustisch passenden Betonung anfangen können...

Daher wäre es für mich die passende Lösung, die Tagwolke akustisch als simple Liste darzustellen - nach der Bedeutung geordnet. Eventuell noch mit der Möglichkeit, auf alphabetische Reihenfolge umzustellen. Das wirft allerdings ein paar neue Probleme auf - z.B. wie man so etwas dann technisch löst und ob eine Umschaltmöglichkeit die Bedienung nicht unzumutbar kompliziert.

Permalink Der Caspers meinte am 10.03.2009:

Kai Laborenz meinte:
> nach der Bedeutung geordnet

@Kai: dann hätte man aber wieder das selbstverstärkende Digg-Klickvieh-Problem, dass die am stärksten gewichteten Tags vorne in der Liste stehen und garantiert am Häufigsten angeklickt werden.

> ob eine Umschaltmöglichkeit die Bedienung nicht unzumutbar kompliziert.

Genau. Das wäre doch nur eine (vermeintliche) technische Lösung für ein eigentlich inhaltliches Problem.

Permalink maik_w meinte am 10.03.2009:

@der Caspers: Es geht hier doch um zwei Dinge: Welche (Zusatz-)Informationen will man mittels Tag Clouds vermitteln und wie lässt sich das technisch realisieren?
Die Kritik, dass mein Beispiel nicht zu Ende gedacht sei, möchte ich hier mal nicht so stehenlassen. Die konkrete Anwendung, die hinter diesem Beispiel steht, ist eine Begriffsliste, die das Eingeben von komplizierten medizinischen Fachbegriffen in die Suche erleichtern soll, nicht mehr und nicht weniger. Die Erfahrungen mit den entsprechenden Usern hat gezeigt, dass sie durchaus dankbar sind, den entsprechenden Begriff nicht eingeben zu müssen, sondern auswählen zu können. Unsere Screenreadernutzer sind eher unerfahren und auch geduldig, so dass es schon hinkommt, dass sie sich 'alles' vorlesen lassen. Es ist halt die Frage, ob man zusätzliche Informationen anbietet, die der User nutzen kann – wenn er möchte. Von welchem Nutzer geht man aus, wenn man Informationen anbietet?

Und wie immer: Das Wichtigste ist der Sprunglink, mit dem man das ganze Ding einfach übergehen kann.

Permalink Der Caspers meinte am 10.03.2009:

> Und wie immer: Das Wichtigste ist der Sprunglink, mit dem man das ganze Ding einfach übergehen kann.

Bitte nicht. Zumindest nicht vor die Tag Cloud, nur um diese zu überspringen (alles schon live gesehen – die Seite hatte mehr Sprunglinks als verwertbare Inhalte). Screenreader bieten von sich aus die Möglichkeit, eine Liste zu überspringen und/oder zum nächsten Struktur-Element zu gehen. Tastatur-Nutzern im Allgemeinen reicht, wenn sie zu Beginn der Seiten die wesentlichen Inhalte ansprigen können – mehr ist wirklich unnötig bis schädlich.