Kollaboratives Intranet Anforderungen an das Autorenwerkzeug

Eine Menschenmenge bewegt sich in Richtung eines Intranet-Schildes; eine Hälfte der Menschenmenge benutzt die Treppe, die andere Hälfte benutzt eine Rolltreppe.

Als ich neulich eingeladen war, die Vorstellung mehrerer Bewerber für die Umsetzung eines kollaborativen Intranets vor dem Hintergrund der Barrierefreiheit mit zu bewerten, war ich über zwei Aspekte überrascht. Zum einen wurde von den Bewerbern zu oft angenommen, dass es nur ein begrenztes Redakteursteam gäbe, und zum anderen wurde zu oft angenommen, dass Menschen mit Behinderungen keine Inhalte zum Intranet beitragen würden. Damit waren die betroffenen Bieter selbstverständlich aus dem Rennen raus. Erst recht konnten die Anbieter nicht in Erwägung gezogen werden, die keine konkreten Informationen zur Barrierefreiheit im Frontend sagen konnten.

Drei Aspekte der Barrierefreiheit

Die Webseiten eines Intranets mit vielen tausenden potenziellen Nutzern muss selbstverständlich möglichst barrierefrei sein. Die Anforderungen dazu werden in den Erfolgskriterien der Web Content Accessibility Guidelines (WCAG) 2.0 beschrieben.

In einem kollaborativen Intranet werden darüber hinaus sehr viele Nutzer Inhalte einstellen können. Es werden zwar einerseits zentrale Organisationseinheiten Inhalte über das Intranet verteilen, aber andererseits werden Nutzer vorhandene Beiträge kommentieren oder eigene Beiträge verfassen. Dadurch erhalten barrierefreie Eingabemasken in einem kollaborativen Intranet eine große Bedeutung.

Wenn viele Menschen Inhalte zu einem Intranet beitragen, werden die Inhalte selbstverständlich eine unterschiedliche Qualität aufweisen. Genauso wie es gut verständliche und weniger verständliche Texte geben wird, wird es auch gut nutzbare und weniger barrierefreie Inhalte geben. Deshalb sollte das System, dass für die Eingabe und Organisation der Inhalte eingesetzt wird, Nutzer bei der Eingabe barrierefreier Inhalte unterstützen. Die Barrierefreiheit eines Autorenwerkzeugs für ein Intranet spielt somit eine Rolle auf drei Ebenen:

  1. Das Autorenwerkzeug selbst muss barrierefrei nutzbar sein.
  2. Autoren müssen Informationen und Funktionen erhalten, um Inhalte auch barrierefrei zu gestalten.
  3. Das Frontend muss barrierefrei sein.

Während der dritte Aspekt in den Erfolgskriterien der WCAG 2.0 ausführlich behandelt wird, werden die Kriterien für die ersten beiden Aspekte in den Authoring Tool Accessibility Guidelines (ATAG) 2.0 konkretisiert.

Barrierefreiheit der Autorenwerkzeuge

Zusammengefasst muss ein barrierefreies Autorenwerkzeug folgendes erfüllen:

  • Das Autorenwerkzeug selbst sollte möglichst barrierefrei und beispielsweise konform zur WCAG 2.0 sein (sofern das Werkzeug Web-basiert ist). Wenn das System nicht Web-basiert ist, müssen die Barrierefreiheitsrichtlinien der jeweiligen Entwicklungsumgebung beachtet werden.
  • Bei der Eingabe müssen diverse Informationen technisch (und auch beispielsweise Screenreadern) verfügbar gemacht werden. Hierzu zählen Alternativtexte von Grafiken oder Untertitel für Videos, aber ebenso der Zugriff auf Statuszeilen oder das Auslesen von Informationen zum Format und Layout über den Accessibility-Tree des Betriebssystems.
  • Die Eingabe muss für verschiedene Nutzergruppen bedienbar und insbesondere vollständig und effizient per Tastatur steuerbar sein. Auch müssen Zeitbeschränkungen vermieden werden und benutzerdefinierte Bildschirmeinstellungen möglich sein.
  • Das Autorenwerkzeug muss Möglichkeiten bieten, Eingaben (und insbesondere Fehleingaben)zu korrigieren bzw. rückgängig zu machen. Darüber hinaus sollte jede Funktion des Autorenwerkzeugs dokumentiert werden.

Unterstützung der Autoren

