© Roman Zaiets / 123rf.com

Barrierefreiheit in Webapplikationen gehört zu den wichtigen, aber aufwendigen Aufgaben. Der Hersteller des Open-Source-Knowledgemanagementsystems BlueSpice hat einige Erfahrungen gesammelt.

Die Webseite http://digitale-barrierefreiheit.info der Gesellschaft für digitale Barrierefreiheit prüft regelmäßig Internetauftritte auf ihre Barrierefreiheit. Die Informationsplattform listet die “zehn besten barrierefreien Webangebote” auf und bietet Firmen einen Test für den eigenen Internetauftritt an [1]. Auf den vorderen Plätzen des Rankings finden sich das Bundesministerium für Arbeit und Soziales, die BBC, Apple, aber auch Shops wie der von Eurowings oder der Outdoor-Marke Patagonia.

Schon beim Studium der Seite, der bewerteten Kandidaten und der Kriterien klärt sich schnell: Das Thema Barrierefreiheit geht tiefer als oft wahrzunehmen ist – und gleicht schnell dem sprichwörtlichen Kaninchenbau, in Anspielung an Alice im Wunderland. Für Menschen mit Sehschwächen dagegen gehört die schier unendliche Komplexität der Barrierefreiheit in der IT zum bitteren Alltag. Daran hat sich auf den ersten Blick kaum etwas geändert, seitdem das Linux-Magazin im Jahr 2008 einen blinden Programmierer [2] besuchte.

Doch eines ist anders: Der Druck steigt. Ab dem 28. Juni 2025 müssen “Produkte, die online angeboten werden, auch barrierefrei hergestellt und vertrieben beziehungsweise angeboten und erbracht werden”. Das sagt das Barrierefreiheitsstärkungsgesetz (BFSG) [3]. Damit folgt die Bundesrepublik [4] dem Gesetz zur Umsetzung der Verordnung (EU) 2019/882 (European Accessibility Act, EAA) des Europäischen Parlaments und des Rats über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen. Ab Mitte 2025 gibt es also keine Ausrede mehr – könnte man zumindest meinen. Trotzdem kommt die neue Regelung für viele überraschend.

Wissen gefragt

Die gesetzlichen Pflichten kollidieren außerdem massiv mit dem allgegenwärtigen Fachkräftemangel. Unternehmen brauchen und suchen verzweifelt Experten für Barrierefreiheit. Nur wer sich in der Tiefe mit der Materie befasst hat, kann ohne Scheuklappen und Betriebsblindheit agieren und erkennt beispielsweise die für Sehbehinderte offenkundigen Probleme.

Für Barrierefreiheit benötigen Unternehmen Experten, im Optimalfall gibt es sogar ein eigenes Team mit Bezug zum Thema, also mit Einschränkungen. “Für Entwickler und Entwicklerinnen ist erst einmal unklar, wie man beispielsweise einen Screenreader anwendet oder steuert. Da hilft nur, sich mit einem Sehbehinderten zusammenzusetzen, um zu sehen, wie er den Reader praktisch verwendet. Dann lernt man schnell: Sehbehinderte gehen ganz anders damit um”, berichtet Richard Heigl, CEO bei der Hallo Welt! GmbH aus Regensburg.

Webapps

Dabei lässt sich eine komplexe Webanwendung wie das an Atlassians Confluence erinnernde BlueSpice [5] der Hallo Welt! deutlich schwieriger auf WCAG- und BITV-Konformität trimmen als zum Beispiel eine einfache Webseite – Open Source hin oder her. Internationale Leitlinien wie die Web Content Accessibility Guidelines (WCAG) [6] regeln die Anforderungen an die Barrierefreiheit. Vom World Wide Web Consortium (W3C) entwickelt, bilden sie weltweit die Grundlage für zahlreiche gesetzliche Regelungen zur Barrierefreiheit. Zwar werden sie im BFSG nicht direkt genannt, spielen aber dennoch eine wichtige Rolle beim Erfüllen der digitalen Anforderungen.

