Die Bemühungen von Rocket Software um Barrierefreiheit

Unsere Mission bei Rocket Software geht weit über die Entwicklung innovativer Lösungen hinaus. Jeder Aspekt unserer Arbeit wird von unseren zentralen Werten geleitet: Empathie, Menschlichkeit, Vertrauen und Liebe. Innerhalb dieser Werte legt Rocket Software großen Wert auf Barrierefreiheit. Unabhängig von Technologie, System oder IT-Umgebung entwickeln wir Lösungen, die für alle funktionieren.

Um etwas mehr darüber zu erfahren, wie wir unsere Lösungen aus der Perspektive der Barrierefreiheit angehen, haben wir uns mit Brian Kunz, dem leitenden Softwarearchitekten von Rocket Software, zusammengesetzt.

Brian verfügt über mehr als 20 Jahre Erfahrung in der Entwicklung und Gestaltung von Frontend-Anwendungen. Seit 2024 engagiert er sich intensiv für Barrierefreiheit und leitet die Entwicklung grundlegender Barrierefreiheitskomponenten für die neue Benutzeroberfläche von Rocket Content Services, den Rocket Content Explorer.

Wie würden Sie Barrierefreiheit aus der Perspektive von Softwareentwicklung definieren?

Aus Software-Sicht geht es darum, die Tastatur mit der Anwendung kompatibel zu machen. Die Tastaturschnittstelle ist die Grundlage für alle Hilfstechnologien wie Bildschirmleseprogramme. Jede Interaktion auf dem Bildschirm muss über eine Reihe von Tastaturbefehlen möglich sein; diese Befehle sind den Nutzern bekannt und geläufig. Als Nutzer sollte ich alle Funktionen einer Anwendung bedienen können, ohne die Maus zu verwenden.

Wir konzentrieren uns so sehr auf die Entwicklung von mausgesteuerten Anwendungen – diese Denkweise muss sich ändern.

Aus Entwicklersicht ist Barrierefreiheit eine Kompetenz, die den meisten Entwicklern fehlt. Das galt auch für mich und für jeden Entwickler, der an unserem neuen UI-Projekt mitgearbeitet hat.

Agile Methoden sind wahrscheinlich ein Hauptgrund dafür, dass Barrierefreiheit nicht stärker im Fokus steht. Entwickler haben sich traditionell auf das Aussehen der Anwendung und die Mausbedienung konzentriert; das galt als Kriterium für die Fertigstellung einer Funktion. Sobald diese Funktion abgeschlossen ist, geht es mit der nächsten weiter, denn das Ziel ist, so viele Funktionen wie möglich hinzuzufügen.

So wird Barrierefreiheit aus Zeitgründen zugunsten der schnellen Implementierung einer Funktion vernachlässigt. Es liegt nicht daran, dass Entwickler keine barrierefreien Anwendungen erstellen wollen – aber wir haben die Bedeutung der barrierefreien Programmierung unterschätzt, weil sie zusätzlichen Zeitaufwand erfordert. Auch der Fokus des Managements spielt eine Rolle, da die barrierefreie Programmierung von allen Beteiligten etwas mehr Zeit und Mühe verlangt.

Barrierefreiheit ist oft eine Nebensache, über die kaum gesprochen oder die nicht gefördert wird – das möchten wir ändern. Wir wollen, dass Barrierefreiheit ein selbstverständlicher Bestandteil jedes Projekts wird.

Können Sie in einfachen Worten die vier Prinzipien der Web Content Accessibility Guidelines (WCAG) erläutern und erklären, warum sie wichtig sind?

Dafür gibt es ein Akronym: POUR. Es steht für Wahrnehmbar, Bedienbar, Verständlich und Robust.

Beginnen wir mit der Wahrnehmbarkeit. So entwickelt man eine komplexe Anwendung, die sowohl visuell ansprechend als auch ästhetisch ansprechend gestaltet ist und deren Zusammenhänge zwischen den visuellen Elementen auf dem Bildschirm auch für Menschen ohne Sehvermögen verständlich sind. Wie erkennt ein Benutzer beispielsweise, dass ein Button beim Drücken ein neues Informationsfeld öffnet? Oder wie wird dem Benutzer eine – selbst subtile – Änderung des Bildschirms auf anderem Wege als visuell vermittelt? Wahrnehmbarkeit bedeutet, dem Benutzer ein Bild davon zu vermitteln, wo er sich in der Anwendung befindet und wie diese strukturiert ist.

