Barrierefreiheit – Ein wesentlicher Bestandteil des Rezepts oder das Sahnehäubchen als "Tüpfelchen auf dem i"?

Bei Peerigon ist Barrierefreiheit im Web kein „nettes Extra“, sondern ein fester Bestandteil, um inklusive und funktionale digitale Produkte zu schaffen. Ab Mitte 2025 müssen Websites und Webapplikationen in Deutschland dem Barrierefreiheitsstärkungsgesetz (BFSG) entsprechen. Dieses Gesetz, das in der gesamten EU durch die Europäische Richtlinie zur Barrierefreiheit (EAA) eingeführt wird, legt Standards für barrierefreies Design fest. Die zugrunde liegenden Vorschriften orientieren sich eng an den Web Content Accessibility Guidelines (WCAG) und stellen sicher, dass digitale Dienste für alle zugänglich sind.

Das Update unserer eigenen Abstimmungsapp Konsens hat uns gezeigt, wie wichtig Barrierefreiheit in jeder Entwicklungsphase ist. In diesem Beitrag nehmen wir Sie mit auf unsere Reise, teilen die Erkenntnisse, die wir gewonnen haben, und erklären, warum Barrierefreiheit im Web nicht „nur eine Aufgabe vor dem Release“ ist, sondern ein fortlaufender Prozess.

Konsens begann als internes Projekt bei Peerigon während einer Software-Ausbildung. Die ursprüngliche Version der App wurde mit Vue 2, einem der meist genutzten JavaScript-Frameworks, entwickelt und diente dem Lernen, Experimentieren und dem Austausch von Wissen im Team. Von Anfang an wurde Barrierefreiheit berücksichtigt, zum Beispiel durch ein Tortendiagramm, das Farben und Muster kombiniert, um die Ergebnisse besser lesbar zu machen. Der Schwerpunkt lag jedoch zunächst auf der Funktionalität und weniger darauf, sämtliche Barrierefreiheitsstandards zu erfüllen.

Diese Phase lehrte uns, dass selbst wenn Barrierefreiheit von Anfang an Teil des Designs ist, sie im Laufe der Entwicklung kontinuierliche Aufmerksamkeit erfordert. Barrierefreiheit ist ein ebenso wichtiger Faktor in der Entwicklung von Web-Apps wie Performance, Benutzerfreundlichkeit und Sicherheit – all diese Aspekte müssen zusammenkommen, um ein erfolgreiches Produkt zu schaffen.

Als es an der Zeit war, Konsens von Vue 2 auf Vue 3 zu migrieren, erweiterte sich der Umfang des Projekts schnell. Es ging nicht nur um die Aktualisierung des Frameworks – wir gestalteten die App umfassend neu, um sie moderner aussehen zu lassen und neue Funktionen hinzuzufügen. Dabei ergaben sich wichtige Anforderungen:

• Migration zu Vue 3 mit TypeScript
• eine frische, moderne Gestaltung, die sich an der mobilen App orientiert
• Verbesserungen der Barrierefreiheit für mobile und Desktop-Nutzer

Früh entschieden wir uns, die „Composition API“ in Vue 3 zu verwenden und Headless UI sowie Tailwind CSS für das Komponentendesign zu nutzen. Storybook wurde unerlässlich, um die Barrierefreiheit und das visuelle Erscheinungsbild zu testen. In dieser Phase blieb die Barrierefreiheit ein Schwerpunkt, und wir stellten sicher, dass wir Entscheidungen zur Verbesserung dieser in enger Zusammenarbeit mit dem Designteam trafen.

Ein weiterer Schritt war die Auswahl einer geeigneten UI-Komponentenbibliothek. Für unsere React-basierten Projekte haben wir bislang Chakra UI genutzt. Doch es war schwierig, eine ähnlich vollständig anpassbare und barrierefreie UI-Bibliothek zu finden, die mit Vue 3 kompatibel war.¹ Daher verfolgten wir einen pragmatischen Ansatz: Wir konzentrierten uns auf die wesentlichen Aspekte der Barrierefreiheit, indem wir grundlegende Webstandards berücksichtigten und Headless UI als Basis für komplexere Komponenten nutzten.

