Journalismus & Barrierefreiheit: Wie prüfen wir unser Autor*innensystem auf Barrierefreiheit?

Heutzutage ist der größte Teil unseres Wissensmanagements digital in Form von Internetseiten oder Dokumenten. Wenn wir etwas nicht verstehen, googeln wir es. Wenn wir ein historisches Ereignis nachschlagen wollen, gehen wir zu Wikipedia. Und wenn wir die neuesten Nachrichten sehen wollen, öffnen wir unseren Feed.

Mit Autor*innensystemen erzeugte Webseiten sind weit verbreitet

Da ist es nur logisch, dass wir auch Software brauchen, die uns bei der Erstellung all dieser Dateien und Informationen unterstützt. Diese Rolle übernehmen oft sogenannte Autor*innensysteme, Programme, mit denen wir auf einfache Weise Dokumente und Publikationen erstellen können. Das ist einerseits für Journalist*innen relevant – aber auch für Unternehmen. Denn auch in unserem Unternehmen nutzen wir Autor*innensysteme – beispielsweise für das interne Wissensmanagement oder unsere öffentliche Webseite.

Der Begriff Autor*innensystem klingt zunächst etwas sperrig. Umgangssprachlich könnten wir sagen: Es ist eine Softwareanwendung, mit der wir eine andere Softwareanwendung bauen. Der Fokus liegt auf den Inhalten: Beispielsweise wird in einem Web-CMS wie WordPress, Joomla, TYPO3, Drupal, Wix.com oder Shopify mit Hilfe einer Webanwendung (dem Backend) eine Webseite (das Frontend) erstellt.

Viele Webseiten werden inzwischen ohne Programmierkenntnisse erstellt

Vor allem im Rahmen der Digitalisierung werden immer wieder neue Kompetenzen benötigt, um mit den andauernd wachsenden Herausforderungen des Internets und digitaler Landschaften mithalten zu können. Dabei existiert eine signifikante Menge an Personen, welche nicht mit Technologien aufgewachsen sind und daher nicht alle nötigen Skills zum Erstellen von Internetseiten und Ähnlichem haben.

Und auch Software mit Baukasten-Charakter, in welcher wir einzelne Web-Elemente zusammensetzen und anordnen, kann für Manche zu komplex sein. Diese Kompetenzlücke versuchen Autor*innensysteme nun zu schließen, indem sie Nutzer*innen dazu befähigen, eigene Seiten, Dokumente und Lernmittel zu gestalten. Diese können entweder online oder offline angeboten werden und an verschiedene Wissensstände der Benutzer*innen angepasst sein.

Ein Autor*innensystem bietet eine einfache Leinwand für alle

Die Besonderheit hier ist, dass Autor*innensysteme meist explizit keine Programmierkenntnisse von ihren Benutzer*innen verlangen und häufig nach dem “What-You-See-Is-What-You-Get”-Prinzip arbeiten. Sie sind häufig an die durchschnittlichen Benutzer*innen angepasst und können teilweise in ihrer Funktion nur auf das Nötigste reduziert sein. Teilweise sind aber auch Autor*innensysteme mit fortgeschrittenen Funktionalitäten und Features ausgestattet, welche erfahrenen Benutzer*innen die Arbeit erleichtern und helfen, effizienter zu arbeiten.

Die Bandbreite verschiedener Anwendungen und Kompetenzniveaus ist hierbei nahezu unendlich. Grundsätzlich sind Autor*innensysteme wie eine leere Leinwand zu verstehen, die mit Inhalt gefüllt werden kann. Umso wichtiger: Wie gut werden wir als Autor*innen in diesem Prozess dabei unterstützt, dass am Ende barrierefreie Softwareanwendungen entstehen?

You can do anything you want. This is your world.

Bob Ross

Autor*innensysteme spielen eine zentrale Rolle für die Barrierefreiheit unserer Webseiten