Wenn wir von Bedienbarkeit sprechen, meinen wir, dass jedes manipulierbare Element über die Tastatur zugänglich sein muss. Wir berücksichtigen dabei, dass assistive Technologien auch Optionen wie Spracherkennung für Nutzer mit motorischen Einschränkungen umfassen, da die Tastatur für diese Nutzer möglicherweise nicht verfügbar ist. Bedienbarkeit bedeutet, dass alles, was manipuliert werden kann – wie beispielsweise Schaltflächen, Listenfelder, Texteingabefelder usw. –, per Tastatur oder Sprachbefehl bedienbar sein muss. Dies stellt besondere Herausforderungen für Aktionen dar, die traditionell mit der Maus ausgeführt werden, wie etwa Ziehen und Skalieren. Bei der Entwicklung barrierefreier Software müssen wir die Maus nicht als primäres Änderungsmittel, sondern lediglich als ein weiteres Werkzeug betrachten. Wir wollen Funktionen wie Klicken und Ziehen nicht ausschließen, nur weil ein Nutzer keine Maus verwenden kann.

Als Nächstes ist Verständlichkeit wichtig. Verständlichkeit bedeutet, dass jedes Widget wie erwartet funktioniert. Assistive Technologien identifizieren Elemente auf dem Bildschirm und zeigen beim Navigieren Meldungen wie „Schaltfläche“ oder „Tabelle“ an. Diese grundlegende Beschreibung erklärt dem Nutzer, wie er das jeweilige Element bedienen und gängige Tastenkombinationen der assistiven Technologie nutzen kann. Weiß der Nutzer beispielsweise, dass ein Kombinationsfeld im Fokus ist, kann er es mit der Eingabetaste oder der Pfeiltaste nach unten aktivieren. Als Entwickler müssen wir sicherstellen, dass die Aktionen und deren Reihenfolge für ein bestimmtes Element der erwarteten Benutzererfahrung mit assistiven Technologien entsprechen. Andernfalls entsteht ein verwirrendes Szenario und die Technologie ist nicht effektiv nutzbar.

Schließlich kommen wir zum Thema Robustheit. Es gibt Codierungskonventionen und Attribute, die Entwickler verwenden sollten, um sicherzustellen, dass unsere Software mit allen assistiven Technologien kompatibel ist. Die WCAG-Standards bilden die Grundlage, nach der wir als Entwickler programmieren und die auch von den Entwicklern der assistiven Technologien verwendet wird. Solange beide Entwicklergruppen ihren Beitrag leisten, erhalten unsere Endnutzer eine funktionale und barrierefreie Benutzererfahrung. Wir programmieren nach einem Standard, nicht für eine bestimmte assistive Technologie.

Robustheit bedeutet, Software so zu entwickeln, dass sie mit verschiedenen Benutzeragenten und Hilfstechnologien kompatibel ist. Ein weiterer Aspekt von Robustheit ist die intuitive Navigation innerhalb der Anwendung mit wenigen Tastatureingaben. Bei korrekter Entwicklung ermöglicht die Anwendung dem Benutzer, mit der Tastatur schnell zu den gewünschten Bereichen auf dem Bildschirm zu navigieren, ohne jedes einzelne Steuerelement oder Element mit der Tabulatortaste ansteuern zu müssen.

Wie kann man für farbenblinde Personen sicherstellen, dass die Richtlinien für Farbkontraste im Design einer Website oder Anwendung eingehalten werden, und welche Arten von Hilfsmitteln können dabei hilfreich sein?

Die WCAG empfiehlt ein Farbverhältnis von 4,5 zu 1 für Vorder- und Hintergrundfarben. Es ist etwas schwierig, genau zu beschreiben, was das bedeutet, aber es bezieht sich auf Farbabstufungen zwischen Vorder- und Hintergrund in der Anwendung.

Wie stellen wir das also fest? Es beginnt ganz am Anfang des Designprozesses. Wir haben Figma verwendet, um detaillierte Wireframe-Entwürfe für die Anwendung zu erstellen. Dieses Tool hilft uns sicherzustellen, dass das Design selbst das Farbkontrastverhältnis einhält. Wir wollen vermeiden, etwas zu entwerfen, das uns zwar gefällt, und Zeit und Ressourcen dafür zu investieren, nur um dann festzustellen, dass es die Farbkontrastprüfung nicht besteht.

