Daniel Lutz, wie war die Entwicklung des barrierefreien User-Interfaces von axesWord?

Die WCAG (Web Content Accessibility Guidelines) waren eine gute Start-Norm für meine Arbeit. Was die PDF/UA-Richtlinien für PDFs sind, sind die WCAG für das Web. Da aber im Web und bei Applikationen nicht alles auf die selbe Art und Weise funktioniert, mussten die Richtlinien angepasst werden. Bei machen Standards (z.B. Kontraste) hat es Sinn ergeben, die Vorgaben exakt aus den WCAG zu übernehmen, andere Komponenten mussten abgewandelt werden.

Eine Schwierigkeit war, dass kein grundsätzlich neues User-Interface aufgebaut, sondern mit dem bestehenden Interface gearbeitet wurde. Beim Versuch etwas Bestehendes barrierefrei zu machen, muss ein Kompromiss zwischen der maximalen Barrierefreiheit und der Wirtschaftlichkeit unternommen werden. Wir haben zwei bis drei Monate intensiv an der Entwicklung gearbeitet, aber sind dabei auf Widrigkeiten gestoßen – zum Beispiel bei der Nutzung von Drittanbieter-Software. Im Endeffekt ist man damit auch auf die Umsetzung von Barrierefreiheit vonseiten der Drittanbieter angewiesen, was nicht immer und ausreichend der Fall ist.

Im Endeffekt ist es objektiv nur möglich, die gleichen Informationen für alle – Personen mit und ohne Beeinträchtigung – bereitzustellen. Ob diese Informationen jedoch „gute“ Informationen sind, ist subjektiv und kann nur im Einzelfall entschieden werden (z.B. ob genug Kontextwissen für das Verständnis vorhanden ist). Die Reise ist also nie zu Ende und man wird immer Feedback benötigen, um der maximalen Barrierefreiheit näherzukommen. Mit der neuen Benutzeroberfläche sind wir auf dem Weg dahin und haben meiner Meinung nach bereits ein gutes Maß an Barrierefreiheit erreicht.

Ja! Da wir selbst keine Mitarbeiter mit Sehschwäche o.Ä. haben, wurde die Software von mehreren Experten begutachtet, die auf die Testung barrierefreier Software spezialisiert sind. Eine interessante Anmerkung diesbezüglich: Jeder Anbieter einer solchen Prüfung deckt eine andere Konformitätsstufe bzw. -bereich ab. Ein standardisierter Prüfbogen würde die Arbeit an einer solchen Software enorm erleichtern und zugleich die Vergleichbarkeit gewährleisten.

Wir haben uns dem BITi-Test unterzogen, einem Test speziell für barrierefreie Software, der relativ streng gefasst ist. Er erfüllt ein Konglomerat aus Normen – so werden die WCAG in der Konformitätsstufe AA, die EN sowie ISO mit einbezogen.

Ideal wäre natürlich, das Thema der Barrierefreiheit bei neuen Projekten von Beginn an in die Entwicklung einzubeziehen. Damit kann einigen Problematiken, die bei der späteren Implementierung von Barrierefreiheit entstehen können, vorgebeugt werden.

Darüber hinaus würde ich immer empfehlen, den Schulterschluss mit Menschen zu suchen, die körperliche Einschränkungen haben. Als gesunder Mensch ohne Beeinträchtigung nimmt man die Benutzeroberfläche logischerweise anders wahr. Ein einfacher Tipp, der hilft zumindest ein ungefähres Gefühl dafür zu bekommen, ist, bei geschlossenen Augen einen Screenreader zu benutzen und mit der Software zu arbeiten.

Leider gar nicht, da weder in meiner fachlichen Ausbildung noch im Studium Barrierefreiheit in der Softwareentwicklung ein Thema war. Ich würde mir wünschen, dass es zumindest die Option dafür gibt, zum Beispiel in Form eines Wahlfaches. Grundlegende Themen wie Kontrastverhältnisse, hilfreiche Tools und die gängigsten Richtlinien könnten behandelt werden. Tiefergehendes Wissen entsteht natürlich erst, wenn man in diesem Bereich arbeitet und konkrete Anforderungen erfüllen muss.

Das Projekt ist nicht abgeschlossen. Wir sind nun auf die Anwendung der Software von Menschen mit Beeinträchtigungen angewiesen, von denen wir uns Feedback – sowohl positive Anmerkungen als auch konstruktive Kritik – erhoffen. Aus der Bearbeitung von konkreten Fällen, die beim Support eingehen, können wir schließen, welche Komponenten überarbeitet werden müssen. Es wird ein stetiger Fluss der Entwicklung sein: aktuelle Version – Feedback – Überarbeitung – neue Version.