Bevor wir näher auf die Rolle von Autor*innensystemen gemäß der Barrierefreiheitsnorm DIN EN 301 549 der Europäischen Union eingehen, müssen wir einen kleinen Exkurs in den Aufbau des Dokuments machen (falls Sie sich aber bereits mit der aktuellen Fassung auskennen und stattdessen lieber etwas über die neuesten Updates zu wichtigen Normen erfahren wollen, dann empfehlen wir Ihnen “Wissenschaftlich fundierte Usability und User Experience: Welche vier neuen Normen sollten UUX Expert*innen kennen?”).

Für Autor*innensysteme sind drei Abschnitte der DIN EN 301 549 besonders wichtig

Die Norm ist in neun Abschnitten organisiert, welche sich thematisch mit jeweils einem Bereich digitaler IKTs (Informations- und Kommunikationstechnologien) auseinandersetzen. Für das Verständnis der Rolle von Autor*innensystemen innerhalb der Norm sind besonders folgende Abschnitte relevant:

• 9 Web: Hier befinden sich alle Prüfschritte, welche sich mit der Begutachtung von Internetseiten und Anwendungen im Internet auseinandersetzen.
• 10 Nicht-Web Dokumente: Dies sind alle Prüfschritte speziell für Dateien, welche Informationen beinhalten, aber nicht im Internet angeboten werden. Ein bekanntes Beispiel hierfür ist das Dateiformat “PDF”.
• 11 Software: Alle Prüfschritte, die sich auf Software beziehen, sind hier gesammelt. Es wird zudem noch einmal zwischen Anwendungen mit integrierten Barrierefreiheitsfunktionen und ohne solche unterschieden.

In diesen Abschnitten finden sich alle für die Evaluation relevanten Prüfschritte, welche eine barrierefreie Nutzung der Anwendung oder des Dokuments ermöglichen. Hierbei referenzieren diese unter Umständen auch andere Richtlinien wie die WCAG, welche besonders im Abschnitt “Web” relevant ist. Sie wird aber auch in den Abschnitten “Nicht-Web Dokumente” und selbst “Software” durchaus auftauchen können (falls Sie mehr zu den Unterschieden und Gemeinsamkeiten der Norm 301549 und WCAG erfahren möchten, finden Sie im Blogbeitrag “Barrierefrei nach WCAG 2.1 – oder: Was für die Erfüllung der BITV 2.0 wirklich zählt” dazu nähere Informationen).

Die Prüfung von Autor*innensystemen anhand der DIN EN 301 549

Haben Autor*innensysteme jetzt ihren eigenen Abschnitt in der Norm? Die kurze Antwort ist “Nein”, aber es ist etwas komplizierter…

In der Norm sind die Autor*innensysteme nicht als ein eigener Bereich gelistet und haben keinen eigenen Prüfschrittkatalog wie zum Beispiel Web-Anwendungen. Das bedeutet aber nicht, dass die Norm Autor*innensysteme vergessen hat oder nicht berücksichtigt. Autor*innensysteme tauchen in der Norm auf, nur sind diese etwas versteckt: Wir finden sie im Abschnitt 11 “Software”, wo sie einen Teilabschnitt mit fünf Prüfschritten haben, die ebenfalls für webbasierte Autor*innensysteme gelten. Und diese fünf Prüfschritte sind etwas knifflig.

Wenn wir einen Blick in die Norm werfen, dann beinhalten die meisten Prüfschritte Prüfkriterien für einen bestimmten Aspekt oder eine bestimmte Funktionalität einer IKT. Diese sind meist messbar oder setzen auf die Erfüllung eines konkreten und spezifischen Prüfschrittes. Ein Beispiel hierfür sind Farbkontraste bei großen Texten, welche 3:1 betragen müssen, mit einer Formel berechenbar sind und durch ein Tool eindeutig bestimmt werden können [1]. Die fünf Prüfschritte für Autor*innensysteme sind in Bezug auf Formulierung aber anders.

Hier wird nicht eine Menge an einzelnen Prüfschritten geliefert, welche konkrete Aspekte und Funktionen prüfen sollen. Stattdessen referiert die Norm auf sich selbst und besagt, dass die Ergebnisse des Autor*innensystems konform zu allen Prüfschritten der Abschnitte “Web” und “Nicht-Web Dokumente” sein müssen.