Ein Autorenwerkzeug muss außerdem die Autoren bei der Eingabe barrierefreier Inhalte unterstützen:

  • Automatisierte Prozesse müssen barrierefreien Code produzieren oder den Autoren die Möglichkeit geben, den Code entsprechend anzupassen. Insbesondere darf barrierefreier Inhalt z.B. beim Kopieren aus einer Textverarbeitung oder bei anderen Umwandlungsprozessen nicht entfernt oder in Teilen verloren gehen. Das betrifft vor allem Strukturen, Alternativtexte für Grafiken und andere Eigenschaften des Inhalts, die für eine WCAG-konforme Webseite notwendig sind.
  • Wenn Autoren Inhalte in einem Autorenwerkzeug einstellen, dann muss es möglich sein, barrierefreie Inhalte zu erstellen. Beispielsweise sollten in einem Redaktionssystem Grafiken eine lange Beschreibung erhalten können (auch wenn sie nicht immer eine benötigen). Die Förderung von angemessenen Textalternativen für nicht-textlichen Inhalt ist eine zentrale Aufgabe eines Autorenwerkzeugs. Gleichermaßen müssen bei verschiedenen Umsetzungstechniken für eine konkrete Aufgabe die Lösungen für eine WCAG-konforme Umsetzung vom Autoren leicht auffindbar sein. Autoren müssen ebenfalls zugängliche HTML- und Inhaltsvorlagen identifizieren und auswählen können.
  • Wenn Inhalte eingestellt werden, müssen Autoren ihre Ergebnisse auf WCAG-Konformität überprüfen können (z.B. mit integrierten Werkzeugen oder anhand von Anleitungen). Bei werkzeugunterstützten Überprüfungen sollten die Ergebnisse dokumentiert werden. Nach Möglichkeit sollte die Behebung von Barrieren vom Werkzeugen unterstützt werden.
  • Sofern ein Autorenwerkzeug optionale Features zur Förderung der Barrierefreiheit umfasst, müssen diese standardmäßig eingeschaltet sein(ähnlich wie bei einer Rechtschreibprüfung). Bei Deaktivierung solcher Features müssen Autoren über die Konsequenzen informiert werden, und sie müssen die Optionen leicht wieder finden können. In der Dokumentation des Autorenwerkzeugs sind insbesondere WCAG-konforme Beispiele zu verwenden und außerdem die Accessibility-Features zu erklären. Weitere Unterstützung der Autoren wie z.B. die Bereitstellung von Tutorien und ein Stichwortverzeichnis für die Accessibility-Features ist ebenfalls zu empfehlen.

ATAG-konforme Autorenwerkzeuge

Die ATAG 2.0 bietet neben den Anforderungen an barrierefreie Autorenwerkzeuge auch eine Empfehlung für die Implementierung. Das Dokument liefert zwar Erklärungen und Beispiele für gute Autorenwerkzeuge, aber derzeit stellt es eher ein „Best Of“ einer großen Zahl an Autorenwerkzeugen dar. Mir ist kein Autorenwerkzeug bekannt, das allen Anforderungen der ATAG 2.0 genügt.

Unter dem Strich muss die Qualität eines Autorenwerkzeugs stets neu bewertet werden. Nicht nur die WCAG-Konformität der Ausgabe, sondern die ATAG-Konformität des Backends müssen intensiv getestet werden. Das W3C hat früher Autorenwerkzeuge bewertet, aber neuere Produktübersichten habe ich nicht gefunden.

In der Praxis gehe ich immer noch davon aus, dass ein Autorenwerkzeug nicht ATAG-konform ist, aber ich muss das System nutzen können. Das heißt, dass für jedes neue Projekt zunächst geschaut wird, ob ein vorgesehenes Redaktionssystem mit einem Screenreader nutzbar ist bzw. ob die konkreten Aufgaben mit einem Screenreader erledigt werden können. In der Regel sind sie es (alle) nicht, aber es hat deutliche Verbesserungen in den letzten Jahren gegeben. Für einen Blog ist beispielsweise WordPress schon seit einigen Jahren gut nutzbar – vorausgesetzt, man kennt sich mit HTML-Code aus.

Bei der Pitch-Veranstaltung spielte die Barrierefreiheit bei den meisten Anbietern keine besondere Rolle. Bei den auf Intranet spezialisierten Lösungen hatten die Vorstellenden Schwierigkeiten, überhaupt einen Bezug zur Barrierefreiheit herzustellen. Bewerber, die mit einem klassischen CMS ins Rennen starteten, konnten schon etwas mehr zur Barrierefreiheit sagen, aber keiner konnte eine überzeugende Referenz vorweisen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.