Die Technologiebranche befindet sich derzeit in einer Phase tiefgreifender Veränderungen. Immer mehr Unternehmen erkennen – freiwillig oder schmerzhaft durch eine Klage –, dass sie damit beginnen müssen, ihre Anwendungen und Websites nach dem Prinzip „Barrierefreiheit zuerst“ zu gestalten.
Wenn wir über Barrierefreiheit nachdenken, denken wir vielleicht zunächst an Menschen mit körperlichen Behinderungen, die auf den ersten Blick erkennbar sind. Und obwohl diese Menschen zweifellos einen wichtigen Teil unserer Nutzerbasis ausmachen, sind sie nicht die Einzigen, die von barrierefreier Software profitieren.
Es gibt 5 Hauptkategorien von Behinderungen: visuelle, Hör-, motorische, Sprach- und kognitive Beeinträchtigungen. Die meisten Menschen werden im Laufe ihres Lebens wahrscheinlich mindestens eine davon erleben, selbst wenn es sich nicht um eine dauerhafte Situation handelt. Diese Grafik von Microsoft gehört zu meinen absoluten Favoriten; sie veranschaulicht dieses Konzept hervorragend:
Siehe auch: Die dringende Notwendigkeit, die Geschäftsstrategie an ESG auszurichten
Viele Menschen machen den Fehler, Funktionen für mehr Barrierefreiheit als eine Art Sonderfall oder als wünschenswerte, aber nicht wirklich notwendige Ergänzung zu betrachten. Tatsächlich profitieren alle Ihre Nutzer davon. Alles, was Sie beispielsweise für Nutzer mit eingeschränktem Hörvermögen entwickeln, kommt auch Nutzern zugute, die in öffentlichen Verkehrsmitteln ohne Kopfhörer unterwegs sind.
Alles, was Sie entwickeln für Nutzer mit Sehbehinderung, kommt auch Nutzern zugute, die an diesem Morgen mit Migräne aufgewacht sind und es nicht ertragen, auf einen Bildschirm zu schauen. Wir alle brauchen Funktionen für mehr Barrierefreiheit, auch wenn uns das nicht bewusst ist.
Den gedanklichen Wechsel zu einem barriereorientierten Design zu vollziehen, kann jedoch schwierig sein. Ähnlich wie beim Mobile-First-Ansatz bedeutet „Barrierefreiheit zuerst“, dass Sie Ihre grundsätzliche Herangehensweise an die Entwicklung Ihrer Anwendungen ändern müssen.
Die folgenden Anpassungen helfen Ihnen, Ihre Denkweise bei der Entwicklung von Software neu auszurichten.
Siehe auch: Wie KI die Softwareentwicklung durch KI-Augmentierung verändert
Barrierefreiheit gehört zum Minimum Viable Product
Viele Softwareunternehmen verfolgen den MVP-Ansatz, also das Minimum Viable Product: Was ist das kleinste nützliche Produkt, das sie veröffentlichen können, um eine Funktion auf den Markt zu bringen und mit dem Testen zu beginnen?
Das ist eine hervorragende Methode, um große Ideen in umsetzbare Teile zu zerlegen und die zentralen Werte einer neuen Funktion zu identifizieren. Sie unterstützt ganz natürlich eine Feedback- und Iterationsschleife, die für Design und Entwicklung gleichermaßen hilfreich ist. Bei der Definition dieses Minimums muss Barrierefreiheit jedoch berücksichtigt werden.
Eine der häufigsten und ersten Fehlannahmen beim barrierefreien Design ist, dass man einfach nachträglich ein fertiges Produkt überarbeiten und mit ein paar Anpassungen Barrierefreiheit hinzufügen kann. Doch das stimmt nicht.
Viele Unternehmen betonen zwar pro forma die Bedeutung von Barrierefreiheit in ihren Produkten und stellen sie vielleicht sogar prominent als Verkaufsargument auf ihrer Website heraus … wenn es jedoch darum geht, in einem vollen Sprint Zeit dafür einzuplanen oder den Umfang des MVP einzugrenzen, steht Barrierefreiheit als Erstes auf der Streichliste.
Beim Prinzip „Barrierefreiheit zuerst“ lehnen wir die Vorstellung ab, dass Barrierefreiheit keine Notwendigkeit sei. Barrierefreiheit lässt sich nicht später hinzufügen – oder schlimmer noch: vollständig streichen, wenn die Frist knapp wird. Wir müssen von der Grundannahme ausgehen, dass etwas nicht funktioniert, wenn es nicht barrierefrei funktioniert.
Sobald Sie Barrierefreiheit als grundlegende Anforderung betrachten, ergibt sich alles Weitere ganz natürlich.
Siehe auch: Digitale Transformation: Definition, Arten und Strategien
Vielfältige Nutzertests im Voraus planen
Bei Nutzertests habe ich festgestellt, dass oft gute Absichten vorhanden sind, es aber an der Umsetzung mangelt. Das ist verständlich – die Organisation kann schwierig und zeitaufwendig sein, und häufig braucht man mindestens eine Person im Team, die wirklich weiß, was sie tut, um alles zusammenzuführen.
Das Feedback echter Nutzer einzuholen, ist jedoch unschätzbar wertvoll und den Zeit- und Arbeitsaufwand immer wert. Gespräche mit Ihren Nutzern verschaffen Ihnen einen Einblick, den Sie allein einfach nie gewinnen werden, ganz gleich, wie sehr Sie sich bemühen.
Da es jedoch so schwierig sein kann, sieht die Realität von Nutzertests häufig etwas improvisierter aus – etwa in Form kurzer Tests auf dem Flur mit Mitarbeitern aus anderen Abteilungen oder einmaliger Gespräche mit langjährigen Kunden, die bereit sind, eine Stunde ihres Montagnachmittags zu opfern.
Kurz gesagt: Bei dieser Art von Nutzertests wird die vielfältige und inklusive Gruppe von Nutzern, die Sie für einen gründlichen Test Ihrer Anwendung tatsächlich benötigen würden, nur selten einbezogen. Selbst wenn Sie ein hervorragendes Nutzertestprogramm haben, erzeugen Sie möglicherweise unabsichtlich Verzerrungen in Ihren Ergebnissen, wenn Sie Ihre Arbeit nur mit Menschen ohne Behinderungen testen.
Dieses Problem lässt sich mit etwas Voraussicht und Planung lösen. Das bedeutet, dass Sie zunächst ein standardisiertes Nutzertestprogramm etablieren müssen, falls Ihr Unternehmen bislang in die Kategorie „hier und da ein kleiner Test auf dem Flur“ gefallen ist.
Wenn Sie bereits ein Nutzertestprogramm etabliert haben und sich damit in einer guten Ausgangslage befinden, geht es darum, bei der Suche nach Testpersonen Ihr Netz weiter auszuwerfen. Das könnte bedeuten, einen Anreiz anzubieten, etwa Geschenkkarten oder kostenlose Produkttests. Oder Sie könnten Kontakt zu einer lokalen Gruppe oder Fachperson für die Unterstützung von Menschen mit Behinderungen aufnehmen oder Ihre Informationen zur Suche nach Testpersonen in entsprechenden Online-Gruppen teilen, um den Pool verfügbarer Nutzer zu vergrößern.
Das Prinzip „Barrierefreiheit zuerst“ erinnert uns daran, dass Barrierefreiheit ein entscheidender Bestandteil unserer Anwendung ist. Wenn sie in den Nutzertests überhaupt nicht berücksichtigt wird … nun, dann testen Sie eigentlich nicht.
Siehe auch: Die wichtigsten Trends der digitalen Transformation im Jahr 2022
Barrierefreiheit ist Sache aller
Es gibt einige Produkte, die Sie davon zu überzeugen versuchen, dass Sie nicht wirklich etwas lernen, Ihre Entwicklungsprozesse ändern oder Ihre bestehende Anwendung aktualisieren müssen. Sie müssen nur deren Produkt installieren, und schon macht es auf magische Weise alles barrierefrei – für Sie, normalerweise über eine komplizierte Reihe von Overlays.
Das ist falsch. Barrierefreiheit lässt sich nicht nachträglich über eine bestehende, nicht barrierefreie Anwendung legen; wer etwas anderes behauptet, will Ihnen etwas verkaufen.
„Barrierefreiheit zuerst“ bedeutet, dass wir die Arbeit an der Barrierefreiheit unserer Anwendung weder auslagern – etwa an ein externes Team oder ein Produkt – noch vollständig auf die Schultern einer einzigen Fachperson legen.
Stattdessen machen wir Barrierefreiheit zu einem Bestandteil der Wissensbasis aller Beteiligten, damit sie von Anfang an in das Produkt einfließen kann.
Es gibt einige seriöse Berater für Barrierefreiheit, und es kann sinnvoll sein, einen von ihnen zu engagieren – jemanden, der zu Ihnen kommt und sich tatsächlich mit Ihren Mitarbeitern zusammensetzt, um die Besonderheiten Ihrer Anwendung zu besprechen. Dabei sollte jedoch klar sein, dass die Beauftragung einer Fachperson für Barrierefreiheit ein erster Schritt und keine einmalige Lösung ist.
Wenn Sie auf externes Fachwissen angewiesen sind, geraten Sie in eine Endlosschleife: Sie engagieren eine Fachperson, verbessern Ihre App und sehen dann langsam dabei zu, wie sie mit der Veröffentlichung neuer, nicht barrierefreier Funktionen wieder weniger barrierefrei wird … bis Sie das Gefühl haben, sie sei schlecht genug geworden, um erneut eine Fachperson für Barrierefreiheit zu engagieren, die sie repariert. Das ist mühsam, teuer und stört Ihren regulären Entwicklungszyklus. Und doch ist es ein Muster, in das meines Wissens mehr als ein Unternehmen geraten ist.
Ebenso wenig wollen Sie, dass die gesamte Arbeit an der Barrierefreiheit in der Verantwortung eines einzigen Designers oder Entwicklers liegt, der zufällig bereits über das nötige Wissen verfügt. Eine Person zur Fachkraft zu machen, ist keine langfristige Lösung – was passiert, wenn sie krank ist oder eine neue Stelle findet? Ganz zu schweigen davon, dass sie unmöglich an jedem Meeting teilnehmen kann. Und die Rolle des „Bösewichts“ zu übernehmen, der die Arbeit anderer Teammitglieder ständig als nicht barrierefrei kritisieren muss, macht keinen Spaß.
Die Bedeutung der Unterstützung durch das Management
Wenn Ihre Designer und Entwickler sich nicht sicher fühlen, barrierefreie Software entwerfen und entwickeln zu können, ist es wichtig, dass das Management ihnen die nötige Bildung, Schulung und die erforderlichen Ressourcen zur Verfügung stellt, um diese Fähigkeiten aufzubauen.
Damit wird das Problem an der Wurzel gelöst und Ihre aktuellen Mitarbeiter werden befähigt, neue Kollegen zu schulen, während das Team wächst. Außerdem entsteht in Ihrem Team eine Kultur gemeinsamer Verantwortung, sodass sich alle bei Diskussionen, der Planung und dem Feedback gleichberechtigt und aus einer barriereorientierten Perspektive einbringen können.
Sobald wir anerkennen, dass Barrierefreiheit ein notwendiger Bestandteil des gesamten Funktionsumfangs eines Produkts ist, kann diese Erkenntnis jede Entscheidung beeinflussen, die wir in Bezug auf Planung, Design, Entwicklung und Tests treffen. Befähigen Sie Ihr Management und Ihre Teams, Barrierefreiheit nach dem Prinzip „Barrierefreiheit zuerst“ zu priorisieren, und ich bin überzeugt, dass sie die Herausforderung meistern werden.
Siehe auch: Technologieprognosen für 2022: Cloud, Daten, Cybersicherheit, KI und mehr
Über den Autor:
Kathryn Grayson Nanz, Developer Advocate, Progress