Das Rahmenkonzept

für Barrierefreiheits-Tools für Nutzer mit kognitiven Behinderungen

Hinweis

Dieser Artikel wurde auf Einladung zur Präsentation beim 2. jährlichen internationalen Cross-Disciplinary Workshop on Web Accessibility (W4A) in Chiba, Japan, am 10. Mai 2005 geschrieben.

Zusammengefasst. Die Autoren präsentieren ein Rahmenkonzept, welches Tool Entwickler verwenden können, um auszuwerten, welche Richtung die Entwicklung von Tools annimmt, um Nutzern mit kognitiven Behinderungen zugute zu kommen.
Das Rahmenkonzept beinhaltet Kategorien von funktional-kongnitiven Behinderungen, Prinzipien der Barrierefreiheit für kognitiv Behinderte, Einheiten von Webinhalt Analysen, Aspekte der Analyse und Bereiche der Verantwortung.

Einleitung

Die unterschiedlichen Barrierefreiheits Tools können nach den gängigen Barrierefreiheits-Problemen prüfen wie zum Beispiel Bilder ohne Alt-Text, Datentabellen ohne Überschriften, Formulare ohne Beschriftung usw.. All diese Probleme sind bei der Barrierefreiheit wichtig. Dennoch besteht der Fokus der Mehrheit dieser Tools auf nur einer Art von Behinderung: Blindheit. Nur wenige andere Algorithmen fokussieren sich auf weitere Arten von Behinderungen. Die am meisten vernachlässigte Kategorie der Behinderungen ist die kognitive Behinderung.

Ein Teil des Problems für diese Vernachlässigung ist die Knappheit der generell-akzeptierten Empfehlungen für den Zugang der kognitiven Behinderung zum Web. Empfehlungen existieren zwar aber die Menge an Literatur und Forschung in diesem Bereich ist viel knapper, sodass die Frage aufsteigt wie zuverlässig oder gültig diese sind.

Ein weiterer Grund für die Vernachlässigung ist die Unbestimmtheit und Subjektivität der Empfehlungen, die bereits existieren. Web-Barrierefreiheits-Experten interpretieren dabei die Empfehlungen oft unterschiedlich, was dazu führt, dass die Anforderungen an die Einhaltung schwierig zu überprüfen sind. In vielen Fällen ist die Erstellung von Computer-Algorithmen für diese Empfehlungen schlichtweg unmöglich oder zumindest sehr willkürlich. Obwohl zum Beispiel einige Experten die Idee vertreten, dass einfacher Text [1] Nutzern mit kognitiven Behinderungen nützen können, gibt es keine Definition welcher Text „klar und einfach“ oder im Gegenteil „unklar und komplex“ geschrieben ist.
Barrierefreiheit bei kognitiven Behinderungen ist ein krankhaft strukturierter Bereich, welcher sich mit anderen krankhaft strukturierten Bereichen wie zum Beispiel Usability, Human Computer Interface Design und Wahrnehmungspsychologie überschneidet.

Angesichts der starken Komplexität und der Mehrdeutigkeit von Problemen der Barrierefreiheit für kognitiv Behinderte haben sich die meisten Tool Entwickler dafür entschieden sich auf andere Bereiche zu fokussieren. Als Resultat übersehen die Nutzer der Tools oft die Probleme der Barrierefreiheit für kognitiv Behinderte komplett. Nichtsdestotrotz verringert die Schwierigkeit dieses Problems ihre Wichtigkeit. Wenn die Tools in der Lade wären wenigsten einige wenige Barrierefreiheits-Probleme für Menschen mit kognitiven Behinderungen zu erkennen, dann wären die Entwickler auch eher in der Lage ihre Inhalte dementsprechend zu entwickeln.

Ein Rahmenkonzept zur Demystifizierung von Webdesign für kognitiv Behinderte

Bevor jeglicher Fortschritt in Richtung Entwicklungstools gemacht werden kann, welche Inhalte barrierefreier für Menschen mit kognitiven Behinderungen machen sollen, müssen die kognitiven Behinderungen soweit wie möglich demystifiziert werden. Zu diesen Zweck wurde dieses Rahmenkonzept verfasst, mit dessen Hilfe Tool-Entwickler die Herausforderung der Identifizierung und der Reparatur von Barrieren für kognitiv Behinderte beseitigen können.
Dieses Rahmenkonzept besteht aus:

