Skip to main content

In fünf Schritten zur barrierefreien Software

Barrierefreiheit ist unverzichtbar - auch in der digitalen Welt. Sie ermöglicht es Menschen mit unterschiedlichen Behinderungen und temporären Einschränkungen, Technologien problemlos und in einer Vielzahl von verschiedenen Situationen einsetzen zu können. Open Source-Software spielt eine zentrale Rolle in unserer digitalen Gesellschaft, und als ihre Entwickler*innen haben wir die Verantwortung, diese für alle zugänglich zu gestalten. Ein Einstieg in die Thematik wird oftmals als kompliziert und aufwendig wahrgenommen. Dieser Artikel soll die Basics der digitalen Barrierefreiheit erklären und zeigen, dass schon einfache Anpassungen innerhalb von wenigen Stunden einen nennenswerten Fortschritt bedeuten können. Ein grobes Verständnis der Thematik ist für alle Entwickler*innen wichtig, um die Bedürfnisse von Menschen mit Behinderungen zu verstehen und zu berücksichtigen.Bei der digitalen Barrierefreiheit geht es hauptsächlich darum, wie Menschen mit Software interagieren. Dabei ist es egal, ob das über eine grafische Oberfläche, eine Website oder ein Command Line Interface (CLI) geschieht. Die Interaktion dort kann über verschiedene Eingabegeräte wie Tastatur, Maus, Touchscreen oder sogar per Sprache passieren. Die Ausgabe kann über einen Bildschirm, ein taktiles Braille-Display oder per Sprachausgabe mit einem Screenreader erfolgen. Eine Software muss so gestaltet sein, dass sie mit all diesen Eingabegeräten und Ausgabemedien funktioniert und gleichzeitig möglichst einfach zu verwenden ist. Dabei sind alle diese Geräte und Oberflächen nicht per se mehr oder weniger barrierefrei. Es kommt dabei immer und vor allem auf die Software und auch deren Nutzer*innen an.

Schritt 1: Verstehen, was Barrierefreiheit bedeutet

Barrierefreiheit in der Softwareentwicklung bedeutet, dass alle Menschen, unabhängig von ihren physischen, sensorischen oder kognitiven Fähigkeiten, Anwendungen problemlos nutzen können. Das ist eine sehr allgemeine Definition, die sich auf alle Arten von Software anwenden lässt. Verschiedene Menschen bevorzugen unterschiedliche Ein- und Ausgabegeräte oder sind wegen einer Behinderung sogar auf diese angewiesen. Dabei sind einige Methoden deutlich weniger flexibel als andere.

Ein Beispiel: Auf einem Bildschirm können viele Informationen gleichzeitig dargestellt und somit überflogen werden, während per Sprachausgabe immer nur ein Element nach dem anderen ausgegeben werden kann. Per Touchscreen können die meisten Menschen sehr schnell und präzise auf einen Button klicken, aber per Tastatur müssen sie erst den Fokus durch die gesamte Oberfläche navigieren, bis sie ihn schließlich erreichen. Über ein CLI können erfahrene Nutzer*innen sehr schnell und effizient arbeiten, aber für weniger Versierte ist es oft sehr schwierig, sich die verfügbaren Kommandos und Abstraktionen zu merken - sie würden in nahezu allen Fällen eine GUI bevorzugen.

Übung: Prüfe, welche Interfaces für deine Software zur Verfügung stehen und wer genau dessen Zielgruppe ist.

Schritt 2: Verstehen, wie Hilfsmittel funktionieren

Die meisten Menschen bevorzugen einen weniger abstrakten Umgang mit Software: Angezeigt zu bekommen, welche Möglichkeiten sie haben und bei der Nutzung geführt und angeleitet zu werden. So müssen sie sich keine Shortcuts, Kommandos oder Abstraktionen merken, sondern können sich auf die eigentliche Aufgabe konzentrieren. Das ist auch - und gerade für - Menschen mit Behinderungen ein wichtiges Kriterium bei Software.