Der Prüfprozess für Autor*innensysteme muss in der Praxis einige Hürden überwinden

Als Unternehmen, welches sich unter anderem auf die Begutachtung von internen Softwareanwendungen auf Basis der DIN EN 301 549 spezialisiert, haben wir regelmäßig mit der Evaluation von Autor*innensystemen zu tun. Da dieser Abschnitt der Norm nun aber keine konkreten Prüfschritte wie die restliche Norm vorgibt, mussten wir einen eigenen Prüfprozess entwickeln.

Der erste Schritt unsere Begutachtungsprozesses ist die Unterteilung der Anwendung in einzelne Teilbereiche: Die Anwendung selbst, die Standardausgabe und die Exportfunktion. Diese drei Bereiche, welche aber nicht bei jeder Anwendung vorhanden sein müssen, werden dann von uns separat voneinander geprüft und evaluiert.

Schritt 1: Die EN 301 549 führt durch die Prüfung der Oberfläche des Autor*innensystems

Die grafische Benutzeroberfläche der Anwendung umfasst aus der Perspektive der Autor*innen zum Beispiel alle Schaltflächen, Texte, Menüs, Grafiken und Interaktionselemente, mit denen die Benutzer*innen interagieren können. Hier wird auch das Autor*innensystem selbst betrachtet.

Am Beispiel von Microsoft Word würde in diesem Schritt bewertet werden, ob alle Schaltflächen barrierefrei erreichbar sind, ob die Anwendung nur mit einer Tastatur bedient werden kann, inwieweit Farbkontraste ausreichend hoch gewählt wurden und ob beispielsweise Screenreader die Inhalte problemlos wiedergeben können.

Dazu wird die EN 301549 wie bei jeder anderen Webanwendung oder Software verwendet. Das Ergebnis dieses Prüfschrittes ist ein erstes Gutachten, das dann durch die Bewertung der erstellten Inhalte ergänzt wird.

Schritt 2: Für die vom Autor*innensystem erzeugte Standardausgabe müssen alle Prüfschritte erneut durchlaufen werden

Nachdem die grafische Oberfläche des Autor*innensystems getestet wurde, muss nun beispielsweise die vom Autor*innensystem erstellte Webseite ausgewertet werden. Dabei gibt es zwei Hauptaspekte, auf die wir uns konzentrieren müssen: Werden die Elemente barrierefrei dargestellt und unterstützt das Autor*innensystem die barrierefreie Gestaltung?

Die Elemente in der Standardausgabe müssen barrierefrei dargestellt werden

Der erste Aspekt ist relativ schnell erklärt, da er sich nicht von der “grafischen Oberfläche” unterscheidet. Wir prüfen, ob das Endergebnis barrierefrei zugänglich ist und ob das gewählte Format barrierefrei ist. Hier werden die entsprechenden Prüfschritte aus den Abschnitten 9 “Web” für Webseiten und 10 “Nicht-Web-Dokumente” für z.B. PDF- oder Word-Dateien getestet.

Die Autor*innen muss die barrierefreie Gestaltung ermöglicht werden

Der zweite Aspekt ist etwas umfangreicher. Hier liegt der Schwerpunkt auf “unterstützen” und “ermöglichen”. In diesem Testprozess konzentrieren wir uns bei Nestler UUX Consulting auf die Möglichkeiten des Autor*innensystems, barrierefreie Inhalte zu generieren. Mögliche Fragen, die wir uns stellen, sind beispielsweise:

• Kann ein Bild durch einen Alternativtext ergänzt werden, welcher den Inhalt beschreibt?
• Können verschiedene Überschriftenhierarchien eingestellt werden, um die Navigation mit Screenreadern zu verbessern?
• Können Links durch weitere Informationen genauer beschrieben werden, welche die Zielseite mitteilen?
• Wie schwer ist es, die Funktionen zu nutzen? Können die Funktionen barrierefrei genutzt werden?

Widersprüchlichkeiten zwischen den Perspektiven müssen aufgelöst werden