Kategorien von funktional kognitiven Behinderungen,
Prinzipien der Barrierefreiheit für kognitiv Behinderte,
Einheiten der Web-Inhalt Analyse,
Aspekte der Analyse,
Stufen der Analyse, und
Bereich der Verantwortung.

Nachdem wir dieses Rahmenkonzept untersucht haben, werden wir untersuchen wie man dieses Rahmenkonzept bei der Entwicklung von Barrierefreiheitstools für kognitiv Behinderte einsetzen kann.

Klinische vs. funktionale kognitive Behinderungen

Es gibt verschiedene Typen der kognitiven Behinderungen, wobei jede ihre eigene klinische Diagnose hat. Bei einigen Menschen wird zum Beispiel diagnostiziert, dass sie Lern-Behinderungen haben ( wie z.B. Dyslexie, Schreibstörung, Dyskalkulie oder das Aufmerksamkeitsdefizitsyndrom), genetische oder Enticklungs-Behinderungen (wie Autismus, Down-Syndrom), angeborene Geburtsfehler ( wie das Alkoholentzugssyndrom) oder jede andere Art von Behinderung, die die Wahrnehmung betrifft.
Während diese Diagnosen in der Klinik wertvoll sein können, sind sie für Web Entwickler meist wertlos, weil es in der Regel keine direkte Verbindung zwischen der Diagnose und den Aktionen gibt, die der Entwickler ausführen muss, um den Menschen mit diesen Diagnosen zu helfen. Zunächst einmal gibt es viele Überschneidungen bei den Grenzkennlinien der Menschen mit diesen Diagnosen. Personen mit Down-Syndrom oder Personen mit dem Alkoholentzugssyndrom können Schwierigkeiten bei der Verarbeitung von textbasierten Informationen haben. Genau so können das auch Personen mit Lern-Behinderungen haben, wenn auch in einem anderen Ausmaß. Das bringt uns zu dem zweigen Punkt, dass es oft große Unterschiede nicht nur zwischen verschiedenen Gruppen sondern auch innerhalb gewissen Gruppen mit den gleichen klinischen Diagnosen gibt. Einige Personen mit Down-Syndrom beherrschen sehr gut das Lesen und Verstehen von Web-Inhalten. Bei anderen kann es wiederum sein, dass sie nicht im Stande sind die meisten Web-Inhalte zu verstehen.