Die Barrierefreie-Informationstechnik-Verordnung BITV 2.0 [7] hingegen setzt die EU-Richtlinie 2016/2102 um, die sich speziell auf öffentliche Stellen bezieht und auf der europäischen Norm EN 301 549 basiert, die sich wiederum an den WCAG 2.1 orientiert. Nicht unbedingt hilfreich ist in dem Kontext, dass das BFSG nicht nur öffentliche Stellen, sondern auch private Unternehmen und bestimmte Dienstleistungen betrifft.

Damit handelt es sich um keine direkte Fortsetzung oder Ergänzung der BITV, sondern geht über den öffentlichen Sektor hinaus. Die WCAG können für Webseiten und Webanwendungen relevant sein, das BFSG umfasst zusätzlich auch Hardwareprodukte. Und die Europanorm EN 301 549 verweist explizit auf WCAG als Technik. Da geht allzu leicht jeglicher Überblick verloren.

A und O

Bei Hallo Welt! setzt man sich schon länger mit den ab Juni 2025 geltenden Vorschriften auseinander. Das Thema kam wie so oft “durch eine Mitarbeiterin in die Firma, die sich dafür interessierte”, so Heigl. “Damit hatten wir das Glück, gleich jemand zu haben, der sich der Sache annimmt und sie vorantreibt. Ich glaube nicht, das so ein komplexes und bisweilen komplett neues Thema ohne hochmotivierte Mitarbeiter oder Teams vorankommt.”

Viele Unternehmen bemerken erst jetzt, was für ein großer Berg an Arbeit da auf sie zukommt. “Auch wir kamen zunächst nach einer Prüfung zu der Erkenntnis, dass unser Wiki nicht unter das BFSG und die im Gesetz genannten Dienstleistungen fällt. Richtig ist aber, dass auch für BlueSpice die BITV gilt und es barrierefrei sein muss, wenn es in öffentlichen Behörden und von Steuergeldern finanzierten Organisationen genutzt wird”, erklärt Heigl.

Spätestens wenn die Software im Web Informationen für Endverbraucher anbietet, fällt es schwer, sich aus der Verantwortung zu stehlen. Je mehr allerdings die Begriffe in Ausschreibungen auftauchen, umso mehr realisierten Softwarehersteller in den letzten Jahren, dass hier sie viel Arbeit und Geld investieren müssen. An sich bietet das keinen großen, bewerbbaren Return on Investment (ROI). Ohne sie gewinnt man im öffentlichen Bereich aber sprichwörtlich keinen Blumentopf mehr.

Utopie

Wer sich die erwähnte Webseite http://digitale-barrierefreiheit.info und die dort genannten Produkte genauer anschaut, kommt flott zu dem Schluss: Barrierefreie Webseiten lassen sich einfach erreichen, barrierefreie Webapplikationen dagegen sind mit deutlich mehr Aufwand und Schwierigkeiten verbunden.

Richard Heigl erläutert: “Wir müssen dafür sorgen, dass auch jede Funktionalität WCAG-konform ist. Vom Seiten-Editieren reicht das über die persönlichen Einstellungen bis zu Workflows und Vorlagen. Hier ist oft schwer zu entscheiden, wo man anfängt und wo man aufhört. 100 Prozent WCAG-Konformität ist da unrealistisch.”

Laut Heigl genügt es eben nicht, kurzerhand einige Labels zu ergänzen. Manche Änderungen erzwingen eine komplett neue Architektur. Allein die dafür notwendige Planung zieht einen hohen Kommunikationsaufwand in der Produktentwicklung nach sich. “Eigentlich muss man für die Barrierefreiheit ein eigenes Team aufstellen”, resümiert der Hallo-Welt!-CEO. Weil Open-Source-Accessibility-Experten allerdings sowohl selten als auch teuer sind, sucht man in Regensburg bereits seit einer Weile nach Verstärkung.

Erfolg nicht garantiert

