Mit offenen Augen und offenem Geist

Dr. Andreas Maier

In Deutschland leben ca. 7,8 mio. schwerbehinderte Menschen. Hierbei handelt es sich um eine enorme Zahl potentieller künftiger Kunden. Software, die unter Missachtung ihrer Accessibility entwickelt wurde, schließt diese Menschen als Nutzer aus. Und nicht nur diese - Die barrierefreie Gestaltung von Software-Produkten birgt häufig übersehene Vorteile sowohl für Unternehmen als auch für sämtliche Nutzer.

Schlafende Riesen

In Deutschland sind mindestens 7,8 Mio. Menschen schwerbehindert. Dies entspricht 9,4 % der deutschen Bevölkerung. Davon sind 59,9 % im berufsfähigen Alter zwischen 18 und 65 Jahren. Ein hohes verfügbares Einkommen dieser Menschen bleibt für Software-Produkte ungenutzt. Ein ungemein großes Potential liegt somit brach. Potential, neben der Steigerung der Usability und der positiven User Experience (UX) für alle Nutzer, durch Software-Engineering unter Berücksichtigung derer Accessibility auch neue Märkte zu erschließen.

Accessi- was?

Accessibility bedeutet nicht, Software für „behinderte“ oder „andere“ Nutzer zu entwickeln bzw. anzupassen. Auch lässt sich Accessibility nicht außer Acht lassen, wenn ein Unternehmen Software für die „normalen“ Nutzer entwickelt. „Normal“ ist ein Idealzustand, der in einem Normsystem als Teil der persönlichen Realität wahrgenommen wird. Dieser Normalzustand beachtet aber die Faktenlage nicht.

Accessibility ein Bestandteil des Software-Engineerings? Aber selbstverständlich!

Beeinträchtigungen von Software-Nutzern müssen als normal angenommen werden. Accessibility muss daher als normaler, selbstverständlicher Bestandteil des Software-Engineerings betrachtet werden. Im Rahmen eines User-Centered Designs (UCD), eines Human-Centered Designs (HCD)[1] und eines Experience Designs XD, legt modernes Software-Engineering den Schwerpunkt auf die Bedürfnisse und Bedarfe der Endnutzer. Hierzu ist es insbesondere wichtig, die Aufmerksamkeit auf ein tiefgehendes Verständnis der Endnutzer zu richten. In Bezug auf Nutzerbedarfe bezüglich Accessibility, ist es von Vorteil, ein Verständnis der verschiedenen Abstufungen von Accessibility aufzubauen.

Nicht nur Zugänglichkeit

Das „Gesetz zur Gleichstellung von Menschen mit Behinderungen – Behindertengleichstellungsgesetz (BGG)“ weist durch die Verwendung der Phrase „zugänglich und nutzbar“ auf Unterschiede zwischen diesen beiden Begriffen hin, die häufig synonym verwendet werden. Eine Gleichsetzung der Wörter wird außerhalb des BGG kontrovers diskutiert. Eigenständige Definitionen von „Zugänglichkeit“, „Nutzbarkeit“ und „Barrierefreiheit“ werden von unterschiedlichen Personen und Gruppen angewandt. Hinzu kommt das Bestreben, die Denkansätze „Design4All“ und „Universal Design“ in der Gesellschaft zu etablieren.

Accessibility umfasst all diese Definitionen. Aus ihnen lässt sich eine 4-stufige Hierarchie der unterschiedlichen Ebenen der Accessibility von Software-Produkten ableiten:

• Zugänglichkeit: Informationen können erreicht, wahrgenommen und verstanden werden,
• Barrierefreiheit/Nutzbarkeit: Produkte und Dienstleistungen können von jedem Anwender genutzt, in ihnen navigiert und mit ihnen interagiert werden,
• Design4All: Produkte und Dienstleistungen sind grundsätzlich von verschiedenen Gruppen von Menschen mit den unterschiedlichsten Fähigkeiten und Fertigkeiten nutzbar, wenn auch in Einzelfällen mit Hilfe assistiver Technologie und durch individuelle Anpassbarkeit des Produkts oder der Dienstleistung selbst. Sonderlösungen wie spezielle Implementierungen oder die Notwendigkeit einer Unterstützung durch weitere Personen sollenvermieden werden. Soziales Engagement ist ein wichtiger Faktor von Design4All. Im Gegensatz zu Barrierefreiheit, legt Design4All großen Wert auf die frühe Einbindung von Nutzern sowie auf die Ästhetik von Produkten und Umwelt,
• Universal Design: Produkte und Umgebungen sind so gestaltet, dass sie für alle individuellen Personen gebrauchstauglich sind, ohne Bedarf von Anpassungen oder eines speziellen Designs. Universal Design legt Wert auf eine intuitive Nutzbarkeit und eine Vermeidung von Risiken für die Nutzer.

Die Kreise größer ziehen

Accessibility bezieht sich auch auf die Nutzungsumgebung, nicht allein auf die Fähigkeiten und Fertigkeiten der Nutzer. Bei Berücksichtigung von Accessibility kann eine Reihe von Fragen beantwortet werden, deren Berücksichtigung allen Nutzern zu Gute kommt:

• Auf welchem Gerät wird die Software verwendet?
• Welche zusätzlichen Ein- und Ausgabegeräte werden verwendet?
• Welches Betriebssystem wird verwendet?
• Welcher Browser wird verwendet?
• Welche Internetgeschwindigkeit ist vorhanden?

Das Ziel von Accessibility beschränkt sich nicht darauf, Menschen mit Beeinträchtigungen (Behinderte) die Interaktion mit einem Software-Produkt zu ermöglichen, indem Inhalte zugänglich, erfassbar und verständlich gestaltet werden. Accessibility befähigt auch Nutzer ohne sichtbare Beeinträchtigungen, Software zu nutzen. Im einfachsten Fall erhöht Accessibility die Usability einer Software generell für alle Nutzer.

Für wen denn eigentlich?

Nutznießer eines barrierefreien Softwareprodukts sind neben Menschen mit körperlichen, psychischen oder sensorischen Beeinträchtigungen auch Nutzer mit weniger offensichtlichen Beeinträchtigungen, beispielsweise verursacht durch:

• verminderte Reaktionsgeschwindigkeit,
• reduzierte Aufnahmefähigkeit,
• Lernschwäche,
• Lese-/Rechtschreibschwäche,
• verringerte motorische Fähigkeiten,
• Autismus,
• Epilepsie,
• psychische Erkrankungen,
• Farbenblindheit,
• Rheuma,
• Arthritis,
• Müdigkeit,
• Stress,
• Depression,
• Knochenbrüche (speziell des Arms),
• Ablenkung,
• Reflexionen von Sonnenlicht (beispielsweise auf einem Monitor),
• vergessene Brille.

Software, die nicht accessible gestaltet ist, diskriminiert all diese Nutzer.

Einmal umlegen, bitte

Beeinträchtigte Menschen - im Fall von Software Nutzern - sind nicht per se „behindert“, sie werden behindert durch Barrieren, erzeugt durch eine schlecht konzipierte, schlecht gestaltete oder schlecht umgesetzte Software. Anders ausgedrückt: Eine Behinderung entsteht durch äußere Umstände, nicht durch das Fehlen von Fähigkeiten eines Menschen mit Beeinträchtigung.