Ein viel nützlicheres Rahmenkonzept für Entwickler ist das der funktional kognitiven Behinderungen. Nicht alle Kategorien von funktional kognitiven Behinderungen, die bisher von früheren Autoren vorgeschlagen wurden, sind direkt für Web Entwickler relevant. Die Kategorien, die wir auflisten basieren primär auf Rowland`s [2] Kategorien mit einigen Ergänzungen. Diese Kategorien sind:

Gedächtnis
Problem-Lösungen
Aufmerksamkeit
Lesen, linguistisches, und verbales Fassungsvermögen
Mathematisches Fassungsvermögen
Visuelles Fassungsvermögen

Die letzten 3 Kategorien sind eine Ergänzung der Original Kategorien von Rowland, welche unserer Meinung nach für unsere Zwecke zu breit gefächert waren. Nutzer müssen mit der Herausforderung einiger dieser Kategorien, die sich übrigens nicht gegenseitig ausschließen, beim Verarbeiten von Webinhalten zurecht kommen. Der Fakt, dass die Kategorien sich nicht gegenseitig ausschließen verkompliziert die Angelegenheiten. Dennoch sind die Kategorien als Bezugsrahmen, innerhalb dessen man die einzelnen Herausforderungen charakterisieren kann, sinnvoll. Die meisten Anwender Herausforderungen werden in erster Linie in eine Kategorie passen, auch wenn ihre Auswirkungen in andere Kategorien übergehen.
Zum Beispiel wird eine Person mit Lese-Schwierigkeiten es auch schwer finden langen Passagen von Text Aufmerksamkeit entgegen zu bringen. Eine Person, die Konzentrationsschwierigkeiten hat wird auch Schwierigkeiten beim Begreifen von Text haben. Im ersten Fall führen Leseschwierigkeiten zu Unaufmerksamkeit und im zweiten Fall führt Unaufmerksamkeit zu Leseschwierigkeiten. Trotz der Überschneidung der Ergebnisse sollte man die Aufmerksamkeit auf die ursprüngliche Ursache richten, was die zweite Ursache eliminieren oder die Ausmaße verringern kann. Ebenso repräsentiert jeder der oben genannten Kategorien aus Entwickler-Sicht jeweils eine andere Art von Problem und benötigt dementsprechend auch eine andere Art von Lösung.

Prinzipien der Barrierefreiheit für kognitiv Behinderte

Es gibt generelle Prinzipien, die auf alle Kategorien von funktional kognitiven Behinderungen angewandt werden können. Diese Prinzipien, die von Bohman [3] entnommen wurden besagen, dass Web-Inhalte:

einfach
einheitlich
klar
Multi-Modal
fehlertolerant
verzögerungstolerant
aufmerksamkeitsfokussierend

sein sollten.

Die Definition eines jeden dieser Prinzipien ist nicht immer ganz einfach. Wie einfach sollte zum Beispiel etwas sein, um als „einfach“ zu gelten? Wieviel Variation kann hinzugefügt werden bevor etwas als nicht „einheitlich“ mehr gelten kann. Was sind die besten Möglichkeiten um Inhalte „klar“ zu gestalten? Die Antwort auf diese Fragen hängt davon ab welche Art von Dingen Tools identifizieren können und sollten, um Web Inhalte barrierefreier für Menschen mit Behinderungen zu machen. Dennoch werden viele der Antworten genau so unklar und vage sein, wie die dazugehörigen Fragen. Dennoch ist es bereits der erste Schritt in die richtige Richtung, wenn man einige Prinzipien identifiziert, weil uns das erlaubt die existierenden Algorithmen in Tools zu kategorisieren und weil es die Richtung der Entwicklung für zukünftige Algorithmen voraus zeigt.

Einheiten der Analyse

Einer der Bereiche, der bei der Entwicklung von Barrierefreiheits-Tools übersehen wird ist die Analyseeinheit. Wir haben 6 potentielle Einheiten zur Analyse identifiziert:

Die Web-“Seite”
Die vollständige Webseite
Das Template
Inhalt innerhalb des Templates
“Brocken” oder Unterabschnitte vom Inhalt
Szenarien und Pfade

Die meisten Tools werten entweder einzelne Seiten oder gleich die gesamte Webseite aus. Die Tools, die Berichte über gesamte Webseiten erstellen, verwenden dabei dennoch die Analyse von mehreren einzelnen Seiten. Oft beinhalten die Berichten eine Liste mit Fehlern und zeigen dem Nutzer die URLs der Seiten, auf denen die Fehler gefunden wurden. Obwohl solche Berichte in unterschiedlichen Bereichen wichtig sind, sind diese Berichte, bei denen die gesamte Webseite ausgewertet wert nicht so nützlich wie andere Arten von Berichten, die auf anderen Analyseeinheiten basieren.

Die Analyse der gesamten Webseite ist nicht sehr effizient, da Webseiten in der Regel mit Hilfe von Template Systemen konstruiert werden, oft mit Elementen in der Navigation wie Tabs oder Sidebar Links zu anderen Bereichen der Seite. Diese Templates sind in der Regel auf der gesamten Seite einheitlich aufgebaut. Berichte, die auf der Seite als Einheit der Analyse basieren, beinhalten meist die gleichen Fehler für jede einzelne Seite. Wenn das Haupt-Logo der Seite zum Beispiel keinen ALT-Text beinhaltet, dann steht im Bericht, dass dieser Fehler auf jeder einzelnen Seite über die gesamte Webseite hinweg vorhanden ist. Es wäre viel effizienter diesen Fehler nur ein Mal zu erwähnen und diesen Fehler als Fehler im Template zu kennzeichnen.

Fehler, die im Haupt-Inhalt auftauchen sollten auch als solche gekennzeichnet sein, aber die Tools können potentiell noch mehr tun als nur den Inhalt vom Template zu trennen. Wo es notwendig ist sollten Tools in der Lage sein einzelne Bruchteile oder Untersegmente des Haupt-Inhalts zu analysieren. Dies wäre zum Beispiel auf Seiten sehr sinnvoll, auf denen der Inhalt von verschiedenen Quellen zusammengetragen wird. Jede Inhalts-Komponente könnte einzeln und unabhängig analysiert werden. Nicht jeder Web-Inhalt kann oder soll in kleinere Unterbereiche aufgeteilt werden, wo es aber möglich ist, sollte es aber gemacht werden, um ihn besser zu analysieren.

Der abschließende Teil der Analyse ist einer der wichtigsten, obwohl dieser meisten ignoriert wird: Szenarien und Pfade [4]. Im Kontext dieses Papiers bedeutet das Szenario oder der Pfad die gesamte Nutzererfahrung vom Anfang bis zum Ende. Auf einer E-Commerce Seite würde das Szenario zum Beispiel die Suche nach einem Produkt, das Hinzufügen des Produktes zum virtuellen Warenkorb, die Eingabe der Zahlungsmittel und der Versandinformationen sowie die Bestätigung der Bestellung beinhalten. Das setzt natürlich voraus, dass der Nutzer nicht vom Pfad abweicht. Alternative oder tangierende Pfade würden zum Beispiel das Durchlesen der Informationen über das Unternehmen, das das Produkt verkauft, das Durchlesen der Datenschutzbestimmungen, den Vergleich des Produktes mit anderen vergleichbaren Produkten usw. beinhalten. Wenn einer dieser Schritte über den gesamten Weg auf einem dieser Pfade nicht barrierefrei ist, dann ist der gesamte Pfad nicht barrierefrei. In diesem Fall wäre sinnlos zu behaupten, dass 95 % einer Seite barrierefrei ist, wenn die 5%, die nicht barrierefrei sind dafür sorgen, dass der Nutzer das Produkt nicht kaufen kann. Das gesamte Szenario oder das Szenario Set muss mit in die Planung hineingenommen werden, um das Maximum an Barrierefreiheit zu erreichen.

Aspekte der Analyse

Für alle Einheiten der Analyse gibt es 2 verschiedene Aspekte der Analyse:

den Inhalt
die Präsentation

Der Inhalt kann primär nach der semantischen und begrifflichen Bedeutung untersucht werden. Die Präsentation, die im Text, in den Grafiken, Videos, Audios und anderen Formaten enthalten ist, kann im Bezug auf seine Multimodalität, Fehlertoleranz, Verzögerungstoleranz oder auf die Fähigkeit die Aufmerksamkeit des Nutzers aufzufangen analysiert werden. Interessanterweise kann die Präsentation ebenfalls nach der semantischen und begrifflichen Bedeutung hin untersucht werden. Zum Beispiel kann eine Webseite in verschiedene Bereiche mit Hilfe des <div> Tags mit unterschiedlichen Hintergrundfarben unterteilt werden. Diese Bereiche können effektiv als visuelle Gruppierung oder als Unterteilung wahrgenommen werden. Dabei stellen diese Unterteilungen nicht nur visuelle Bereiche sondern auch visuelle Präsentationen von semantischer Bedeutung dar. Natürlich muss so eine semantische Bedeutung auch im Haupt-Inhalt vorhanden sein aber die Präsentation unterstreicht dabei die semantische Bedeutung nochmal.

Stufen der Analyse

Web Inhalte können auf verschiedenen Entwicklungsstufen und aus verschiedenen Gründen bewertet werden. Die Hauptstufen der Analyse sind:

Der Planungsprozess
Der Design Prozess
Die Testphase
Nachdem der Inhalt fertiggestellt ist

Die meisten Tools wurden erstellt, um sie nach der Fertigstellung des Inhalts zu verwenden. Das ist auch eine wichtige Entwicklungsstufe aber natürlich nicht die einzige. Die allererste Stufe bei der bereits Arbeit an der Barrierefreiheit nötig ist ist: der Planungsprozess. Es gibt bereits Tools für den Planungsprozess, die in Authoring Tools, in Grafik Tools oder in Tools, die exklusiv für den Planungsprozess erstellt wurden, enthalten sind. Solche Tools könnten den Nutzern Anleitungen oder Anregungen zu Beginn der Entwicklung liefern, damit die Probleme bereits beseitigt sind bevor sie überhaupt entstehen. Zusätzlich zu den Tools für die Authoring-Umgebung könnten Test-Tools für Browser oder für Desktop-Programme oder für Web-Programme erstellt werden.

Bereich der Verantwortung

Eine der Schwierigkeiten bei der Besprechung von Möglichkeiten zur Erstellung von barrierefreien Inhalten für Menschen mit kognitiven Behinderungen ist, dass es oft unklar ist, wer für welchen Bereich und für welche Veränderungen zuständig ist. Die Hauptbereiche der Verantwortung beinhalten:

Web Entwickler
Richtlinien und Advances
Authoring Tool Entwickler
Nutzer Agent Entwickler
Unterstützende Technologie Entwickler
Persönliche Assistenten des Nutzers(wo anwendbar)
Der Nutzer

Es gibt viele Punkte, an denen Web Inhalte für Menschen mit kognitiven Behinderungen, barrierefreier gemacht werden können. Die Reihenfolge, in der die Bereiche der Verantwortung oben aufgelistet sind, ist eine grobe Repräsentation des Flusses vom Web-Inhalt von der Quelle (dem Web Entwickler) zum Ziel (dem Nutzer). Web Entwickler implementieren Richtlinien und Advances in ihre Authoring Tools. Der Inhalt wird vom Nutzer Agent (dem Browser) dargestellt und kann zum Beispiel durch eine unterstützende Technologie wie einem Text-zu-Sprache Synthesizer oder durch einen persönlichen Assistenten unterstützt werden. Je schwerer die kognitive Behinderung des Nutzers, desto wahrscheinlicher ist es auch, dass der Nutzer einen persönlichen Assistenten benötigt, um auf Web Inhalte zuzugreifen. Am Ende dieses Flusses sind die Nutzer, die ihre Browser-Einstellungen entsprechend ihren Bedürfnissen einstellen können.

Trotz der vielen Ansatzpunkte der Intervention ist es entscheidend, dass der Prozess beim Web Entwickler startet. Die Web Entwickler können ihre Verantwortung dabei nicht abgeben, wobei es einige wohl gerne tun würden. Sobald der Web Entwickler Inhalte im Internet postet, sind diese entweder barrierefrei oder nicht barrierefrei für Menschen mit kognitiven Behinderungen. Es gibt danach nicht viele Möglichkeiten an den anderen Ansatzpunkten zu intervenieren und zu verbessern, denn nur der Autor des Inhaltes weiß in der Regel zu 100%, was der Sinn des Inhaltes ist. Bei allen anderen Intervention an Ansatzpunkten handelt es sich um Interpretationen des Originalinhaltes vom Autor. Aus diesem Grund kann man später nicht zu 100% die Fehler und Versäumnisse des Autors kompensieren.

Die Anwendung des Rahmenkonzeptes an der Tool Entwicklung

Das Rahmenkonzept, welches in diesem Papier vorgestellt wurde hilft nicht nur bei der Tool Entwicklung für kognitive Behinderungen sondern für alle Arten von Behinderungen. Da es in diesem Papier aber um kognitive Behinderungen geht, zeigen wir euch auch ein Beispiel.

Das Rahmenkonzept entmystifiziert zwar einige der konzeptuellen Probleme bei der Tool Entwicklung für kognitiv behinderte, aber es gibt keine automatischen oder einfachen Antworten auf die Umsetzung dieser notwendigen Prozesse. Dennoch werden einige der Konzepte in dem Rahmenkonzept wahrscheinlich niemals vollständig automatisiert werden können und sie werden wahrscheinlich immer menschliche Interpretationen und Interventionen erfordern, sowohl auf der Entstehungsseite als auch auf der Auswertungsseite.

Für unser Beispiel haben wir einen Teil von jedem Element aus dem Rahmenkonzept gewählt, um dieses näher zu erklären. Die Rahmenkonzept-Elemente, die wir gewählt haben, sind folgende:

Kategorie der funktionalen & kognitiven Behinderungen: Lesen, linguistisches und verbales Verständnis
Prinzipien der Barrierefreiheit bei kognitiven Behinderungen: Einfachheit
Einheit der Web-Inhalt Analyse:Das „Szenario“ oder der Pfad
Aspekte der Analyse: Präsentation
Stufe der Analyse: Die Designphase
Bereich der Verantwortung: Authoring Tool Entwickler

Das Szenario, an welchem wir diese Elemente des Rahmenkonzeptes anwenden ist die Suche eines Nutzers nach dem aktuellen Wetter auf einer News-Seite. Die Schritte in diesem Szenario sind:

News Seite Startseite aufrufen
Finde den Link zu der Wetter Information
Klicke auf den Link der Wetter Information
Gebe die Stadt, den Staat und das Land ein
Lese die Wetter Prognose

Der Umfang unserer Analyse beinhaltet die Überprüfung ob jeder einzelne Schritt in unserem Szenario barrierefrei lesbar ist und aus einer einfachen Präsentation des Leseinhaltes besteht und linguistisch und verbal verständlich ist. Die Analyse in unserem Beispiel findet in der Designphase innerhalb des Authoring-Tools statt.

Unser hypothetisches Autorentool ermöglicht uns, eventuelle Szenarien oder Benutzerpfade auf der Webseite zu definieren. Wir bestimmen diese Szenarien gemäß unseren Testanalysen und geben ihnen einen Titel, wie beispielsweise „Informationen über das Wetter lesen“. (Weitere mögliche Szenarien, die wir für eventuell für andere Analysen definieren, könnten das folgende beinhalten „lokale Schlagzeilen lesen“, „eine Todesanzeige einreichen“, „einen Brief an die Redaktion einreichen“ oder „Technologie-Neuigkeiten lesen“.)

Da unser hypothetisches Autorentool erkennen kann, in welchen Bereichen der Webseite sich die Vorlage und der Hauptinhalt befinden (wir würden dies vorher definieren), sind wir in der Lage zu ermitteln, welche Fehler in welchem Teile der Internetseiten auftreten. Wenn wir das Tool aktivieren, erhalten wir die Wahl zwischen einem zusammenfassenden Bericht oder einem interaktiven Assistenten. Wir wählen den interaktiven Assistenten, denn das Tool schaut sich zuerst die Vorlage an.

Analyse der Vorlage Wie sich herausstellt, wird die gleiche Vorlage auf jeder der drei Seiten verwendet, auf die wir zugreifen müssen, um die Wettervorhersage zu erhalten. Das ist eine gute Sache, denn das Tool empfiehlt uns, die gleiche Vorlage beizubehalten.

Das Tool hat festgestellt, dass sich 15 Hauptnavigationslinks in der Vorlage befinden. Die durchschnittliche Länge der Texte innerhalb der Links beträgt 1,3 Worte. Das Tool warnt uns davor, dass zu viele Hauptnavigationslinks die Einfachheit des Designs vermindern und das Leseverständnis erschweren. Es lobt uns jedoch für die kurze Länge unserer Link-Texte, denn in diesem Hinblick sind die Navigationslinks sehr einfach gestaltet.

Das Tool hat ebenfalls festgestellt, dass wir Verdana als Schrift für die Hauptnavigation gewählt haben, was eine Schriftart ist, die für eine verbesserte Bildschirmlesbarkeit entworfen wurde. Die Schriftgröße ist die Advanceschriftgröße des Browsers. Das Tool lobt uns erneut für unsere Wahl der Schriftart und Schriftgröße, wohingegen sich der Kontrast in einem akzeptablen Bereich befindet.

Unser hypothetisches Tool ist in der Lage diese Beurteilungen zu erstellen, weil es mehr als nur eine oberflächliche Kenntnis von Formatvorlagen besitzt. Es wäre unmöglich, alle Variablen oder Präsentation zu bestimmen, wenn Sie nicht in der Lage sind, auf alle Informationen der Formatvorlagen zuzugreifen.

In Bezug auf eine einfache Darstellung für das Leseverständnis vergibt unser Tool eine Bewertung für jede spezifische Analyse, die zuvor durchgeführt wurde. Dabei ist die Anzahl der Hauptnavigationslinks jedoch eine Ausnahme.

Analyse der Inhalte auf der Homepage. Nach der Auswertung der Vorlage erstellt das Tool eine Analyse der Homepage. Es hat festgestellt, dass 206 Links (die Vorlage nicht mitgerechnet) und 4 Bilder vorhanden sind, die im Zusammenhang mit den Kopfzeilen stehen (wir haben bereits zuvor die semantische Bedeutung von „Kopfzeilen“ in unserem Tool als ein „Inhaltselement“ der Homepage definiert).

Das Tool weist darauf hin, dass unsere Schriftgröße etwa 60 % für den Hauptinhalt beträgt, was für die meisten Leser zu klein ist. Die Zeilenhöhe beträgt hingegen 1.2em, was innerhalb eines akzeptablen Bereichs liegt (das Tool verwendet akzeptable Bereiche für diese Art von Bewertungen, die in der Advancekonfiguration vorprogrammiert wurden. Diese Werte sind vom Benutzer veränderbar). Es gibt keine unnötigen Großbuchstaben, lange Passagen von kursivem Text oder andere potenziell schwierige Darstellungsformen von Text.

Obwohl wir uns in diesem Beispiel anstatt des Inhalts auf die Vorlage konzentrieren, sollte darauf hingewiesen werden, dass das Tool auch andere Aufgaben ausführen kann. Dies ist zum Beispiel eine Zählung der Zeichen, Anzahl von Wörtern, Anzahl der Wörter pro Satz, Anzahl der Sätze pro Absatz, Anzahl von Silben pro Wort, Anzahl der Zeichen pro Wort, Anzahl der passiven Sätze, und so weiter. All dies könnte verwendet werden, um eine Berechnung des Leseniveaus, der Lesbarkeit oder andere Messungen der Lesbarkeit durchzuführen. Trotz der Tatsache, dass diese Messungen als eine unzuverlässige oder ungenaue Darstellung der Lesbarkeit kritisiert wurden, können sie zumindest dazu verwendet werden, um eine grobe Einschätzung der Lesbarkeit zu bieten. Dies kann ein erster Schritt sein, um die Komplexität des geschriebenen Inhaltes zu bewerten.

Die restlichen Webseiten. Das Tool würde in diesem Szenario eine ähnliche Analyse auf den restlichen Webseiten durchführen, um dadurch sicherzustellen, dass jede dieser Seiten unserer Kriterien für eine einfache Darstellung von Inhalten erfüllt. Das Tool würde dann einen Gesamtbericht über die Zugänglichkeit des Szenarios oder des Pfades zur Verfügung stellen. Das Tool könnte Anregungen bieten, um sicherzustellen, dass der Benutzer genau weiß, wie er in diesem Szenario von Anfang bis Ende navigieren kann, was unter Berücksichtigung der Text- und Präsentationselemente geschieht, die bereits vorhanden sind.

Ein besonderes Interessengebiet auf den übrigen Webseiten wäre das Formular (input) für den Wohnort und das Land des Benutzers. In einer szenariobasierten Analyse müssten wir nicht nur die Möglichkeit einer korrekten Antwort bewerten (sprich Werte, die dem Web-Skript ermöglichen Wetterinformationen abzurufen), sondern auch die Möglichkeit von fehlerhaften oder unverständlichen Eingaben. Alle Benutzerfehler müssen korrigierbar sein, wohingegen die Fehlermeldungen sinnvoll, sehr eindeutig und einfach sein müssen.

Künftige Möglichkeiten

Ironischerweise, um Tools zu erstellen, welche sich den Bedürfnissen von Menschen mit kognitiven Behinderungen anpassen, müssen diese Tools ein außergewöhnliches Maß an Intelligenz besitzen. Menschen mit kognitiven Behinderungen benötigen ausgesprochen benutzerfreundliche, prägnante und gut gestaltete Webseiten, vielleicht sogar mehr als der durchschnittliche Benutzer. Eine Einfachheit und Übersichtlichkeit beim Design war schon immer eine der schwierigsten Herausforderungen im Web-Design oder bei der Gestaltung von jeder Art von Informationen.

Je intelligenter unsere Tools sind, desto mehr werden sie in der Lage sein unsere Bedürfnisse zu erfüllen. Im vorherigen hypothetischen Beispiel haben wir angegeben, dass der Benutzer bestimmte Bereiche der Webseite als Vorlage, Kopfzeile oder als einen anderen Teil der Webseite gekennzeichnet hat. Die benutzerdefinierte Bezeichnung dieser Bereiche ist zwar effektiv, aber leider nur sehr grob. Ausgeklügeltere Tools könnten eine Mustererkennung verwenden, um diese Elemente unabhängig vom Benutzer zu identifizieren. Eine solche Funktion wäre sehr nützlich, um Webseiten zu analysieren, deren Entwicklung bereits fertiggestellt wurde (Folge-Analysen), weil dies die Notwendigkeit beseitigen würde, den Code zu ändern.

Tool-Entwickler müssen zudem ausgeklügeltere Methoden entwickeln, um die Lesbarkeit von Texten, die Feinheiten einer Präsentation von Formatvorlagen und die Komplexität von Multimediainhalten zu analysieren. Die Integration eines fortgeschrittenen Zugänglichkeits/Usability-Tools, zum Beispiel in einer Flash erzeugten Umgebung, oder SVG-Autorentools und Videobearbeitungsprogramme ist durchaus möglich. Es ist definitiv vorstellbar, aber wir wissen auch, dass dies ein gewaltiges Unterfangen ist. Solche Tools würden erhebliche Investitionen an Zeit und Geld erfordern. Auf der optimistischen Seite könnten solche Tools einem zweifachen Zweck dienen, um beispielsweise eine bessere Zugänglichkeit für Menschen mit Behinderungen zu ermöglichen und eine Steigerung der Benutzerfreundlichkeit für alle Anwender zu gewährleisten.

Schlussfolgerung

Das Rahmenkonzept, das in diesem Beitrag vorgestellt wurde, ist keine Universallösung, um Tools für kognitive Behinderungen zu erstellen. Es ist vielmehr eine konzeptionelle Erforschung von Möglichkeiten. Die Welt braucht wahrscheinlich nicht noch ein weiteres Tool, um einzelne Webseite zu analysieren und einen Bericht zu erstellen. Tools dieser Art sind bereits reichlich vorhanden, aber diese sind weitgehend ungeeignet. TEXT BEARBEITEN TEXT LÖSCHEN
Die nächste Generation von Tools erfordert ein tieferes Engagement von den Tool-Entwicklern im Hinblick auf die zugrunde liegende Struktur von Webinhalten, deren semantische Bedeutung und den Zweck, für den sie erschaffen wurden (dem Nutzer Informationen mitzuteilen). Die Notwendigkeit für eine Kommunikation wird zu einem noch größeren Problem, wenn der Nutzerkreis auch Menschen mit kognitiven Behinderungen einschließt.

Referenzen

Chisolm, W., Vanderheiden, G, Jacobs, I. (1999) Web content accessibility guidelines 1.0. Retrieved April 1, 2005 from http://www.w3.org/TR/WCAG10/.
Rowland, C. (2004). Cognitive disabilities part 2: conceptualizing design considerations. Retrieved April 1, 2005 from http://www.webaim.org/techniques/ articles/conceptualize/.
Bohman, P. (2004). Cognitive disabilities part 1: we still know too little and we do even less. Retrieved April 1, 2005 from http://www.webaim.org/techniques/articles/cognitive_too_little/.
Bohman, P., Anderson, S. (2004). Toward user-centered, scenario-based planning and evaluation tools. 9th International Conference on Computers Helping People with Special Needs, Paris, France.