Dabei ist ein positives Ergebnis für die Investitionen keineswegs ausgemacht. “Vor Gericht und in Zertifizierungen ist man immer auf hoher See”, weiß Heigl. Vorab ließe sich schlicht nicht einschätzen, worauf geachtet wird und worauf nicht. Für Open-Source-Projekte ist das weniger problematisch, für Open-Source-Firmen hingegen schon. Wer wie die Hallo Welt! ein OSS-Projekt wie Mediawiki gleichzeitig als Down- und Upstream hat, merkt zügig, dass es wirklich kompliziert ist. Die Wikipedia hat schließlich ganz andere Anforderungen, auch durch ihre Internationalität. Eine oder mehrere gemeinsame Open-Source-Bibliotheken für Barrierefreiheit wären sinnvoll, sind aber nicht in Sicht.

Da müssten die Hersteller eben lernen, ganz anders zusammenzuarbeiten, Best Practices auszutauschen und gemeinsam an der Umsetzung der Standards zu arbeiten, sagt der Hallo-Welt!-CTO Markus Glaser. Als Beispiel nennt er PDFs [7]: Um die wirklich barrierefrei zu bekommen, sollte man sich zusammen für Open-Source-Library engagieren. “Wir haben die Erfahrung gemacht, dass diejenigen, die sich ernsthaft um das Thema kümmern, am Ende bessere Marktchancen haben. Aber die Lernkurve und die Aufwände haben auch wir deutlich unterschätzt.”

Gemeinsame Lösung?

Das Problem ist markant: Niemand möchte für Barrierefreiheit in einem Produkt einen höheren Preis bezahlen. Gleichzeitig kostet die Implementierung Hersteller hohe Summen, das Risiko lässt sich kaum kalkulieren. Wer allerdings Ausschreibungen der öffentlichen Hand gewinnen möchte, muss das Thema angehen, oder eben auf die möglichen Erträge aus solchen Ausschreibungen verzichten. Eine gemeinsame Bibliothek, vielleicht gar verwaltet von einer Stelle wie dem ZenDIS und in openCode, könnte das Thema für Hersteller vereinfachen. Geholfen wäre damit der ganzen Gesellschaft.

Ein typisches Beispiel dafür, wie Barrierefreiheit immer wieder durch die Hintertür in Softwareprojekte kommt, hat das Hallo Welt!-Team bei einem Projekt mit dem Bundesministerium für Bildung und Forschung (BMBF) erfahren. Barrierefreiheit zählte dabei zwar nicht zu expliziten Anforderung, aber die Richtlinie sollte passend mit umgesetzt beziehungsweise berücksichtigt werden. Barrierefreiheit galt quasi als Selbstverständlichkeit.

Fürs BMBF hat die Hallo Welt! einen KI-Chatbot im Handbuch der Projektförderung entwickelt, der ausschließlich gesicherte und verlässliche Ergebnisse zur Unterstützung der Entscheider liefern darf. Man einigte sich darauf, dass die Barrierefreiheit im Chatbot nicht besser sein muss, als die Barrierefreiheit in BlueSpice allgemein. Dahingehend prüfen wollte man den Chatbot am Ende des Projekts. Eine Mitarbeiterin bei Hallo Welt! führte den Barrierefreiheitstest anhand der Kriterien der BITV-Prüfliste [8] durch, wobei webbasierte Anwendungen erst mit Prüfschritt 9 starten.

Sämtliche Ergebnisse landeten im internen Wiki und man arbeite damit weiter, auch weil der erste Durchlauf der Prüfliste dem Chatbot keine Barrierefreiheit bescheinigen konnte. Fragen zu Farben, Design und Kontrast ließen sich schneller lösen als dynamische Themen. “Eine besondere Herausforderung lag im Streaming: Der Chatbot SOLL durchschnittlich nach 2 Sekunden, MUSS aber spätestens nach drei Sekunden mit der Antwort beginnen. Deshalb müssen die Antworten gestreamt werden, sodass sie sich Schritt für Schritt aufbauen. Damit kommen Screenreader nicht so gut zurecht, die fangen jedes Mal von vorn an, den Text vorzulesen”, erklärt Glaser. “Was macht man da? Was ist wichtiger Streaming oder Barrierefreiheit?” Die Entwickler behoben das Problem, indem sie den Screenreader erst vorlesen lassen, sobald die Antwort komplett vorliegt. Der Prüfbericht besprach das Hallo!-Welt-Team daraufhin mit dem BMBF. Nach der Freigabe legte es ihn der Projektdokumentation bei.

