![\"Eine](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/accessibility-keyvisual-1500x750.png\")
<\/p>\n<\/p>\n
Durch das Barrierefreiheitsst\u00e4rkungsgesetz (BFSG) werden sich Unternehmen in den n\u00e4chsten Monaten und Jahren verst\u00e4rkt mit dem Thema Barrierefreiheit auseinandersetzen m\u00fcssen. 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\u00dfe Einhaltung der WCAG nicht abgedeckt werden.<\/p>\n
Digitale Barrierefreiheit ist eigentlich schon lange ein Thema. Sp\u00e4testens seit den 1990er Jahren: Windows95 war das erste Betriebssystem, das standardm\u00e4\u00dfig Barrierefreiheitsfeatures beinhaltete. Die erste Version der Web Content Accessibility Guidelines wurde 1999 vom World Wide Web Consortium (W3C) ver\u00f6ffentlicht[1]<\/a>. F\u00fcr Menschen mit Behinderungen ist digitale Barrierefreiheit (oder das Fehlen dieser) ein allt\u00e4gliches Thema. Dennoch wird sie von Unternehmen, die digitale Produkte und Dienstleistungen anbieten, h\u00e4ufig vernachl\u00e4ssigt.<\/p>\n F\u00fcr viele deutsche Unternehmen wird es jedoch sp\u00e4testens im n\u00e4chsten Jahr relevant, denn am 28.06.2025<\/strong> tritt das Barrierefreiheitst\u00e4rkungsgesetz (BFSG) in Kraft. Mit dem BFSG wurde im Juli 2021 der European Accessibility Act (EAA) in das nationale Recht \u00fcberf\u00fchrt. Durch das BFSG soll die Zug\u00e4nglichkeit von Produkten und Dienstleistungen f\u00fcr Menschen mit Behinderungen oder Beeintr\u00e4chtigungen sowie f\u00fcr \u00e4ltere Menschen verbessert werden.[2]<\/a>.<\/p>\n Um zu verstehen, welche Implikationen das BFSG f\u00fcr Unternehmen hat, m\u00fcssen wir einen kurzen, rechtlichen Exkurs machen. Achtung: Ich bin keine Juristin, daher sind die folgenden Informationen ohne Gew\u00e4hr ?<\/p>\n Das BFSG definiert Barrierefreiheitsanforderungen f\u00fcr bestimmte Produkte und Dienstleistungen, die nach dem Ablauf der Frist in Verkehr gebracht bzw. f\u00fcr Verbraucher*innen erbracht werden (welche Produkte und Unternehmen genau betroffen sind<\/a>, kann man in dieser \u00dcbersicht nachlesen). Bei Verst\u00f6\u00dfen gegen das BFSG kann die Markt\u00fcberwachungsbeh\u00f6rde anordnen, das Produkt oder die Dienstleistung zur\u00fcckzurufen bzw. einzustellen und Bu\u00dfgelder von bis zu 100.000 \u20ac verh\u00e4ngen[3]<\/a>.<\/p>\n Die Anforderungen an die Barrierefreiheit sind in der Verordnung zum BFSG (BFSGV) geregelt. In vielen Artikeln wird im Kontext der BFSGV auf die europ\u00e4ische Norm EN 301 549 verwiesen. Diese wiederum bezieht sich auf die AA-Standards der Web Content Accessibility-Guidelines 2.1 (WCAG 2.1)[4]<\/a>.<\/p>\n Zusammengefasst hei\u00dft das: Bestimmte Produkte und Dienstleistungen m\u00fcssen ab dem 28.06.2025 die Konformit\u00e4tsstufe AA der WCAG 2.1 erf\u00fcllen. Aber was sind \u00fcberhaupt die WCAG? Und was bedeutet Konformit\u00e4tsstufe AA?<\/p>\n Die Web Content Accessibility Guidelines (WCAG) sind ein internationaler Standard f\u00fcr die barrierefreie Gestaltung von Webinhalten des World Wide Web Consortium (W3C)[5]<\/a>. Obwohl mittlerweile die im Oktober 2023 aktualisierte Version 2.2 vorliegt, bezieht sich die EN 301 549 derzeit noch auf die Vorg\u00e4ngerversion 2.1 (Stand November 2024).<\/p>\n Die WCAG gliedern sich in die vier Prinzipien Wahrnehmbarkeit, Benutzbarkeit, Verst\u00e4ndlichkeit und Robustheit. Wie genau diese Prinzipien eingehalten werden k\u00f6nnen, ergibt sich aus einer Reihe von Erfolgskriterien, die den einzelnen Prinzipien zugeordnet sind[6]<\/a>.<\/p>\n Quelle: WCAG-2.2-Karte von Intopia https:\/\/intopia.digital\/wp-content\/uploads\/2024\/05\/German-WCAG-2.2-Map.pdf<\/a><\/p>\n Die Erfolgskriterien sind in verschiedene Priorit\u00e4tsstufen eingeteilt \u2013 Stufe A (h\u00f6chste Priorit\u00e4t), AA und AAA (niedrigste Priorit\u00e4t). Um die Konformit\u00e4tsstufe AA zu erreichen, m\u00fcssen alle Erfolgskriterien der Priorit\u00e4tsstufen A und AA erf\u00fcllt sein. Eine genaue Erl\u00e4uterung der einzelnen Erfolgskriterien und deren Einhaltung findet man auf der Website des W3C[7]<\/a>. Wer noch mehr Grundlagen zur Barrierefreiheit im UX Design lesen m\u00f6chte, dem empfehle ich den Blogbeitrag meiner Kollegin Catharina: UX Accessibility & Barrierefreiheit 101<\/a><\/p>\n Nun k\u00f6nnte man denken: \u201eAlles klar, wir erstellen eine Checkliste aller A- und AA-Erfolgskriterien der WCAG 2.1, haken alles ab und dann ist unser Produkt barrierefrei!\u201c<\/p>\n 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\u00fcllen. Trotzdem garantiert dieser Ansatz nicht die vollst\u00e4ndige Barrierefreiheit eines Produktes.<\/p>\n 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\u00fccksichtigt.<\/p>\n UX Research kann Barrierefreiheitsprobleme aufdecken, die von den WCAG nicht ber\u00fccksichtigt werden. Beispielsweise ist es m\u00f6glich, dass bestimmte Barrierefreiheitsprobleme bei bestimmten Nutzergruppen h\u00e4ufiger oder seltener auftreten als in der Gesamtpopulation. Das W3C selbst empfiehlt neben der Einhaltung der WCAG-Erfolgskriterien auch die Durchf\u00fchrung von UX Research mit Menschen mit Behinderungen.[8]<\/a>.<\/p>\n Ein Beispiel daf\u00fcr, wie UX Research zus\u00e4tzliche Barrierefreiheitsprobleme aufdecken kann, stammt von James Buller, der als UX Researcher f\u00fcr das britische Innenministerium arbeitet. Sein Team und er haben Usability Tests durchgef\u00fchrt, um herauszufinden, wie Nutzende beim Beantragen eines Reisepasses vorgehen[9]<\/a>. In einer Sitzung mit einer geh\u00f6rlosen 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\u00f6chte, da sie geh\u00f6rlos ist. Das Eingabefeld f\u00fcr die Telefonnummer lie\u00df jedoch nur die Eingabe von Zahlen zu, so dass sie ihren Hinweis nicht hinzuf\u00fcgen konnte. Das Formular war zwar WCAG-konform, aber nicht barrierefrei, da es diese Option nicht enthielt.<\/p>\n 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]<\/a>. Dabei orientieren wir uns unter anderem an den Bed\u00fcrfnissen (User Needs) und Anforderungen (User Requirements) der Nutzenden.<\/p>\n Dazu geh\u00f6ren auch Access Needs. Access Needs bezeichnen im Kontext von menschzentrierter Gestaltung alle Voraussetzungen, die erf\u00fcllt sein m\u00fcssen, damit ein*e Nutzer*in ein Produkt erfolgreich nutzen kann. Access Needs sind User Needs!<\/p>\n Das Thema Barrierefreiheit sollte also in jedem Schritt des menschzentrierten Gestaltungsprozesses, d.h. auch im UX Research, mitber\u00fccksichtigt werden. Im Folgenden werden einige Impulse f\u00fcr eine st\u00e4rkere Verankerung von Barrierefreiheit im UX Research vorgestellt.<\/p>\n Im Idealfall sollte bei jedem Research-Vorhaben einen Anteil der Sessions mit Teilnehmenden durchgef\u00fchrt werden, die der Nutzergruppe entsprechen, eine Behinderung haben und ggf. auch assistive Technologien nutzen. Wenn in einem Projekt regelm\u00e4\u00dfig UX Research durchgef\u00fchrt wird und darauf geachtet wird, dass immer ein gewisser Anteil von Teilnehmenden mit unterschiedlichen Behinderungen einbezogen wird, erh\u00f6ht sich die Wahrscheinlichkeit, im Laufe der Zeit alle relevanten Barrierefreiheitsprobleme aufzudecken.<\/p>\n Wenn wir UX Research mit Menschen mit Behinderung durchf\u00fchren, ist es wichtig, auch den Research-Prozess barrierefrei zu gestalten. Grunds\u00e4tzlich sollte UX Research nat\u00fcrlich m\u00f6glichst immer nutzerzentriert und bed\u00fcrfnisorientiert 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\u00f6glichkeit, so effektiv mitzumachen wie Teilnehmer*innen ohne Behinderung. Aus diesem Grund m\u00fcssen wir im Vorhinein identifizieren, welche Access Needs unsere Teilnehmenden an den UX Research haben.<\/p>\n Je nach Zielgruppe und Behinderung m\u00fcssen wir uns unterschiedliche Fragen stellen, z. B: Soll der Test im B\u00fcro, bei den Teilnehmenden zu Hause oder remote durchgef\u00fchrt werden? Ist der Prototyp, mit dem der Usability-Test durchgef\u00fchrt wird, f\u00fcr alle zug\u00e4nglich? Kann der Fragebogen mit Keyboard-Only Navigation oder mit einem Screenreader ausgef\u00fcllt werden?<\/p>\n Ein Fallbeispiel f\u00fcr barrierefreien UX Research ist das vom BMBF gef\u00f6rderte Projekt MightyU<\/a>. Ziel des Projekts war die Entwicklung eines Serious Games, mit dem Kinder mit infantiler Zerebralparese (ICP) ihre Therapie\u00fcbungen spielerisch und selbstwirksam zu Hause durchf\u00fchren k\u00f6nnen. In diesem Projekt mussten einigen Herausforderungen beim Research beachtet werden: Die Kinder und Eltern sind durch die Krankheit h\u00e4ufig zeitlich und mental stark belastet. Zudem ist die Auspr\u00e4gung der Erkrankung von Person zu Person sehr unterschiedlich. Die Testungen wurden bei den Kindern zuhause durchgef\u00fchrt, um den Nutzungskontext kennenzulernen und m\u00f6glichst wenig Zeit der Kinder und Eltern zu beanspruchen. Dar\u00fcber hinaus war bei der Planung des UX Research der Vater eines betroffenen Kindes im Konsortium, um Ideen einzubringen und zu bewerten.<\/p>\n Es gilt also, sich vor dem Research die richtigen Fragen zu stellen, sich zu informieren und ggf. kreativ zu werden. So k\u00f6nnen sich Teilnehmende mit und ohne Behinderung gut einbringen und wir erhalten spannende und verl\u00e4ssliche Erkenntnisse.<\/p>\n Eine Persona ist eine fiktive Beschreibung eines typischen Nutzers bzw. einer typischen Nutzerin. Personas helfen dem Team dabei, mehr Empathie gegen\u00fcber den verschiedenen Nutzergruppen zu empfinden und somit w\u00e4hrend des gesamten Projektverlaufs nutzerzentrierte Entscheidungen zu treffen[11]<\/a>.<\/p>\n Allen Leser*innen, die schon mal an der Entwicklung von Personas beteiligt waren, m\u00f6chte 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\u00f6nnen, beeinflusst hat? Aus meiner Erfahrung w\u00fcrde ich vermuten, dass die \u00fcberwiegende Mehrheit der Personas keine Behinderung hatte.<\/p>\n Um Barrierefreiheit so fr\u00fch wie m\u00f6glich zu ber\u00fccksichtigen, sollte man verschiedene Personas mit unterschiedlichen Behinderungen entwickeln, die verschiedene Arten assistiver Technologien nutzen.<\/p>\n 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\u00fccksichtigt.<\/p>\n Man sollte sich auch bewusst machen, dass die Persona niemals eine ganze soziale Gruppe (z.B. alle Menschen mit motorischen Behinderungen) repr\u00e4sentieren kann und sollte. Dies birgt die Gefahr der \u00dcbergeneralisierung.<\/p>\n Last, but certainly not least: Personas sollten durch die Durchf\u00fchrung von UX Research kontinuierlich validiert, korrigiert und erg\u00e4nzt werden. Personas, die nur auf den Annahmen des Teams basieren, werden auch Protopersonas genannt[12]<\/a> und bergen die Gefahr, dass Entscheidungen im Designprozess auf Basis (m\u00f6glicherweise) falscher Annahmen getroffen werden.<\/p>\n 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\u00f6nnen die User Needs und die Art und Weise, mit dem Produkt zu interagieren, beeinflussen \u2013 z.B. Alter, Bildungsstand, Geschlecht, Technologieerfahrung und Pers\u00f6nlichkeit. Man kann die ausgearbeitete Protopersona daf\u00fcr nutzen, die richtigen Screening-Kriterien f\u00fcr die Rekrutierung der Teilnehmenden zu definieren.<\/p>\n L\u00e9onie Watson hat dies gut mit folgendem Beispiel zusammengefasst[13]<\/a>:<\/p>\n \u201eWenn man eine App f\u00fcr M\u00e4dchen im Teenageralter entwickelt, macht es keinen Sinn, einen vierzigj\u00e4hrigen Mann zu bitten, die App zu testen, nur weil er zuf\u00e4llig einen Screenreader benutzt. Genauso wie seine Einstellung und seine F\u00e4higkeiten im Allgemeinen anders sind, wird auch seine F\u00e4higkeit, assistive Technologien zu nutzen, anders sein als bei jemandem, der 25 Jahre j\u00fcnger ist.\u201c<\/em><\/p><\/blockquote>\n L\u00e9onie Watson, Mitglied des W3C-Board of Directors<\/strong><\/p>\n <\/p>\n Eine tolle Ressource, an der man sich orientieren kann, wenn man zum ersten Mal Personas mit Behinderungen entwickelt sind die Personas f\u00fcr Barrierefreiheit<\/a> der \u00dcberwachungsstelle des Bundes f\u00fcr 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\u00fcr die Entwicklung von eigenen Personas einsetzen. Man kann auch dar\u00fcber nachdenken, AI-Tools bei der Entwicklung der Personas einzusetzen. Wer \u00fcber dieses spannende Thema mehr erfahren m\u00f6chte, dem sei Thomas\u2018 Blogartikel \u00fcber KI-Personas<\/a> nahegelegt.<\/p>\n \u201eBarrierefreiheit ist f\u00fcr einige essenziell und f\u00fcr alle n\u00fctzlich.\u201c<\/em><\/p><\/blockquote>\n <\/p>\n <\/p>\n <\/p>\n Shawn Lawton Henry, W3C Web Accessibility Initiative (WAI) Program Lead[14]<\/a><\/strong><\/p>\n <\/p>\n Abschlie\u00dfend noch ein Argument daf\u00fcr, warum sich alle UX Professionals mit Barrierefreiheit besch\u00e4ftigen sollten. Das prim\u00e4re Ziel von digitaler Barrierefreiheit ist es, digitale Inhalte und Technologien f\u00fcr Menschen mit Behinderung zug\u00e4nglich zu machen. Nat\u00fcrlich 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\u00e4ngt[15]<\/a>. Wir alle profitieren von digitaler Barrierefreiheit, wenn wir tempor\u00e4r (z.B. durch einen gebrochenen Arm) oder situational eingeschr\u00e4nkt 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 \u00c4lterwerden.<\/p>\n Quelle: Microsoft Inclusive Design https:\/\/inclusive.microsoft.design\/tools-and-activities\/Inclusive101Guidebook.pdf<\/a><\/p><\/div>\n Bei der Umsetzung von digitaler Barrierefreiheit ist WCAG-Compliance nicht alles. Es lohnt sich, \u00fcber die Einhaltung der WCAG hinaus UX Research mit Fokus auf Barrierefreiheit durchzuf\u00fchren. Dabei sollte man darauf achten, dass der UX Research zug\u00e4nglich f\u00fcr alle Teilnehmenden ist. So baut man Schritt f\u00fcr Schritt Barrieren in seinen digitalen Produkten ab – und vergr\u00f6\u00dfert ganz nebenbei seine potenzielle Nutzerbasis.<\/p>\n Wenn du mehr zu diesem Thema erfahren m\u00f6chtest: Bald erscheint unser neuer Podcast 2025: Odysee Accessibility<\/a>, indem es um Accessibility und AI geht.<\/p>\nDie Web Content Accessibility Guidelines (WCAG)<\/h2>\n
![\"WCAG](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/wacag22.png\")
<\/a><\/p>\nWCAG-Konformit\u00e4t ist nicht alles<\/h2>\n
UX Research f\u00fcr alle! \u2013 Ideen f\u00fcr mehr Inklusion und Barrierefreiheit<\/h2>\n
Inklusive Personas<\/h2>\n
![\"Portr\u00e4t-Aufnahme](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/leonie.watson-1-300x300.jpg\")
<\/p>\nFazit<\/h2>\n
![\"Portr\u00e4t-Aufnahme](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/shawn.lawton.henry-1.jpg\")
<\/p>\n![\"Eine](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Microdoft-Inclusive-Design-Tool-2-1081x1024.png\")
Du m\u00f6chtest die Barrierefreiheit deines Produkts verbessern<\/span>?<\/h2>\n