Viele von ihnen nutzen sehr spezifische Hilfsmittel mit ihrer eigenen, persönlichen Konfiguration. Eine Software darauf zu optimieren, ist sehr anspruchsvoll. Deshalb lohnt es sich, einen Blick darauf zu werfen, wie diese funktionieren. Nutzer*innen von Sprachausgabe navigieren beispielsweise mit der Tastatur oder verschiedenen Finger-Gesten zwischen den Elementen in einer Oberfläche, die sie dann jeweils vorgelesen bekommen. Dabei können sie ein User Interface anhand bestimmter Merkmale schneller erfassen und erkunden. Diese Merkmale könnten alles sein - Hauptsache ist, sie sind eindeutig und konsistent: Überschriften, Links, Buttons, Textfelder, Bilder, Tabellen, Formulare etc. Die Navigation per Überschriften erlaubt beispielsweise, sich schnell einen Überblick über den Inhalt eines langen Textes zu verschaffen, den andere Menschen einfach überfliegen könnten. Die Navigation per Buttons erlaubt es, schneller eine bestimmte Funktionalität der Software aufrufen zu können, die andere Menschen einfach nur mühelos auf dem Display antippen müssten. Gäbe es für eine Funktionalität eine Tastenkombination, wäre das für erfahrene Nutzer*innen eine weitere sehr schnelle Möglichkeit, diese aufzurufen. Diese könnte dann beispielsweise auch mit einem individuellen Makro ausgelöst werden, was den Einsatz der Software in vielen Bereichen deutlich flexibler machen könnte - auch für Menschen ohne Behinderung.

Nicht nur Menschen mit Sehbehinderung nutzen diese Art der Navigation sondern auch viele Menschen mit motorischen Behinderungen. Sie können beispielsweise nur sehr schwer oder gar nicht mit der Maus oder Touchscreens arbeiten und sind auf die Tastatur angewiesen. Aber auch diese könnte eine zu große Präzision erfordern, weshalb einige Menschen speziellere Eingabegeräte verwenden, die auf ihre eigene Behinderung angepasst wurden. Um nur mal ein paar der Möglichkeiten zu nennen: Eye Tracking, Head Tracking, Sprach-Erkennung, Joysticks, wenige große physische Tasten, die Controller von Spielkonsolen oder ein Saug-Blase-Schalter.

Viele haben gemeinsam, dass sie noch unflexibler sind als eine Tastatur und nur eine begrenzte Anzahl an verschiedenen Inputs erlauben. Ähnlich wie Nutzer*innen von Sprachausgabe-Software sind die Nutzer*innen dieser Hilfsmittel auf eine klare und eindeutige Struktur angewiesen, um sich in einer Software zurechtzufinden, da auch sie hauptsächlich linear und Element für Element einzeln navigieren müssen, um ein Interface zu bedienen. Aber: Wenn die Bedienung einer Software mit einer Tastatur möglich ist, dann stehen die Chancen gut, dass sie auch mit diesen Hilfsmitteln funktionieren kann. Diese Annahme ersetzt natürlich aber nicht die langfristige Notwendigkeit, die Software auch mit diesen Hilfsmitteln von echten Nutzer*innen testen zu lassen.

Es gibt aber auch noch andere assistive Technologien wie Screen Magnifier, die den Bildschirminhalt vergrößern, Kontrast-Anpassungen vornehmen oder Farben dynamisch umwandeln können. Diese sind für Menschen mit Sehbehinderung sehr hilfreich, aber auch für Menschen mit kognitiven Behinderungen, die sich beispielsweise besser auf eine Aufgabe konzentrieren können, wenn sie nur einen kleinen Ausschnitt des Bildschirms sehen. Auch hier ist es wichtig, dass die Software so gestaltet ist, dass sie mit diesen Technologien funktioniert.

Übung: Prüfe, ob die Bedienung deiner Software per Tastatur problemlos möglich ist und ob interaktive Elemente in einer sinnvollen Reihenfolge angeordnet sind. Falls nicht, kannst du hier erste Anpassungen vornehmen.

Schritt 3: Verstehen, was die Prinzipien der Barrierefreiheit sind

Auch die Prinzipien der Barrierefreiheit sind sehr allgemein gehalten und lassen sich auf alle Arten von Software anwenden. Sie sind sehr wichtig, um die Bedürfnisse von Menschen mit Behinderungen zu verstehen und zu berücksichtigen.

  • Wahrnehmbarkeit: Alle Informationen und Bedienelemente müssen für alle Menschen wahrnehmbar sein. Das bedeutet, dass sie nicht nur sichtbar sondern auch hörbar oder fühlbar sein müssen. Dabei soll man auch sofort erkennen können, was die Funktion eines Elements ist und wie es verwendet werden kann. Zum Beispiel muss eine Checkbox auch aussehen wie eine Checkbox und nicht wie ein Button. Für einige Medien wie Bilder, Videos oder Audio-Dateien benötigen wir zudem eine Text-Alternative.

  • Bedienbarkeit: Alle Bedienelemente sollen per Tastatur und assistiven Technologien erreichbar sein und intuitiv nach bekannten Regeln funktionieren. Zum Beispiel muss es möglich sein, in Drop-Down Menüs per Texteingabe oder Pfeiltasten zu navigieren. Wir müssen auch beachten, dass einige Menschen mehr Zeit benötigen und dass ihre Reaktionszeit unter Umständen deutlich länger ist.

  • Verständlichkeit: Sowohl die Bedienelemente als auch die Informationen müssen verständlich sein. Das bedeutet, dass sie in einer klaren und einfachen Sprache formuliert sein müssen. Zum Beispiel könnte ein Button in einem Speichern-Dialog mit "Speichern" beschriftet sein statt mit "OK". Wenn Nutzer*innen Fehler machen, müssen sie auch verstehen können, was sie falsch gemacht haben und wie sie eventuelle Probleme beheben können.

  • Robustheit: Wir müssen sicherstellen, dass die Software für aktuelle und auch zukünftige Nutzer*innengruppen mit verschiedenen assistiven Technologien funktioniert. Das bedeutet, dass wir uns an die Standards halten sollten, die für die jeweilige Technologie gelten.