Screenreader

Screenreader gehören zu den zentralen Softwareprodukten für die Barrierefreiheit. Prinzipiell lesen sie Text (und Bilder) vom Bildschirm vor. Genauer gesagt bereiten sie ihn für Audioausgabe und Braille-Displays vor, um Blinden und Sehbehinderten Zugang zu ansonsten verwehrten Inhalten zu eröffnen.

Mit passenden Meta-Daten ausgestattet, beispielsweise ALT-Tags bei Bildern, erstellen sie ein nicht-visuelles Bild von einer Webseite oder Anwendung. Im Open-Source-Bereich gibt es zwei bedeutende Softwareprojekte: NVDA [9] und Orca [10]. Auch der proprietäre JAWS-Screenreader [11] von Freedom Scientific wirkt den Entwicklern zufolge vielversprechend, kam aber schon wegen der Lizenz nicht in Betracht.

NonVisual Desktop Access

Die Abkürzung NVDA steht für NonVisual Desktop Access, also den nicht-visuellen Zugang zur Arbeitsfläche (Abbildung 1). Das im Jahr 2006 von Michael Curran begonnene Projekt ist zwar überwiegend in Python programmiert und kommt komplett in Open Source (GPL) daher, funktioniert aber nur unter Windows. Es unterstützt Standards wie das Accessibility-Framework von Windows Microsoft Active Accessibility (MSAA), die neuere User Interface Automation oder die Java Access Bridge (JAB).

Abbildung 1: Barrierefrei auch für nicht-eingeschränkte Entwickler ohne Screenreader: NVDA zeigt dem Developer, was es vorlesen würde.

NVDA enthält den Sprachsynthesizer eSpeak und ist zusätzlich mit weiteren Sprachsynthesizer und Braille-Geräte kompatibel. Im Test der Hallo Welt! funktionierte das Werkzeug zuverlässig. Die Agentur, an die die Entwickler das Accessibility-Testing ausgelagert hatten, nutzt den Screenreader ebenfalls. Vielen in der Branche gilt er als Standardreferenz.

Orca

Der zweite verbreitete Open-Source-Screenreader nennt sich Orca und stammt aus dem Gnome-Projekt. Orca bezieht sich dediziert auf das AT-SPI2-Projekt [12] der Freedesktop-Initiative, die damit Inhalte über Dbus auch an Screenreader übergeben möchte. Auch BlueSpice wird damit getestet, die Ergebnisse fallen jedoch durchwachsen aus.

Zwar gibt es Orca für Linux, mit NVDA kann es aber nicht mithalten. “Bei uns hat das nicht zuverlässig funktioniert, Rechner hängten sich auf, alle Entwickler hatten Probleme damit. Oft ist es schwer zu verstehen, was gerade vorgelesen wird”, berichtet Markus Glaser. “Irgendwie erinnert mich das an früher, als man auf verschiedene Browser zu optimieren hatte. Man muss sich irgendwann entscheiden, für welchen Screenreader man die Webseite optimiert.” Die Entscheidung für NVDA beeinflusste zudem die Entwicklungsprozesse, weil die Entwickler überwiegend unter Linux arbeiten, NVDA aber nur unter Windows – Änderungen ließen sich somit nicht sofort prüfen, zusätzliche Testsysteme mussten her.

Von ExtJS nach OOJs

Möchten Sie Barrierefreiheit integrieren, bringt das typischerweise Veränderungen im Tech-Stack mit sich – teilweise sind sie umfangreich und vorher nicht absehbar. In BlueSpice mussten die Entwickler alte Javascript-Bibliothek (Ext JS) [13] vorzeitig durch OOJs [14] ersetzen, um den Stack zu vereinheitlichen und BITV-Compliance zu erreichen.