Wenn es um Barrierefreiheit in unserer schnelllebigen Zeit geht, gilt: Praktische Entscheidungen mit dem bestmöglichen Ergebnis sind oft die beste Wahl. Für uns bedeutete dies die Entscheidung für Headless UI.

Mit dem Fortschreiten des Projekts veränderte sich die Teamzusammensetzung, und der Fokus lag zunehmend auf der Fertigstellung des neuen Designs und der Implementierung aller Funktionen. Einige Aufgaben zur Barrierefreiheit wurden daher bis kurz vor dem Release zurückgestellt, während andere bewusst nach dem Release eingeplant wurden. Diese Entscheidung führte jedoch zu Herausforderungen, die mit einem proaktiveren Ansatz möglicherweise hätten vermieden werden können.

Zum Beispiel wurden wiederholt auftretende Farbkontrastprobleme vor dem Release behoben, was zeitintensive Nachbesserungen in verschiedenen Bereichen der Anwendung erforderlich machte. Gleichzeitig entschieden wir, bestimmte bekannte Barrierefreiheitsprobleme – wie eine UI-Komponente, die noch nicht den Standards entsprach – für eine spätere Iteration einzuplanen. Diese bewusste Priorisierung ermöglichte es uns, den Release zu erreichen, ohne das Ziel einer langfristigen Verbesserung der Barrierefreiheit aus den Augen zu verlieren. Die noch offenen Themen wurden in der Barrierefreiheitserklärung transparent dokumentiert.

Solche Situationen sind im Bereich der Web Entwicklung häufig – wenn sich Teammitglieder und Prioritäten ändern, kann es leicht passieren, dass Barrierefreiheit aus dem Fokus gerät. Es ist wichtig, in diesen Phasen nicht den Mut zu verlieren oder das Ziel der Barrierefreiheit aus den Augen zu verlieren. Schauen wir uns im Folgenden an, wie wir unsere Anstrengungen wieder auf das Ziel konzentrierten.

Nach der Implementierung der Hauptfunktionen lag unser Fokus wieder darauf, die Barrierefreiheit der Anwendung sicherzustellen. Als ich nach Abschluss eines Kundenprojekts zurück zum Team stieß, führten wir umfassende Audits zur Barrierefreiheit auf manueller und automatisierter Ebene durch.

Wir testeten die Anwendung auf verschiedenen Plattformen (macOS, Windows) und in Browsern wie Chrome, Firefox und Safari. Dazu gehörten Tests zur reinen Tastaturnavigation und Screenreader wie VoiceOver und NVDA, um sicherzustellen, dass die App auch für Nutzer mit unterstützenden Technologien zugänglich ist.

Zusätzlich integrierten wir End-to-End-Tests mit den Tools Playwright und Axe, um die Barrierefreiheit der Webapplikation durchgängig zu testen und sicherzustellen, dass die Standards eingehalten werden, auch wenn sich die App weiterentwickelt.

Kurz vor der Veröffentlichung von Konsens verfolgten wir einen pragmatischen Ansatz und konzentrierten uns auf die Behebung der kritischsten Probleme. Das stellte sicher, dass die Kernfunktionen einer breiten Nutzergruppe zugänglich waren. Dennoch erkannten wir, dass Barrierefreiheit nicht durch einmalige Anstrengungen vollständig erreicht werden kann. Da sich die App weiterentwickelt, bleiben fortlaufende Bemühungen zur Verbesserung der Barrierefreiheit unerlässlich.

Um dieses Engagement zu kommunizieren, haben wir eine Barrierefreiheitserklärung in die Webanwendung integriert. Diese Erklärung bietet Transparenz über den aktuellen Stand der Barrierefreiheit, beschreibt bekannte Einschränkungen und informiert die Nutzer darüber, dass Barrierefreiheit weiterhin eine Priorität bleibt. Außerdem haben Sie als Nutzer die Möglichkeit, Feedback zu geben, damit wir die Barrierefreiheit im Fokus behalten, während die App weiterentwickelt wird.