In den Web Content Accessibility Guidelines (WCAG) des W3C gibt es für alle diese Prinzipien sehr detaillierte Richtlinien, die auch konkrete Beispiele und Prüfkriterien enthalten. Diese sind sehr hilfreich, um die Bedürfnisse von Menschen mit Behinderungen besser zu verstehen und zu berücksichtigen. Sie lassen sich auch auf andere Arten von Software anwenden, die keine Web-Technologien einsetzen.

Die WCAG sind ein sehr guter Standard, der inzwischen in die Gesetzgebung in vielen Ländern eingeflossen ist. Wer sich längerfristig mit Barrierefreiheit auseinandersetzen möchte, sollte Zeit investieren, damit vertraut zu werden.

Aber nicht nur die WCAG ist ein wichtiger Standard, sondern auch die Dokumentationen und Standards der Betriebssysteme und GUI-Frameworks, die verwendet werden. Diese enthalten hilfreiche Informationen, wie Software barrierefrei gestaltet werden kann und welche technische Unterstützung notwendig ist, um gute Ergebnisse zu erzielen. Für Web-Anwendungen gibt es beispielsweise die WAI-ARIA Spezifikation, die eine Reihe von Rollen, Eigenschaften und Zuständen definiert, die für die Barrierefreiheit von Web-Anwendungen wichtig sind und assistive Technologien mit zusätzlichen Informationen über die Struktur einer Bedienoberfläche versorgt. Ein Tipp: Die meisten Vanilla-Komponenten von HTML5 oder beispielsweise SwiftUI sind bereits technisch barrierefrei und es empfiehlt sich daher immer, diese zu verwenden, statt eigene zu entwickeln.

Übung: Prüfe oberflächlich, ob deine Software den 4 Prinzipien der Barrierefreiheit entspricht. Falls nicht, kannst du mit den WCAG-Richtlinien genauer prüfen, welchen Verbesserungsbedarf es gibt und die entsprechenden Veränderungen vornehmen. Mit der Zeit wirst du ein Gefühl dafür entwickeln und die Prinzipien automatisch berücksichtigen, wenn du Software entwickelst. Der spätere Aufwand für Barrierefreiheit wird dadurch deutlich geringer.

Schritt 4: Implementierung und Test der Barrierefreiheit

Die Implementierung von Barrierefreiheit ist sehr vielfältig und hängt stark von der Art der Software ab. Es ist ratsam, sich mit der Dokumentation der verwendeten Technologien vertraut zu machen und die entsprechenden Richtlinien zur Barrierefreiheit zu befolgen. Dabei gilt es immer im Auge zu behalten, dass es nicht nur um die technische Umsetzung von Standards geht, sondern vor allem darum, wie echte Nutzer*innen die Software am Ende tatsächlich verwenden. Wenn möglich sollte man Menschen mit Behinderung an der Entwicklung beteiligen - so fallen viele Barrieren schon früh auf und können direkt behoben werden, noch bevor die Software einem genauen Test unterzogen wird. Es bietet sich an, mit jedem Code Review kurz zu überprüfen, ob die Prinzipien der Barrierefreiheit eingehalten wurden und falls nicht, entweder eine Nachbesserung oder eine Erklärung einzufordern.