Nehmen wir diese Denkweise an, dreht sich die Verantwortlichkeit für Zugänglichkeit, Barrierefreiheit und Nutzbarkeit um: Software- Entwickler sind verantwortlich dafür, dass Nutzer mit jeglicher Fähigkeit und Fertigkeit die bereitgestellte Software gleichermaßen nutzen können. Beeinträchtigte Nutzer sind nicht länger auf assistive Technologien, spezielle Anpassungen von Software oder alternative Produkte mit weniger bzw. ohne Barrieren angewiesen. Accessibility wird integraler Bestandteil des Software-Engineerings. Fehlende Accessibility wird als Bug betrachtet, nicht als vernachlässigbare Software-Qualität.

Es gilt, den mentalen Schalter umzulegen: Fähigkeiten und Fertigkeiten statt Unfähigkeiten zu Fokussieren. Richtlinien, Normen und Gesetze nehmen diese Sicht teilweise bereits ein.

Accessibility oder Usability? Das Oder muss weg!

Gemäß der ISO/IEC Norm 25010 ist Accessibility ein Kriterium der Gebrauchstauglichkeit (Usability) [2]. Accessibility ist also so bedeutsam wie beispielsweise Nutzbarkeit und Lernförderlichkeit. Da Usability ein Bestandteil der User Experience (UX) ist, kann auch Accessibility zu einem gesteigerten Nutzungserleben, zu einer positiven UX aller Nutzer beitragen.

Eine separate Betrachtung und Umsetzung von Accessibility und Usability während des Software-Engineerings ist nicht zielführend. Wie der Versuch, am Ende der Entwicklung Accessibility zu schaffen, vergrößert die Separation von Usability und Accessibility im Normalfall eher den Bedarf an einzusetzenden Ressourcen. Nur die Berücksichtigung eines für jede Nutzergruppe geeigneten Interaction Designs unter Beachtung der Usability Prinzipien [3] und accessible Design Guidelines [4] führt zu einem inklusiven System.

Und wie mache ich das für mein Webangebot?

Die Web Content Accessibility Guidelines (WCAG) des World Wide Web Consortiums (W3C) spezifizieren vier Prinzipien für eine barrierefreie Gestaltung von Webangeboten:

• Wahrnehmbarkeit: Alle Informationen und Bestandteile des UIs müssen möglichst alle Nutzer wahrnehmen können,
• Bedienbarkeit: Alle Bestandteile des UIs und der Navigation müssen mit allen Eingabegeräten bedienbar sein,
• Verständlichkeit: Alle Informationen und die Bedienung des UIs müssen verständlich sein, Abkürzungen und ungewöhnliche Begriffe müssen erläutert werden,
• Robustheit: Nutzer und assistive Technologien müssen Inhalte zuverlässig interpretieren können.

Die ISO-Norm 9241–171 beschreibt barrierefreie Mensch-Maschine-Kommunikation unabhängig von bestimmten Technologien wie dem Web [4]. Sie überführt die WCAG in das gesamte Spektrum informationstechnologischer Anwendungen. Die Norm stellt die Gleichberechtigung möglichst aller Nutzer mit unterschiedlichsten Fähigkeiten heraus. Weiterhin fordert die Norm Wahrnehmbarkeit von Informationen über verschiedene Modalitäten. Daneben ist der Einsatz robuster Technologien nötig, um Interoperabilität mit möglicherweise benötigten technischen Hilfsmitteln zu gewährleisten.

Muss das denn wirklich sein?

In Deutschland gilt die auf den WCAG basierende und in das BGG integrierte Barrierefreie Informationstechnik-Verordnung (BITV). Die BITV ist verpflichtend für Webangebote und öffentlich zugängliche Intranet-Angebote sowie für grafische Programmoberflächen der Bundesbehörden. Anders als die WCAG, fordert die BITV die Bereitstellung von Inhalten in Gebärdensprache sowie in leichter Sprache.

Wie soll ich das denn verstehen?

Das BGG definiert „Barrierefreiheit“ mit einem Fokus auf „Menschen mit Behinderungen“. Es lässt damit außer Acht, dass Barrierefreiheit auch anderen Menschen zu Gute kommt.

Der komplette Text von § 4 des BGG lautet:

Für das Software-Engineering bedeuten die verwendeten Ausdrücke:

„in der allgemein üblichen Weise“: Es darf keine speziellen Ansichten einer Software, keine Sonderlösungen, keine separaten Websites geben, um den Bedarfen beeinträchtigter Nutzer Rechnung zu tragen,

„ohne besondere Erschwernis“: Bei der barrierefreien Gestaltung von Software dürfen keine zusätzlichen Hürden für Nutzer erzeugt werden. Zu Hürden gehört beispielsweise die Pflicht, seine Beeinträchtigung anzugeben und weitere Software installieren und konfigurieren zu müssen, um ein Software-Produkt nutzen zu können,

„grundsätzlich ohne fremde Hilfe“: Die Selbständigkeit der Nutzer der Software muss gewährleistet werden. Weitere Personen, egal ob vor Ort, per Telefon/Smartphone oder per Videotelefonie, dürfen nicht für die Verwendung der Software notwendig sein.

Das ist für uns nicht relevant

Gründe für Unternehmen, sich nicht oder nur wenig mit Accessibility als Teil des Software-Engineerings zu beschäftigen, sind vielfältig (eigene Übersetzung):

• “Menschen mit Beeinträchtigungen zählen nicht zu unseren Zielkunden”
• “Unsere Statistiken zeigen, dass wir keine Nutzer mit Beeinträchtigungen unter unseren Besuchern haben”
• “Wir erhalten keine Beschwerden von Nutzern mit Beeinträchtigungen”
• “Wir hatten andere Prioritäten”
• “Wir planen, Accessibility in künftigen Versionen zu adressieren”
• “Wir hatten weder die Zeit noch das Budget, um die Software accessible zu gestalten”
• „Der direkte Return on Investment ist nicht zu messen“

Weitere Argumente von Unternehmen gegen eine barrierefreie Gestaltung von Software sind, dass dadurch auf eine zeitgemäße Darstellung, die Verwendung moderner Technologien und das Ausleben von Kreativität verzichtet werden müsse. Auch würden Sonderlösungen für vermeintliche Randgruppen nur Personal sowie Zeit und somit Geld verschlingen.

Einige Unternehmen gehen auch davon aus, Accessibility lediglich dadurch zu erreichen, dass automatisierte Accessibility Test Tools den Produkten eine hohe Accessibility bescheinigen. Automatisierte Accessibility Test Tools, beispielsweise Google Lighthouse, prüfen die Qualität des Codes, können allerdings keinen manuellen Test durch eine beeinträchtigte Person ersetzen. Eine durch ein automatisiertes Accessibility Test Tool angegebene perfekte Accessibility kann sich bei der realen Interaktion eines Nutzers mit der Software trotzdem als völlig unbenutzbar herausstellen. Ein durchgeführter und erfolgreicher automatischer Accessibility Test bildet lediglich die Grundlage für manuelle Accessibility Tests durch beeinträchtigte Nutzer in einem realen Kontext.

Vorteile einer barrierefreien Gestaltung von Software-Produkten entkräften Argumente gegen die barrierefreie Software-Gestaltung nicht nur, sondern können skeptische Unternehmen sogar motivieren, mehr Ressourcen für die barrierefreie Gestaltung ihrer Software bereitzustellen.

Und was bringt uns das?

Die barrierefreie Gestaltung von Software-Produkten als integraler Bestandteil des Software-Engineerings schafft systematisch und zielorientiert eine Reihe von Vorteilen, die insbesondere die Nutzbarkeit und die User Experience der Software erhöhen.

Das Angebot der Aktion Mensch für ein barrierefreies Internet „Einfach für Alle“ nennt generelle Vorteile einer barrierefreien Gestaltung von Software:

• Eine schlanke Programmierung sorgt für kürzere Ladezeiten und für geringere Entwicklungskosten,
• barrierefreie Software stellt Inhalt zur Verfügung, der gut verständlich ist,
• barrierefreie Software ist leicht zu bedienen,
• Anbieter barrierefreier Software sparen nicht nur Geld, sie erreichen auch mehr und zufriedenere Kunden.

Nutzer von Geräten mit kleinem Bildschirm, beispielsweise Smartphones und Smart Watches, nutznießen ebenso eine barrierefreie Software-Gestaltung wie Menschen mit Beeinträchtigungen. Benefits umfassen nicht nur die Lesbarkeit von Inhalt, sondern auch die angepassten Eingabemethoden und Eingabemodalitäten.

Was sehen unsere Nutzer davon?

Das UI eines Software-Produkts kann durch diverse einfache Grundlagen barrierefrei gestaltet werden und lässt sich dadurch von einer großen Zahl von Nutzern effektiv und effizient verwenden:

• Verwendung hoher Kontraste,
• Verwendung großer und gut lesbarer Schriftarten,
• Verwendung einfacher Sprache,
• Verwendung korrekt strukturierten HTMLs, inklusive nicht visueller Tags und Attribute wie „alt“ für Alternativtexte für grafische Elemente,
• Verzicht auf animierte Elemente,
• Verzicht auf blinkende/blitzende Elemente,
• Verzicht auf CAPTCHAs,
• Ermöglichung reiner Tastaturnutzung.

Wenn Software vollständig per Tastatur verwendbar ist, ist sie nicht nur von blinden Nutzern bedienbar, sondern auch von Power-Nutzern wie Programmierern und anderen Nutzern, die bei reiner Tastaturnutzung ihre Aufgaben effizienter durchführen können.

Auch temporär eingeschränkte Nutzer, die beispielsweise eine Maus aufgrund einer Sehnenscheidenentzündung nicht benutzen können, profitieren von der Möglichkeit einer reinen Tastaturnutzung.

CAPTCHAs grenzen hörbeeinträchtigte Menschen und sehgeschädigte Menschen aus. Selbst alternativ angebotene Audio-CAPTCHAs können Barrieren auch für Menschen ohne Beeinträchtigung darstellen.

Die genannten Beispiele sind nicht ausreichend, um barrierefreie Software zu entwickeln. Vielmehr dienen sie der Illustration, welche unterschiedlichen Aspekte Barrierefreiheit umfasst. Die erforderlichen Maßnahmen hängen immer stark von dem zu entwickelnden Software-Produkt ab. Hilfreiche Quellen mit Beispielen für die praktische Umsetzung der Richtlinien und Prinzipien sind die WCAG und die ISO Norm 9241–171 [4].

Auch Bots wollen nicht blind durch das Web kriechen

Zu oft übersehenen Aspekten einer barrierefreien Software-Gestaltung gehört beispielsweise auch die barrierefreie Gestaltung eines Webangebots durch die Verwendung von entsprechenden HTML-Tags wie „h#“ für Überschriften und Attributen wie „alt“ für Alternativtexte für grafische Elemente. Hiervon profitieren nicht nur menschliche Nutzer, sondern ebenso Webcrawler, welche die Basis für das Ranking bei Suchmaschinen schaffen.

Suchmaschinenoptimierung setzt hier an: Webcrawler „erkennen“ und kümmern sich nicht um das visuelle Design eines Webangebots. Sie extrahieren Informationen aus dessen Quellcode. Ähnlich wie blinde Nutzer eines Webangebots, die dessen Inhalt mit Hilfe eines Screenreaders erfassen, analysieren Webcrawler ein Webangebot. Auch ein Screenreader analysiert den Quellcode einer Webseite. Was hier nicht an dafür vorgesehenen Stellen angegeben wird, ist sowohl für einen Screenreader als auch für einen Webcrawler unsichtbar, nicht existent.

