Daniel Lutz, wie war die Entwicklung des barrierefreien User-Interfaces von axesWord?
Bisher war die Erstellung barrierefreier Dokumente nur für Menschen ohne Sinneseinschränkungen möglich. Mit dem neuen User-Interface von axesWord können auch Personen, die beispielweise eine Sehbeeinträchtigung haben, barrierefreie Dokumente erstellen. Wir haben mit unserem Entwickler Daniel Lutz gesprochen, der an der Software gearbeitet hat.
Daniel, bisher gab es noch keine Software zur Erstellung barrierefreier Dokumente, die mit barrierefreiem User-Interface gearbeitet hat.
Wie bist du an die Entwicklung herangegangen? Woran hast du dich orientiert?
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.
Welche Herausforderungen gab es und wie bist du diesen begegnet?
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.
Ist es überhaupt möglich, maximale Barrierefreiheit zu erreichen?
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.
Daniel Lutz, Entwickler bei axes4axes4 GmbHDie 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.
Wurde in der Entwicklung mit betroffenen Personen zusammengearbeitet?
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.
Welche Standards erfüllt die axesWord-Software im Endeffekt?
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.
Hintergrund: Der BITi-Test
Der BITi-Test ist ein Instrument zur Beurteilung barrierefreier Software. An der Entwicklung des Tests haben Experten für barrierefreie IT gearbeitet unter der Förderung des Bundesministerium für Arbeit und Soziales. Der BITi-Test vereint die geforderten Standards des Behindertengleichstellungsgesetzes (BGG) aus dem Jahre 2016 sowie der Beschaffungsrichtlinie des öffentlichen Dienstes (EU-Richtlinie 2014/24) und arbeitet entlang eines standardisierten Punktekatalogs.
Hast du Tipps für andere Entwickler*innen, die vor ähnlichen Herausforderungen stehen?
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.
Daniel Lutz, Entwickler bei axes4axes4 GmbHIdeal 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.
Wie gut hat deine Ausbildung dir bei der Entwicklung barrierefreier Software geholfen?
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.
Was sind die nächsten Schritte nach dem Release der neuen axesWord-Version mit barrierefreier Benutzeroberfläche?
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.