Der Test der Barrierefreiheit sollte immer von dazu speziell dazu ausgebildeten Menschen erfolgen, idealerweise auch wieder von solchen, die aufgrund einer Behinderung im täglichen Leben selbst auf assistive Technologien angewiesen sind. Dazu können beispielsweise auch die Prüfkriterien der WCAG verwendet werden, die sehr gut für die Prüfung von Software außerhalb des Webs geeignet sind. Ebenfalls empfehlenswert ist ein Selbsttest mit Screenreader-Software und Sprachausgabe. Für Windows gibt es den kostenlosen und Open Source-Screenreader NVDA, auf Linux gibt es Orca und auf macOS ist bereits VoiceOver vorinstalliert. Es bietet sich auch ein Test mit den etwas einfacheren, vorinstallierten Screenreadern auf den mobilen Plattformen iOS (VoiceOver) und Android (TalkBack) an. In beiden Fällen sollte man den sogenannten Bildschirmvorhang aktivieren oder den Bildschirm ganz ausschalten, um die Software nur per Sprachausgabe bedienen zu können. Ist die Software auch dann noch gut und einfach nutzbar, ist das ein sehr gutes Zeichen dafür, dass auch andere assistive Technologien ähnlich gut oder sogar noch besser funktionieren werden.

Die Bedienung von Screenreadern verlangt einiges an Übung und es ist am besten, wenn man dabei von einer Person angeleitet wird, die regelmäßig auf diese Software angewiesen ist. Das temporäre Verwenden von Screenreadern zeigt nicht, wie gut die Software für Menschen mit Sehbehinderung nutzbar ist, sondern nur, wie gut sie für Menschen ohne Sehbehinderung, aber dafür mit technischem Hintergrund nutzbar ist, die gerade einen Screenreader verwenden.

Zur weiteren Unterstützung bei der Integration von Barrierefreiheitsprüfungen in den Entwicklungsprozess gibt es auch einige Tools, die automatisierte Tests durchführen können. Diese sind aber ausschließlich Hilfsmittel und können die Prüfung durch echte Nutzer*innen nicht ersetzen. Ebenso könnten sie falsche Ergebnisse liefern, deren "Behebung" dann zu einer Verschlechterung der Barrierefreiheit führen würde. Empfehlenswert sind beispielsweise das WAVE Accessibility Tool von WebAIM oder die Accessibility Insights von Microsoft.

Übung: Mache dich mit Screenreader-Software vertraut und teste deine Software damit. Falls du keine Möglichkeit hast, mit einer Person zu üben, die selbst Screenreader-Software verwendet, kannst du auch die NVDA User Guides oder das Handbuch des von dir verwendeten Screenreaders durcharbeiten. Wenn dir fehlende Element-Beschriftungen oder fehlende Text-Alternativen auffallen, kannst du diese direkt beheben. Falls du Probleme mit der Bedienung der Software feststellst, kannst du diese ebenfalls ausbessern oder zumindest dokumentieren.

Schritt 5: Barrierefreiheit kommunizieren

Neben der technischen Umsetzung der Barrierefreiheit ist es auch wichtig, diese zu kommunizieren. Das kann beispielsweise über eine Dokumentation, eine Website oder eine Release-Note geschehen. Es ist wichtig, dass die Nutzer*innen wissen, dass die Software barrierefrei ist, wo und ob es noch Probleme gibt, und wie sie diese melden können. Barrierefreiheit sollte dabei stets einen prominenten Platz einnehmen und nicht nur als Randnotiz erwähnt werden. Release Notes wie "Verbesserte Barrierefreiheit" sind nicht hilfreich, da sie nicht erklären, was genau verbessert wurde und wie sich das auf die Nutzer*innen auswirkt. Oftmals sind Menschen mit Behinderung von neuer Software eher abgeschreckt, da sie befürchten, dass diese nicht barrierefrei sein könnte. Es ist daher wichtig, dass sie wissen, dass die Software barrierefrei ist und dass sie sich darauf verlassen können, dass sie auch in Zukunft barrierefrei bleiben wird.

In der Kommunikation um dieses Thema gilt es außerdem, immer absolut ehrlich zu sein und typische Marketing-Relativierungen zu vermeiden. Behinderte Nutzer*innen sind sehr gut darin, diese zu durchschauen und werden sich dadurch eher abgeschreckt fühlen. Es ist hier besser, Probleme offen und detailliert zu kommunizieren, da dies selbst eine Verringerung der Barrieren darstellen kann. So sind die Nutzenden dazu in der Lage, selbst zu entscheiden, ob sie die Software aktuell verwenden können oder nicht.

Auch in der Kommunikation müssen die Prinzipien der Barrierefreiheit beachtet werden. Das bedeutet konkret: Informationen klar und einfach formuliert sein. Ebenso müssen sie leicht auffindbar sein und dürfen nicht versteckt werden. Sie müssen selbst barrierefrei sein, damit sie auch von Behinderten gelesen werden können und sie müssen sich immer auch auf den aktuellen Stand der Software beziehen.