Die reine Verwendung des „h#“ Tags für die Formatierung von Text (Schriftgröße und Schriftschnitt) stellt hingegen eine Barriere für die meisten Nutzer dar und kann zu einem niedrigeren Ranking bei Suchmaschinen führen.

Durch die Einhaltung von HTML-Richtlinien kann also letztlich ein Webangebot ein höheres Ranking in Suchergebnissen erzielen.

Zahlen, bitte!

Marktgröße und potentieller Umsatz sollten nicht die Grundlage barrierefreier Software-Entwicklung sein. Dennoch hierzu ein paar Zahlen:

• Weltweit leiden ca. 1 Mrd. Menschen an einer anerkannten Behinderung,
• Erweitert um Menschen, die an altersbedingten Beeinträchtigungen leiden, umfasst der Markt für barrierefreie Software ca. 2,3 Mrd. Menschen,
• Menschen mit Behinderungen bzw. Beeinträchtigungen haben ein geschätztes verfügbares Jahreseinkommen von ca. 6,9 Billionen Dollar.

Auch Kosten sowohl für die Entwicklung als auch für die Wartung und Pflege der Software sowie für Dienstleistungen lassen sich durch barrierefreie Software-Gestaltung einsparen.

Perspektivwechsel

Bei der Entwicklung barrierefreier Software geht es - ähnlich wie bei Design Thinking - darum, dass von Beginn der Software-Entwicklung an Designer, Programmierer und Experten für Usability und User Experience die Perspektive von Endnutzern ohne und mit verschiedenen Beeinträchtigungen einnehmen. Gemeinsam entwickelt das Team eine für alle potentiellen Endnutzer zugängliche und nutzbare Software. Ein solches Entwicklungs-Team orchestriert Software Architektur, Usability, visuelles Design, Information Architecture und Information Design sowie User Experience.

Beschäftigt sich ein Entwicklungs-Team von Anfang an mit Barrierefreiheit und plant es entsprechende Entwicklungsschritte, schafft es ohne großen Mehraufwand eine barrierefreie Software.

Barrierefreiheit erst im Nachgang erzeugen zu wollen bzw. eine Software bezüglich ihrer Barrierefreiheit zu überarbeiten, kann einen immensen Aufwand bedeuten. Dieser Aufwand kann so groß sein, dass eine komplette Neuentwicklung der Software günstiger und weniger aufwendig sein kann als ein Re-Design.

So sieht’s aus!

Barrierefreiheit kann zu einer überproportional ansteigenden Nutzerzufriedenheit, einer überproportional ansteigenden positiven User Experience und größerer Loyalität der Nutzer gegenüber des Software-Produkts, der Marke und des Unternehmens führen.

Die Berücksichtigung von Accessibility über den gesamten Software-Entwicklungsprozess hinweg schafft neben der Adressierung eines deutlich größeren Markts auch diverse weitere Vorteile wie Kosteneinsparungen, höhere Verständlichkeit, bessere Bedienbarkeit, Geräteunabhängigkeit und ein besseres Suchmaschinenranking.

Bestehende Normen und Richtlinien unterstützen dabei, barrierefreie Software zu entwickeln. Accessibility als Teil von Usability sollten Unternehmen aber als integralen Bestandteil des Software-Engineerings betrachten. Ein entsprechendes Umdenken findet langsam statt.

Für Unternehmen bieten sich durch die Entwicklung und das Anbieten barrierefreier Software auch Chancen für das eigene Fortbestehen. Die Anzahl beeinträchtigter Nutzer wächst stetig. Usability wird von Nutzern vorausgesetzt. Das Verlangen nach Barrierefreiheit als Mehrwert für alle Nutzer steigt ebenfalls.

Schließlich ist Barrierefreiheit eine Investition in die eigene Zukunft: 96 % aller beeinträchtigten Menschen werden durch Krankheiten, Unfälle und einfach durch das Alter beeinträchtig - und die Lebenserwartung steigt…

Referenzen