Einige dieser Prüfschritte können sich durchaus mit vorausgehenden Evaluationen überschneiden, da diese bereits bei der Überprüfung der grafischen Oberfläche vorkommen können. Hier ist der Fokus deutlich stärker bei der Möglichkeit der Umsetzung als bei den Interaktionselementen, welche zur Umsetzung benötigt werden.

Autor*innen müssen über Probleme in Bezug auf die Barrierefreiheit informiert werden

Abschließend prüfen wir, ob und wie das System die Benutzer*innen bei der barrierefreien Gestaltung unterstützt und möglicherweise sogar auf Barrieren hinweist. Dies könnte konkret folgendermaßen umgesetzt werden:

• Das Autor*innensystem zeigt eine Warnung an, wenn ein Bild keinen Alternativtext hat.
• Benutzer*innen werden darauf hingewiesen, wenn der Farbkontrast von Text zum Hintergrund zu gering ist oder für farbenblinde Menschen problematische Farbkombinationen genutzt werden (beispielsweise grün-rot).
• Die Anwendung bietet verschiedene Vorlagen zur Erstellung von Inhalten an, welche barrierefreie Gestaltung unterstützen.

Schritt 3: Bei allen Exportfunktionen wird die korrekte Übernahme der Barrierefreiheitsinformationen geprüft

Der letzte Schritt in unserem Begutachtungsprozess für Autor*innensysteme ist die Bewertung des Exports oder der Konvertierung von Formaten. Dies muss zum Beispiel geprüft werden, wenn ein Autor*innensystem seine Publikationen als Internetseite speichert, seinen Benutzer*innen aber die Möglichkeit gibt, sie als PDF-Datei herunterzuladen.

Hier ist vor allem zu prüfen, ob alle vorhandenen Informationen zur Barrierefreiheit adäquat übernommen und exportiert werden. Ein Beispiel hierfür sind Alternativtexte zu Bildern: Wenn das Bild auf der Internetseite einen solchen Alternativtext hat, dann muss dieser auch nach dem Export bzw. der Umwandlung in eine PDF-Datei entsprechend erhalten bleiben. Hier prüfen wir bei Nestler UUX Consulting gemäß Abschnitt 10 “Nicht-Web-Dokumente”.

Fazit: Die Rolle von Autor*innensystemen in Bezug auf die Barrierefreiheit wird in der Praxis häufig unterschätzt 

Fünf Testschritte, aber viel Arbeit: So lässt sich die Evaluierung von Autor*innensystemen treffend beschreiben. Dabei handelt es sich um komplexe Funktionalitäten, die oft aus mehreren verschiedenen Teilfunktionen bestehen, die alle einzeln getestet bzw. bewertet werden müssen. Und obwohl wir bei Nestler UUX Consulting einen eigenen Testprozess entwickelt haben, um diese zu begutachten, stellt sich für uns die Frage, ob nicht ausführlichere Testschritte in der Norm sinnvoll wären.

Abschließend lässt sich sagen: Natürlich müssen wir auch Autor*innensysteme, wie alle anderen Angebote innerhalb und außerhalb des Internets, auf bestmögliche User Experience, Usability und Barrierefreiheit prüfen.

Ein so großer Teil unseres Lebens findet mittlerweile online statt und eine einfache Möglichkeit, Inhalte zu generieren, hilft enorm, Menschen mit geringer digitaler Kompetenz einzubinden. Wir müssen immer auch an die Menschen denken, die ohne barrierefreies Design von diesem großen Teil unserer Welt ausgeschlossen sind. Ein durch die Norm standardisierter Prüfprozess könnte die Gestaltung vereinfachen und feste Richtlinien liefern, um zumindest die offensichtlichsten Probleme zu beheben. Dies könnte auch Gestalter*innen und Programmierer*innen motivieren, sich mehr mit den Aspekten eines barrierefreien Autor*innensystems auseinanderzusetzen, ohne Angst haben zu müssen, sich in Normen zu verlieren.

Weiterführende Links

[1] https://barrierefreies.design/barrierefreiheit-interaktiv-testen/farben-und-kontraste-pruefen