Es gibt außerdem ein Browser-Tool namens Accessibility Insights. Dieses Browser-Plugin lässt sich für jede Seite aktivieren und zeigt an, ob das zuvor erwähnte Seitenverhältnis verletzt wurde. Das Tool kann die Anwendung auch in Graustufen darstellen. So lässt sich die Entwicklung optimal betrachten, ohne die Farbe zu berücksichtigen, und man sieht, wie die Graustufenkontraste wirken und wie gut sich Elemente unterscheiden lassen.

Welche Strategien haben Sie eingesetzt, um Entwicklungs- und Designteams über bewährte Verfahren zur Barrierefreiheit aufzuklären und diese zu fördern?

Wenn man sich die WCAG-Spezifikation ansieht, mag sie einen zunächst abschrecken. Sie ist umfangreich, sehr technisch und wirkt auf den ersten Blick schwer verständlich. Doch sobald man den ersten Schreck überwunden hat, ist sie ganz einfach, sobald man die Zusammenhänge verstanden hat. Genau so ging es mir auch. Ich wusste, dass ich diesen Schritt gehen musste, und es war die richtige Entscheidung.

Ich habe festgestellt, dass ich, sobald ich das verstanden habe, eine neue Begeisterung für Barrierefreiheit entwickelt habe. Programmieren auf diese Weise macht unsere Anwendungen so viel robuster, und es ist gar nicht so kompliziert … und man fragt sich, warum man diese Programmierstrategien bisher vermieden hat.

Mein Ziel ist es, barrierefreies Programmieren für Frontend-Entwickler zur Selbstverständlichkeit zu machen, sodass es nicht als zusätzliche Aufgabe, schwierig oder nicht lohnenswert angesehen wird. Ich habe unser Entwicklungsteam unterstützt, indem ich grundlegende Schemata für die visuellen Designs bereitgestellt habe, die die Berücksichtigung von Barrierefreiheit verdeutlichen. Als Experte im Team konnte ich sagen: „Wenn ihr diesen Bildschirm erstellt, achtet bitte auf diese Aspekte und weitere Punkte im Hinblick auf Barrierefreiheit.“ Die Entwickler haben diese Vorgehensweisen beim Programmieren angewendet, und wir haben den Code anschließend im Rahmen unseres üblichen Code-Review-Prozesses evaluiert. Da dies für alle neu war, waren immer wieder kleinere Nachbesserungen nötig; wir alle haben neue Fähigkeiten entwickelt und jeder hat dazugelernt. Wir haben den Code also so lange getestet und optimiert, bis wir das gewünschte Ergebnis erzielt hatten.

Aus dieser Erfahrung heraus habe ich eine Reihe von aufeinander aufbauenden Schulungsvideos erstellt, die allen Rocketeers zur Verfügung stehen, die Barrierefreiheit in ihre Projekte integrieren möchten. Ich habe fast fünf Stunden Videomaterial produziert – die Bearbeitung wird also nicht viel Zeit in Anspruch nehmen. Die Videos bieten eine Einführung in die grundlegenden Konzepte und zeigen anhand einer kleinen Beispielanwendung deren praktische Anwendung.

Mein Ziel ist es, die Angst vor der Einführung der WCAG-Standards abzubauen, indem ich zeige, wie einfach es ist. Unsere Teams haben außerdem eine Bibliothek mit UI-Widgets entwickelt, die bereits die meisten Aspekte der Barrierefreiheit abdecken. Dadurch können andere Teams zukünftig bessere Produkte entwickeln, indem sie diese Widgets nutzen. Sie müssen sich innerhalb dieser Widgets keine Gedanken mehr um die Barrierefreiheit machen, da diese bereits integriert ist.

Haben Sie Tipps oder Tricks, die Sie Entwicklern oder Teams mitgeben würden, die sich gerade erst mit dem Thema Barrierefreiheit auseinandersetzen?

Mein Tipp: Nutzen Sie HTML5 so, wie es gedacht ist. Dadurch erhalten Sie automatisch viele Vorteile für die Barrierefreiheit. Achten Sie beim Programmieren für ein visuelles Design auf die grundlegenden Elemente.