Im PDF-Backend kommt jetzt eine Bibliothek zum Einsatz, die Barrierefreiheit besser unterstützt: OpenHTML2PDF [15]. “Ursprünglich wollten wir mit mPDF eine andere Bibliothek nehmen, sind dann aber zu OpenHTML2PDF gewechselt, weil sie als einer der wenigen barrierefreie PDFs erzeugt”, erzählt Glaser. “Allerdings wird diese Bibliothek nicht aktiv gepflegt – auch hier bräuchte es Kooperation und Funding. PDF ist ein Riesenproblem für Barrierefreiheit. Daher wird es bei den meisten Tests nicht geprüft.” Fürs Testen der PDFs bietet sich laut dem CTO das Analysetool PAC [16] an. “Das wird immer wieder fürs BITV-Testing empfohlen und eingesetzt, deshalb schauen wir uns das auch gerade an”.

Die unsichtbare Welt

Außerhalb des Radars uneingeschränkt sehfähiger Personen befinden sich zahlreiche unsichtbare Elemente (Kasten “Versteckte Informationen”). Screenreader erkennen sie, obwohl sie nicht anzeigt werden. Ein typisches Beispiel dafür sind Ankündigungen für den Screenreader, beispielsweise die Anzahl der Suchergebnisse. “Es gibt da eine ‘unsichtbare Welt’, die man verstehen, einbauen und separat testen muss: Kann ich mich so durchklicken? Funktioniert das mit dem Screenreader? Stimmt die Reihenfolge beim Durchtabben? Und stimmt sie auch, wenn man mit der Maus unterwegs ist?” Solche Aspekte führten dazu, dass die Umsetzung von Barrierefreiheit so aufwendig ist, so Heigl.

Versteckte Informationen

»VisuallyHidden_SearchAnnouncement«: Der Benutzer hat im Suchfeld “Kun” eingetippt. Das HTML-Element (Abbildung 2) für den Screenreader, das die Anzahl der gefundenen Ergebnissen ankündigt, ein blaues Element im HTML-Code, ist im UI nicht zu sehen, aber notwendig, um Ankündigungen bei der Verwendung von Screenreadern machen zu können. Der Inhalt passt sich entsprechend der gefundenen Ergebnissen an.

Abbildung 2: Im UI versteckt, weil “offensichtlich”, muss der Screenreader doch erfahren, wie viele Suchergebnisse er weiterzugeben hat. Das geschieht über versteckte Elemente im HTML/CSS-Code.

»VisuallyHiddenStyles«: Die Position des nicht zu sehenden Ankündigungselements (Abbildung 3) rechts neben dem ausgewählten HTML-Element mit der Klasse bleibt für Screenreader wahrnehmbar, aber im UI unsichtbar.

Abbildung 3: Über »class=visually-hidden« definieren die Entwickler Informationen, die zwar für Barrierefreiheit wichtig sind, aber auf der Webseite versteckt bleiben.

»UIVisibleOnHoverButAlsoWithTab«: Ein UI-Element, ist ausschließlich zu sehen, wenn sich der Mauszeiger darüber bewegt, um das UI nicht zu überladen und die Lesbarkeit der wirklich relevanten Informationen zu verbessern. Für die Tab-Navigation muss das allerdings dann sichtbar gemacht werden.

Der liebe Downstream

Probleme, mit denen nur Open-Source-Anwendungen kämpfen, können mit dem Downstream, also der Vernetzung mit der Community zusammenhängen. Im Wiki-Umfeld ist das beispielsweise die vermeintlich simple Auszeichnung für fetten Text: »Bold« oder »Strong« macht da einen erheblichen Unterschied.

Die Auszeichnung im MediaWiki Visual Editor für Fettungen ist »Bold« und hart in MediaWiki einprogrammiert. Screenreader fordern jedoch eine Auszeichnung mit »Strong«. In einem solchen Fall muss eine Firma wie die Hallo Welt! permanent nacharbeiten – oder den langen Weg gehen und versuchen, die Entwickler zu überzeugen. Deren Prioritäten richten sich in der Regel nicht nach lokalen, nationalen oder staatlichen Regulierungen.

Vergrößerung

Hinsichtlich Formatierung und Darstellung lauern noch mehr Fallstricke: 200 Prozent Vergrößerung und mehr lassen sich nicht leicht umsetzen. Obgleich sie notwendig sind, verursacht das in der Praxis das große Probleme. “Keine Ahnung, ob das auch getestet wird, aber wir haben bis jetzt keine Webseite gefunden, die das beherrscht,” berichtet Heigl.