Sind diese Voraussetzungen erfüllt, werden auch Personen, die assistive Technologien einsetzen, früher oder später auf die Software aufmerksam und werden sie ausprobieren. Das ist eine sehr gute Gelegenheit, um qualitatives Feedback zu erhalten und die Software weiter zu verbessern - für alle Nutzer*innen.

Übung: Erstelle eine "Erklärung zur Barrierefreiheit" für dein Projekt und erkläre darin, wie du die Barrierefreiheit sicherstellst, welche Barrieren es derzeit gibt und bis wann diese behoben werden sollen.

Fazit

Digitale Barrierefreiheit ist nicht nur ein Konzept oder eine Anforderung - sie ist ein Wegbereiter für Gleichberechtigung und gesellschaftliche Teilhabe. Durch die Schaffung barrierefreier Software ermöglichen wir Menschen mit Behinderungen, ein großes Maß an Selbstbestimmung zu erlangen und aktiv an unserer Gesellschaft teilzunehmen. Sie können so kommunizieren, Informationen suchen, Dienstleistungen nutzen, sich weiterbilden und ihrer Arbeit nachgehen - all das mit der gleichen Leichtigkeit und Bequemlichkeit wie alle anderen auch.

Es stimmt: Die Umsetzung von Barrierefreiheit in der Softwareentwicklung kann eine große, zusätzliche Herausforderung darstellen. Es gibt nicht die eine Checkliste, sondern es erfordert ein Verständnis für die Bedürfnisse verschiedener Benutzer*innengruppen, ein Umdenken in Design- und Entwicklungsprozessen und den Einsatz zusätzlicher Tools und Tests. Aber die zusätzliche Arbeit, die in die Schaffung barrierefreier Software investiert wird, zahlt sich auf vielfältige Weisen aus.

Erstens verbessert es die Erfahrung für alle, nicht nur für Menschen mit Behinderungen. Features, die zur Barrierefreiheit beitragen, wie zum Beispiel ein guter Kontrast, klare Navigation und einfache Sprache, sind eine Hilfe für alle.

Zweitens erweitert es den potenziellen Nutzer*innen-Kreis ihrer Software erheblich. Es gibt Milliarden von Menschen mit unterschiedlichen Arten von Behinderungen auf der Welt, und barrierefreie Software ist ein entscheidender Faktor, um diese Menschen zu erreichen und zu bedienen.

Drittens fördert es Innovation und Qualität. Wenn man sich darauf konzentriert, Software für alle zugänglich zu machen, wird man oft kreativere Lösungen finden und ein höheres Qualitätsniveau erreichen. Gerade Open Source-Software scheitert aktuell häufig daran, für die meisten Menschen außerhalb der Tech-Community attraktiv zu sein. Barrierefreiheit und User Experience können hier einen großen Unterschied machen.

Es gibt einige Schulungs-Angebote, unter anderem von Menschen mit Behinderung, die sich auf die digitale Barrierefreiheit spezialisiert haben. Diese sind sehr empfehlenswert, um weitere Verbesserungen der Barrierefreiheit zu erreichen und die eigene Software besser zu verstehen.

Also, liebe Entwickler*innen, lasst uns den Weg der digitalen Barrierefreiheit beschreiten. Es mag ein bisschen mehr Arbeit sein, aber es ist eine Arbeit, die sich lohnt. Es ist eine Arbeit, die den Unterschied macht - denn sie macht unsere Software, unsere Gemeinschaften und unsere Gesellschaft besser und inklusiver. Zusammen können wir eine digital zugängliche Welt schaffen, in der alle Menschen gleichermaßen teilhaben können. Und das ist ein Ziel, das jede Anstrengung wert ist.

Eine Übersicht der genannten Tool

Zusatz: Eine schnelle Barrierefreiheitsüberprüfung für Websites bietet auch das Tool https://www.experte.de/barrierefreiheit.

Zur Autorin

Casey Kreer ist Beraterin für digitale Barrierefreiheit und Software-Entwicklerin. Sie ist seit ihrer Geburt sehbehindert und nutzt assistive Technologien, um mit dem Computer zu arbeiten. Sie arbeitet als Freiberuflerin für verschiedene Kund*innen und Projekte, die gute und inklusive Medien-Angebote schaffen möchten. Dafür vermittelt sie in Workshops und Schulungen das notwendige Wissen oder schreibt Gutachten über Barrieren in bestehender Software. (conesible.de)

Back to top