Wenn etwas eine Inhaltsliste darstellt, verwenden Sie die entsprechenden Listenelemente in HTML5. Wenn etwas sich wie ein Button verhält, machen Sie es zu einem Button. Wenn Sie tabellarische Daten darstellen, verwenden Sie die Tabellenelemente, da assistive Technologien ihren Nutzern semantische Informationen bereitstellen, wenn Sie diese Basiselemente verwenden. Als Entwickler neigen wir dazu, generische Container zu verwenden, die so gestaltet sind, dass sie wie etwas Bestimmtes aussehen, und ihnen dann manuell Klick-Handler hinzuzufügen. Das ist der einfachste Weg und erzeugt etwas, das gut aussieht und mit der Maus anklickbar ist, aber es hat keine Bedeutung für Menschen, die assistive Technologien verwenden. Die Verwendung der Basiselemente von HTML5 liefert Ihnen mindestens die Hälfte dessen, was Sie benötigen.

Was die technischen Ressourcen angeht, gibt es eine Seite mit Mustern. Diese Ressource hat mir wirklich den Durchbruch gebracht. Auf dieser Seite findet man Spezifikationen für jeden erdenklichen Widget-Typ; sie enthält Beispiele, Codebeispiele, Tastaturbelegungen für verschiedene Elemente usw. Man kann sogar eine Hilfstechnologie wie JAWS verwenden, um die Beispiel-Widgets zu testen und zu sehen, wie JAWS damit umgeht. Das war eine großartige Möglichkeit für mich zu verstehen, als ich anfing, mich mit barrierefreiem Programmieren zu beschäftigen; ich musste beim Programmieren nur ein paar Kleinigkeiten anpassen.

Was war das Interessanteste, das Sie bei der Arbeit an einem Projekt mit Schwerpunkt Barrierefreiheit gelernt haben?

Die einfache Antwort ist, dass ich den Kernwert von Rocket Software – Empathie – in unserer Arbeit erkenne. Wir möchten, dass unsere Software für alle nutzbar ist. Wie bereits erwähnt, konzentrieren wir uns in unserer agilen Entwicklungsumgebung auf den schnellsten Weg zur Fertigstellung einer Funktion. Dies führt dazu, dass wir Anwendungen entwickeln, die bestimmte Nutzergruppen ausschließen. Das geschieht nicht absichtlich und ohne böse Absicht, aber wir übersehen leicht Menschen mit Behinderungen und berücksichtigen ihre Erfahrungen und die Schwierigkeiten, die ihnen bei der Nutzung unserer Software begegnen könnten, nicht ausreichend.

Wir müssen unsere Denkweise bei allem, was wir mit dem Namen Rocket Software veröffentlichen, ändern. Es geht darum, die unterschiedlichen Bedürfnisse unserer Nutzer zu berücksichtigen und keine ausgrenzenden Tools zu entwickeln, selbst wenn das bedeutet, dass die Entwicklung und das Testen etwas länger dauern. Deshalb möchte ich, dass barrierefreie Programmierstrategien für unsere Entwickler selbstverständlich werden, sodass sie nicht mehr denken: „Ich mache das aus Gründen der Barrierefreiheit“, sondern es ein grundlegender Bestandteil der Programmierung jedes Projekts ist.

Die Zukunft begeistert mich. Die neuen Funktionen, die wir eingeführt haben, bergen großes Potenzial. Ich prüfe gerade, wie wir etwas wie einsetzen können. ^® Content Smart Chat soll Lücken bei der Interaktion mit Inhalten in einer Anwendung schließen – und zwar nicht nur mit der Anwendung selbst. Wenn wir einem Benutzer beispielsweise ein Bilddokument präsentieren, könnte Rocket^® Der Content Smart Chat liefert dann eine kurze Zusammenfassung des Bildinhalts und informiert den Nutzer beispielsweise mit „Dies ist ein Bild von XYZ“ oder mit einer Dokumentzusammenfassung wie „Dieses Dokument ist ein Zahlungsbeleg für gekaufte Materialien“. Solche Funktionen sparen Zeit. Nutzer müssen nicht mehr das gesamte Dokument lesen, um festzustellen: „Oh, das ist nicht das gesuchte Dokument.“

Stattdessen erhalten sie diese Zusammenfassung schnell und können dann mit ihrer nächsten Aufgabe fortfahren. Ich denke, dass wir mithilfe modernster Technologien noch mehr tun können, um unser barrierefreies Angebot weiter zu verbessern.

Es ist aufregend für mich und ich bin sehr stolz darauf, dass wir intern bei dieser Initiative eine Vorreiterrolle einnehmen. Diese WCAG-konforme Benutzererfahrung ist bahnbrechend.

Erfahren Sie mehr über die neuesten Funktionen von Rocket Content Services .