Unsere Erfahrungen mit Konsens haben einige wichtige Erkenntnisse zur Barrierefreiheit in der Entwicklung verdeutlicht:

• Barrierefreiheit ist ein fortlaufender Prozess Barrierefreiheit im Web ist kein Punkt, den man auf einer Liste abhaken kann. Sie erfordert kontinuierliche Bewertung und Updates. Neue Funktionen und Designänderungen können neue Barrierefreiheitsprobleme einführen.

• Barrierefreiheit im Nachhinein ist kostspielig Es ist weitaus kostspieliger, Barrierefreiheitsprobleme nach Abschluss des Entwicklungsprozesses zu beheben. Wenn Barrierefreiheit von Anfang an integriert wird, spart das später Aufwand und vermeidet teure Überarbeitungen. Dies ist bei funktionalen Bugs allgemein bekannt, wird bei Barrierefreiheit jedoch oft vernachlässigt.

• Wissenssilos als Herausforderung Das Wissen zur Barrierefreiheit war auf einige Teammitglieder konzentriert, was die Konsistenz erschwerte. Dies ist ein häufiges Problem in Entwicklungsteams, das wir durch bessere Schulung und Wissensaustausch angehen wollen.

• Automatisierung allein reicht nicht aus Automatisierte Testwerkzeuge helfen, offensichtliche Probleme zu erkennen, aber decken nicht alles ab. Eine manuelle Überprüfung ist oft erforderlich, um komplexe Benutzerflüsse zu bewerten, die möglicherweise nuancierte Barrierefreiheitsprobleme aufweisen.

Bei Peerigon nehmen wir diese Erkenntnisse ernst. Für zukünftige Projekte verpflichten wir uns:

• Barrierefreiheitschecks in jeder Entwicklungsphase zu integrieren und nicht erst am Ende.
• Wissen im Team zu teilen, sodass Barrierefreiheit nicht nur von einigen Spezialist abhängt.
• Sicherzustellen, dass Barrierefreiheit ein zentraler Bestandteil der Projektplanung ist und nicht nur ein Punkt auf der Roadmap.

Als visueller Denker und begeisterter Hobby-Bäcker resonierte das Bild zur Barrierefreiheit in Form der „Blaubeermuffin-Analogie“, die Marcy Sutton in einem ihrer Blogbeiträge verwendet, sehr.

Der Gedanke dahinter ist, dass Blaubeeren in den Teig gemischt werden sollten und nicht später hineingesteckt werden. Genauso sollte Barrierefreiheit von Anfang an Teil der Entwicklung sein und nicht erst später hinzugefügt werden. ³

Dieses Bild ist für uns mehr als Theorie. Einige unserer Kollegen profitieren direkt von Barrierefreiheit. Sei es wegen einer Farbenblindheit oder kognitiven Herausforderungen durch chronische Krankheiten oder Neurodivergenz. Barrierefreies Design macht das tägliche Leben einfacher – und das nicht nur für einige, sondern für alle.

Konsens zeigt die Herausforderungen und Vorteile auf, wenn Barrierefreiheit zur Kernpriorität wird. Am Ende geht es darum, bessere, inklusivere digitale Erfahrungen zu schaffen – denn Barrierefreiheit kommt nicht nur denen, die darauf angewiesen sind zugute. Alle profitieren von ihr.

Wenn Sie mehr über unseren Ansatz zur Barrierefreiheit erfahren möchten oder Interesse haben, wie wir Ihre Projekte unterstützen können, nehmen Sie gerne Kontakt mit uns auf. Bei Peerigon freuen wir uns immer auf spannende Gespräche!

Fußnoten

1 | Seitdem hat das Team um Chakra UI eine weitere Bibliothek namens Ark UI veröffentlich, die React, Svelte und Vue kompatibel ist.

2 | JavaScript and Civil Rights | Article by Marcy Sutton

3 | Baking Accessibility In | Talk by Cordelia McGee-Tubb

Coverbild basierend auf dem Blaubeermuffinfoto von Aneta Voborilova auf Unsplash

Photo von Blaubeermuffins auf einem Auskühlgitter von Aneta Voborilova auf Unsplash