Durch das Barrierefreiheitsstärkungsgesetz (BFSG) werden sich Unternehmen in den nächsten Monaten und Jahren verstärkt mit dem Thema Barrierefreiheit auseinandersetzen müssen. Auch wenn die Einhaltung der Barrierefreiheitsanforderungen des BFSG ein wichtiger erster Schritt in Richtung digitaler Barrierefreiheit ist, reicht dies nicht aus, um alle Barrierefreiheitsprobleme aufzudecken. UX Research ist ein tolles Werkzeug, um genau die Probleme zu identifizieren, die die durch die bloße Einhaltung der WCAG nicht abgedeckt werden.
Das Barrierefreiheitsstärkungsgesetz (BFSG) kommt!
Digitale Barrierefreiheit ist eigentlich schon lange ein Thema. Spätestens seit den 1990er Jahren: Windows95 war das erste Betriebssystem, das standardmäßig Barrierefreiheitsfeatures beinhaltete. Die erste Version der Web Content Accessibility Guidelines wurde 1999 vom World Wide Web Consortium (W3C) veröffentlicht[1]. Für Menschen mit Behinderungen ist digitale Barrierefreiheit (oder das Fehlen dieser) ein alltägliches Thema. Dennoch wird sie von Unternehmen, die digitale Produkte und Dienstleistungen anbieten, häufig vernachlässigt.
Für viele deutsche Unternehmen wird es jedoch spätestens im nächsten Jahr relevant, denn am 28.06.2025 tritt das Barrierefreiheitstärkungsgesetz (BFSG) in Kraft. Mit dem BFSG wurde im Juli 2021 der European Accessibility Act (EAA) in das nationale Recht überführt. Durch das BFSG soll die Zugänglichkeit von Produkten und Dienstleistungen für Menschen mit Behinderungen oder Beeinträchtigungen sowie für ältere Menschen verbessert werden.[2].
Um zu verstehen, welche Implikationen das BFSG für Unternehmen hat, müssen wir einen kurzen, rechtlichen Exkurs machen. Achtung: Ich bin keine Juristin, daher sind die folgenden Informationen ohne Gewähr ?
Das BFSG definiert Barrierefreiheitsanforderungen für bestimmte Produkte und Dienstleistungen, die nach dem Ablauf der Frist in Verkehr gebracht bzw. für Verbraucher*innen erbracht werden (welche Produkte und Unternehmen genau betroffen sind, kann man in dieser Übersicht nachlesen). Bei Verstößen gegen das BFSG kann die Marktüberwachungsbehörde anordnen, das Produkt oder die Dienstleistung zurückzurufen bzw. einzustellen und Bußgelder von bis zu 100.000 € verhängen[3].
Die Anforderungen an die Barrierefreiheit sind in der Verordnung zum BFSG (BFSGV) geregelt. In vielen Artikeln wird im Kontext der BFSGV auf die europäische Norm EN 301 549 verwiesen. Diese wiederum bezieht sich auf die AA-Standards der Web Content Accessibility-Guidelines 2.1 (WCAG 2.1)[4].
Zusammengefasst heißt das: Bestimmte Produkte und Dienstleistungen müssen ab dem 28.06.2025 die Konformitätsstufe AA der WCAG 2.1 erfüllen. Aber was sind überhaupt die WCAG? Und was bedeutet Konformitätsstufe AA?
Die Web Content Accessibility Guidelines (WCAG)
Die Web Content Accessibility Guidelines (WCAG) sind ein internationaler Standard für die barrierefreie Gestaltung von Webinhalten des World Wide Web Consortium (W3C)[5]. Obwohl mittlerweile die im Oktober 2023 aktualisierte Version 2.2 vorliegt, bezieht sich die EN 301 549 derzeit noch auf die Vorgängerversion 2.1 (Stand November 2024).
Die WCAG gliedern sich in die vier Prinzipien Wahrnehmbarkeit, Benutzbarkeit, Verständlichkeit und Robustheit. Wie genau diese Prinzipien eingehalten werden können, ergibt sich aus einer Reihe von Erfolgskriterien, die den einzelnen Prinzipien zugeordnet sind[6].
Quelle: WCAG-2.2-Karte von Intopia https://intopia.digital/wp-content/uploads/2024/05/German-WCAG-2.2-Map.pdf
Die Erfolgskriterien sind in verschiedene Prioritätsstufen eingeteilt – Stufe A (höchste Priorität), AA und AAA (niedrigste Priorität). Um die Konformitätsstufe AA zu erreichen, müssen alle Erfolgskriterien der Prioritätsstufen A und AA erfüllt sein. Eine genaue Erläuterung der einzelnen Erfolgskriterien und deren Einhaltung findet man auf der Website des W3C[7]. Wer noch mehr Grundlagen zur Barrierefreiheit im UX Design lesen möchte, dem empfehle ich den Blogbeitrag meiner Kollegin Catharina: UX Accessibility & Barrierefreiheit 101
WCAG-Konformität ist nicht alles
Nun könnte man denken: „Alles klar, wir erstellen eine Checkliste aller A- und AA-Erfolgskriterien der WCAG 2.1, haken alles ab und dann ist unser Produkt barrierefrei!“
Das ist auf jeden Fall ein guter Anfang und ein erster wichtiger Schritt in Richtung Barrierefreiheit. Es wird auch ausreichen, um die Anforderungen des BFSG zu erfüllen. Trotzdem garantiert dieser Ansatz nicht die vollständige Barrierefreiheit eines Produktes.
Die WCAG-Kriterien sind allgemeine Richtlinien zur Sicherstellung von Web Accessibility. Bei einer alleinigen Orientierung an den WCAG-Kriterien werden Eigenschaften der Nutzergruppe und des Nutzungskontextes nicht berücksichtigt.
UX Research kann Barrierefreiheitsprobleme aufdecken, die von den WCAG nicht berücksichtigt werden. Beispielsweise ist es möglich, dass bestimmte Barrierefreiheitsprobleme bei bestimmten Nutzergruppen häufiger oder seltener auftreten als in der Gesamtpopulation. Das W3C selbst empfiehlt neben der Einhaltung der WCAG-Erfolgskriterien auch die Durchführung von UX Research mit Menschen mit Behinderungen.[8].
Ein Beispiel dafür, wie UX Research zusätzliche Barrierefreiheitsprobleme aufdecken kann, stammt von James Buller, der als UX Researcher für das britische Innenministerium arbeitet. Sein Team und er haben Usability Tests durchgeführt, um herauszufinden, wie Nutzende beim Beantragen eines Reisepasses vorgehen[9]. In einer Sitzung mit einer gehörlosen Teilnehmerin wurde ein Problem mit dem Kontaktformular festgestellt: Die Teilnehmerin musste eine Telefonnummer in das Kontaktformular eingeben. Sie wollte angeben, dass sie nicht angerufen werden möchte, da sie gehörlos ist. Das Eingabefeld für die Telefonnummer ließ jedoch nur die Eingabe von Zahlen zu, so dass sie ihren Hinweis nicht hinzufügen konnte. Das Formular war zwar WCAG-konform, aber nicht barrierefrei, da es diese Option nicht enthielt.
UX Research für alle! – Ideen für mehr Inklusion und Barrierefreiheit
Um Produkte und Dienstleistungen benutzerfreundlich zu gestalten, wenden wir den Prozess der menschzentrierten Gestaltung an. Das Ziel der menschzentrierten Gestaltung ist es, Produkte und Dienstleistungen gebrauchstauglich und zweckdienlich zu machen[10]. Dabei orientieren wir uns unter anderem an den Bedürfnissen (User Needs) und Anforderungen (User Requirements) der Nutzenden.
Dazu gehören auch Access Needs. Access Needs bezeichnen im Kontext von menschzentrierter Gestaltung alle Voraussetzungen, die erfüllt sein müssen, damit ein*e Nutzer*in ein Produkt erfolgreich nutzen kann. Access Needs sind User Needs!
Das Thema Barrierefreiheit sollte also in jedem Schritt des menschzentrierten Gestaltungsprozesses, d.h. auch im UX Research, mitberücksichtigt werden. Im Folgenden werden einige Impulse für eine stärkere Verankerung von Barrierefreiheit im UX Research vorgestellt.
Im Idealfall sollte bei jedem Research-Vorhaben einen Anteil der Sessions mit Teilnehmenden durchgeführt werden, die der Nutzergruppe entsprechen, eine Behinderung haben und ggf. auch assistive Technologien nutzen. Wenn in einem Projekt regelmäßig UX Research durchgeführt wird und darauf geachtet wird, dass immer ein gewisser Anteil von Teilnehmenden mit unterschiedlichen Behinderungen einbezogen wird, erhöht sich die Wahrscheinlichkeit, im Laufe der Zeit alle relevanten Barrierefreiheitsprobleme aufzudecken.
Wenn wir UX Research mit Menschen mit Behinderung durchführen, ist es wichtig, auch den Research-Prozess barrierefrei zu gestalten. Grundsätzlich sollte UX Research natürlich möglichst immer nutzerzentriert und bedürfnisorientiert sein. Bei Teilnehmer*innen mit Behinderung gilt es aber, ein besonderes Augenmerk auf die Barrierefreiheit zu werfen. Denn wenn unser Research nicht barrierefrei ist, haben Teilnehmer*innen mit Behinderung nicht die Möglichkeit, so effektiv mitzumachen wie Teilnehmer*innen ohne Behinderung. Aus diesem Grund müssen wir im Vorhinein identifizieren, welche Access Needs unsere Teilnehmenden an den UX Research haben.
Je nach Zielgruppe und Behinderung müssen wir uns unterschiedliche Fragen stellen, z. B: Soll der Test im Büro, bei den Teilnehmenden zu Hause oder remote durchgeführt werden? Ist der Prototyp, mit dem der Usability-Test durchgeführt wird, für alle zugänglich? Kann der Fragebogen mit Keyboard-Only Navigation oder mit einem Screenreader ausgefüllt werden?
Ein Fallbeispiel für barrierefreien UX Research ist das vom BMBF geförderte Projekt MightyU. Ziel des Projekts war die Entwicklung eines Serious Games, mit dem Kinder mit infantiler Zerebralparese (ICP) ihre Therapieübungen spielerisch und selbstwirksam zu Hause durchführen können. In diesem Projekt mussten einigen Herausforderungen beim Research beachtet werden: Die Kinder und Eltern sind durch die Krankheit häufig zeitlich und mental stark belastet. Zudem ist die Ausprägung der Erkrankung von Person zu Person sehr unterschiedlich. Die Testungen wurden bei den Kindern zuhause durchgeführt, um den Nutzungskontext kennenzulernen und möglichst wenig Zeit der Kinder und Eltern zu beanspruchen. Darüber hinaus war bei der Planung des UX Research der Vater eines betroffenen Kindes im Konsortium, um Ideen einzubringen und zu bewerten.
Es gilt also, sich vor dem Research die richtigen Fragen zu stellen, sich zu informieren und ggf. kreativ zu werden. So können sich Teilnehmende mit und ohne Behinderung gut einbringen und wir erhalten spannende und verlässliche Erkenntnisse.
Inklusive Personas
Eine Persona ist eine fiktive Beschreibung eines typischen Nutzers bzw. einer typischen Nutzerin. Personas helfen dem Team dabei, mehr Empathie gegenüber den verschiedenen Nutzergruppen zu empfinden und somit während des gesamten Projektverlaufs nutzerzentrierte Entscheidungen zu treffen[11].
Allen Leser*innen, die schon mal an der Entwicklung von Personas beteiligt waren, möchte ich folgende Frage stellen: Wie viele dieser Personas hatten eine Behinderung, die die Art und Weise, wie sie das Produkt oder die Dienstleistung nutzen können, beeinflusst hat? Aus meiner Erfahrung würde ich vermuten, dass die überwiegende Mehrheit der Personas keine Behinderung hatte.
Um Barrierefreiheit so früh wie möglich zu berücksichtigen, sollte man verschiedene Personas mit unterschiedlichen Behinderungen entwickeln, die verschiedene Arten assistiver Technologien nutzen.
Bei der Entwicklung von Personas mit Behinderung sind verschiedene Aspekte wichtig: Zum einen sollten die Personas auf den Nutzungskontext des Produkts oder der Dienstleistung zugeschnitten sein. Das bedeutet, dass man die Charakteristika der Nutzenden, ihre Ziele und Aufgaben und ihre Ressourcen und Umgebung berücksichtigt.
Man sollte sich auch bewusst machen, dass die Persona niemals eine ganze soziale Gruppe (z.B. alle Menschen mit motorischen Behinderungen) repräsentieren kann und sollte. Dies birgt die Gefahr der Übergeneralisierung.
Last, but certainly not least: Personas sollten durch die Durchführung von UX Research kontinuierlich validiert, korrigiert und ergänzt werden. Personas, die nur auf den Annahmen des Teams basieren, werden auch Protopersonas genannt[12] und bergen die Gefahr, dass Entscheidungen im Designprozess auf Basis (möglicherweise) falscher Annahmen getroffen werden.
Wichtig ist auch, dass die Teilnehmer*innen im UX Research wirklich zu der Nutzergruppe passen. In der Rekrutierung darf nicht das alleinige Screening-Kriterium sein, dass die Teilnehmer*innen eine bestimmte Behinderung haben. Viele Faktoren können die User Needs und die Art und Weise, mit dem Produkt zu interagieren, beeinflussen – z.B. Alter, Bildungsstand, Geschlecht, Technologieerfahrung und Persönlichkeit. Man kann die ausgearbeitete Protopersona dafür nutzen, die richtigen Screening-Kriterien für die Rekrutierung der Teilnehmenden zu definieren.
Léonie Watson hat dies gut mit folgendem Beispiel zusammengefasst[13]:
„Wenn man eine App für Mädchen im Teenageralter entwickelt, macht es keinen Sinn, einen vierzigjährigen Mann zu bitten, die App zu testen, nur weil er zufällig einen Screenreader benutzt. Genauso wie seine Einstellung und seine Fähigkeiten im Allgemeinen anders sind, wird auch seine Fähigkeit, assistive Technologien zu nutzen, anders sein als bei jemandem, der 25 Jahre jünger ist.“
Léonie Watson, Mitglied des W3C-Board of Directors
Eine tolle Ressource, an der man sich orientieren kann, wenn man zum ersten Mal Personas mit Behinderungen entwickelt sind die Personas für Barrierefreiheit der Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik. Diese Personas stellen hypothetische Nutzer*innen mit einer Reihe von unterschiedlichen Access Needs dar. Da diese Personas recht allgemein gehalten sind, sollte man sie lediglich als Grundlage für die Entwicklung von eigenen Personas einsetzen. Man kann auch darüber nachdenken, AI-Tools bei der Entwicklung der Personas einzusetzen. Wer über dieses spannende Thema mehr erfahren möchte, dem sei Thomas‘ Blogartikel über KI-Personas nahegelegt.
Fazit
„Barrierefreiheit ist für einige essenziell und für alle nützlich.“
Shawn Lawton Henry, W3C Web Accessibility Initiative (WAI) Program Lead[14]
Abschließend noch ein Argument dafür, warum sich alle UX Professionals mit Barrierefreiheit beschäftigen sollten. Das primäre Ziel von digitaler Barrierefreiheit ist es, digitale Inhalte und Technologien für Menschen mit Behinderung zugänglich zu machen. Natürlich profitieren aber nicht nur Menschen mit Behinderung von einer guten Accessibility, sondern alle Nutzer*innen. Eine Studie aus dem International Journal of Human-Computer Studies zeigt, dass eine hohe Barrierefreiheit mit einer guten User Experience zusammenhängt[15]. Wir alle profitieren von digitaler Barrierefreiheit, wenn wir temporär (z.B. durch einen gebrochenen Arm) oder situational eingeschränkt sind (z.B. weil wir in einer lauten Umgebung sind). Ganz abgesehen davon ist es nicht unwahrscheinlich, dass man selbst im Laufe des Lebens eine Behinderung erwirbt, z.B. durch einen Unfall, eine Erkrankung oder durch das Älterwerden.
Quelle: Microsoft Inclusive Design https://inclusive.microsoft.design/tools-and-activities/Inclusive101Guidebook.pdf
Bei der Umsetzung von digitaler Barrierefreiheit ist WCAG-Compliance nicht alles. Es lohnt sich, über die Einhaltung der WCAG hinaus UX Research mit Fokus auf Barrierefreiheit durchzuführen. Dabei sollte man darauf achten, dass der UX Research zugänglich für alle Teilnehmenden ist. So baut man Schritt für Schritt Barrieren in seinen digitalen Produkten ab – und vergrößert ganz nebenbei seine potenzielle Nutzerbasis.
Wenn du mehr zu diesem Thema erfahren möchtest: Bald erscheint unser neuer Podcast 2025: Odysee Accessibility, indem es um Accessibility und AI geht.
Du möchtest die Barrierefreiheit deines Produkts verbessern?
Quellen
[1] Tasyürek, D. (2022, Oktober 25). The History of Digital Accessibility. Storyly. https://www.storyly.io/post/the-history-of-digital-accessibility
[2] Der Beauftragte der Bundesregierung für Informationstechnik. (2023, Dezember 19). Barrierefreiheitsstärkungsgesetz (BFSG). Portal Barrierefreiheit der Dienstkonsolidierung des Bundes. https://www.barrierefreiheit-dienstekonsolidierung.bund.de/Webs/PB/DE/gesetze-und-richtlinien/barrierefreiheitsstaerkungsgesetz/barrierefreiheitsstaerkungsgesetz-node.html
[3] Barrierefreiheitsstärkungsgesetz: Barrierefreiheit wird für Privatunternehmen Pflicht. (o. J.). Industrie- und Handelskammer für München und Oberbayern. https://www.ihk-muenchen.de/de/Service/Recht-und-Steuern/Werbung-Fairer-Wettbewerb/barrierefreiheitsstaerkungsgesetz/
[4] Der Beauftragte der Bundesregierung für Informationstechnik. (2024). Harmonisierte Europäische Norm (EN) 301 549. Portal Barrierefreiheit der Dienstkonsolidierung des Bundes. https://www.barrierefreiheit-dienstekonsolidierung.bund.de/Webs/PB/DE/gesetze-und-richtlinien/barrierefreiheitsstaerkungsgesetz/barrierefreiheitsstaerkungsgesetz-node.html
[5] Lawton Henry, S. (2024, März 7). WCAG 2 Overview. World Wide Web Consortium (W3C). https://www.w3.org/WAI/standards-guidelines/wcag/
[6] Hellbusch, J. (2024). Die vier Prinzipien der Web Content Accessibility Guidelines (WCAG) 2.2. Barrierefreies Webdesign. https://www.barrierefreies-webdesign.de/richtlinien/wcag-2.2/
[7] Eggert, E., & Abou-Zahra, S. (2023, November 12). How To Meet WCAG (Quick Reference). World Wide Web Consortium (W3C). https://www.w3.org/WAI/WCAG22/quickref/
[8] Lawton Henry, S. (2021, Juni 1). Involving Users in Evaluating Web Accessibility. W3C Web Accessibility Initiative (WAI). https://www.w3.org/WAI/test-evaluate/involving-users/
[9] Firth, A. (2020). Practical web inclusion and accessibility: A comprehensive guide to access needs. Apress.
[10] German UPA e.V. (o. J.). Menschzentrierte Gestaltung nach DIN EN ISO 9241-210. German UPA. Abgerufen 17. April 2024, von https://germanupa.de/wissen/berufsbild-usability-ux-professional/grundlegend/menschzentrierte-gestaltung
[11] Harley, A. (2015, Februar 16). Personas Make Users Memorable for Product Team Members. Nielsen Norman Group. https://www.nngroup.com/articles/persona/
[12] Laubheimer, P. (2020, Juni 21). 3 Persona Types: Lightweight, Qualitative, and Statistical. Nielsen Norman Group. https://www.nngroup.com/articles/persona-types/
[13] Kalbag, L. (2017). Accessibility for everyone. A Book Apart.
[14] Dobbs, S. (2024, Mai 31). Web Accessibility: Removing barriers, designing a web for everyone. World Wide Web Consortium (W3C). https://www.w3.org/blog/2024/web-accessibility-removing-barriers-designing-a-web-for-everyone/
[15] Aizpurua, A., Harper, S., & Vigo, M. (2016). Exploring the relationship between web accessibility and user experience. International Journal of Human-Computer Studies, 91, 13–23. https://doi.org/10.1016/j.ijhcs.2016.03.008