Farbe, Kontrast und Alt-Texte dagegen sind zwar ein großes Thema, doch dessen Scope liegt häufig außerhalb der Softwareentwicklung. Die Hersteller können technische Vorgaben machen, am Ende ist bei WebApps aber der Redakteur verantwortlich. “Da muss man zwischen Content und Interface unterscheiden: Die inhaltliche Optimierung muss durch Redakteure geschehen. Wir müssen uns fragen, wie man sie unterstützen kann, weil es etwa bei Tabellen einen vorlesbaren Tabellenkopf, bei Bildern zwingende Eingabemasken für die Alt-Texte braucht,” sagt Heigl.

Tests

Am Ende aller Arbeiten steht das Testen. Weil das aufwendig ausfällt und viel Expertise erfordert, hat sich die Hallo Welt! dafür eine externe, auf Barrierefreiheit spezialisierte Agentur gesucht – auch die sind rar, daher teuer und der Aufwand explodiert schnell. Ministerien schicken mitunter lange Tabellen mit 60 Testkriterien oder mehr.

Für die Tests gibt es spezialisierte Testwerkzeuge, beispielsweise die Axe-DevTools [17] fürs Web Accessibility Testing. Wer da die Lizenz kauft, bekommt Tests auf Syntax, Farbkontraste (Abbildung 4) und korrektes Labelling. “Das ist bei größeren Projekten wie BlueSpice absolut notwendig, an automatisierten Tests führt da kein Weg mehr vorbei.”

Abbildung 4: Der Axe-Test hat einen Fehler in Sachen Barrierefreiheit gefunden und meldet ihn. Hier hat ein Menüelement nicht ausreichenden Farbkontrast, was Sehbehinderten sehr wahrscheinlich Schwierigkeiten bereiten wird.

Die Axe Dev Tools melden, wo ein Fehler aufgetreten ist, was die Ursache ist und machen Lösungsvorschläge – für Entwickler eine große Zeitersparnis. Allerdings genügen sie allein nicht, weil sie nur die Syntax unter die Lupe nehmen. Tests mit dem Screenreader bleiben unerlässlich, und zwar mit allen möglichen Browsern und den dafür notwendigen Erweiterungen.

Kommunikation

Abgesehen von sämtlichen technischen Herausforderungen spielt die menschliche Komponente die wichtigste Rolle. Vor allem in diesem Punkt können Unternehmen und Open-Source-Entwickler viel lernen: “Ein gemeinsames Verständnis für das Thema zu erarbeiten, nicht nur in der Firma, auch bei beteiligten Projekten und ganz wichtig: beim Kunden ist da essenziell,” erklärt Heigl. “Ohne das wird es schwierig und teuer.”

Wie immer bei Open Source funktioniert die Kommunikation als Schlüssel, und die Entwickler in der Community bauen in der Regel nur Funktionen. WCAG und andere Standards berücksichtigen sie selten, außerdem “ticken” sie eher international. Einem hochmotivierten Developer aus Südostasien ist das deutsche Barrierefreiheitsstärkungsgesetz oder die dazugehörige EU-Norm sicher nicht geläufig.

Open Source als Lösung

Andererseits bietet Open Source genau die Möglichkeit, die zahlreiche Unternehmen brauchen: Weil es für einzelne nicht unbedingt rentabel sein kann, lässt sich die Arbeit auf viele Schultern verteilen. Nicht jeder muss das Rad neu erfinden. Da wären dann ZenDIS, openCode oder der Sovereign Tech Fund gefragt. Und weil die angesprochenen Aufgaben rund um Themen der Barrierefreiheit nicht auf freie Software beschränkt sind, leiden auch proprietäre Hersteller unter denselben Problemen, haben aber bei einer komplett eigenen Codebase nicht immer die gleichen Möglichkeiten wie Open-Source-Firmen. Wenn Kommunikation, Kooperation und Kollaboration die Schlüssel sind, besitzt Open Source hier sicher noch ein großes Potenzial. (csi)