Blog
Gut sortiert: Unsere Bibliothek für Barrierefreiheit
Bibliotheken sind Wissensspeicher. Das ist in unserer digitalen Zeit auch nicht anders als in der Antike oder im Mittelalter. Auch in der Softwareentwicklung wollen wir das Rad nicht ständig neu erfinden – sondern greifen auf Sammlungen zurück, in denen wichtige und wiederkehrende Komponenten gespeichert sind. Wenn es für das Thema, das wir umsetzen, noch keine solche Bibliothek gibt, dann legen wir sie uns auf Basis bestehender Teilbibliotheken selbst an.
Ein solcher Fall ist das Thema Barrierefreiheit, die seit Beginn des laufenden Kalenderjahres auch im digitalen Raum rechtlich verpflichtend ist.
Dafür haben wir eine UI-Komponentenbibliothek entwickelt, die wir zurzeit für zwei verschiedene Kunden nutzen. Sie liefert die gewünschten Komponenten sowohl im Dark Mode als auch im Light Mode aus.
Doch das Wichtigste: Die Bibliothek entspricht vollumfänglich den Anforderungen der Barrierefreiheit. So haben wir alle Komponenten WCAG-konform umgesetzt. Denn die deutschen und EU-Regelungen verlangen, dass Websites und Apps mit Hilfstechnologien lesbar sind und bei Interaktionen und Kontrasten den WCAG-Standards entsprechen. Für uns heißt das: Jede Komponente muss für alle Nutzenden zugänglich, also für Screenreader korrekt und vollständig ausgezeichnet und komplett per Tastatur steuerbar sein.
Eingesetzte Technologien
Als technische Basis fiel die Wahl auf solche Teilbibliotheken, die Barrierefreiheit und flexibles Theming direkt unterstützen. Mit react-aria-components (Teil der Adobe React-Spectrum-Bibliotheken) erhalten wir vorgefertigte Bausteine, die Accessibility-Standards (ARIA) bereits integriert haben. Sie bringen Semantik und Interaktionen für Screenreader und Tastatur von Haus aus mit, so dass wir sie nur noch optisch an unsere Designs anpassen müssen. Für das Styling nutzen wir styled-components, eine CSS-in-JS-Lösung, mit der wir CSS direkt in JavaScript schreiben können. Styled-Components kapseln die Stile pro Komponente und erzeugen eindeutige Klassen, wodurch unser Code modular und konfliktfrei bleibt. Außerdem unterstützen sie Themen (Themes): Über einen zentralen `ThemeProvider` tauschen wir Farben und Stile je nach Dark- oder Light-Theme aus. Durch diese dynamische Gestaltung werden unsere Komponenten flexibel und wiederverwendbar.
Zur Dokumentation und Entwicklung jeder einzelnen UI-Komponente setzen wir Storybook ein. Storybook ist wie ein eigenes Mini-Labor für unsere Komponenten: Entwickler:innen können jeden Button, jedes Formularfeld oder jede Navigation isoliert entwickeln und ausprobieren, ohne die ganze Anwendung laden zu müssen. Das hilft nicht nur bei der Umsetzung von Sonderfällen, sondern dient auch als lebendige Dokumentation.
In Storybook sieht man alle Varianten eines Bausteins sofort und kann sie in Echtzeit anpassen. Dank der integrierten Dokumentationsseite können wir neuen Teammitgliedern oder Designer:innen ganz einfach zeigen, wie jede Komponente aussieht und funktioniert. Änderungen sind auf diese Weise leicht nachzuvollziehen, und die Pflege der Komponentenbibliothek bleibt übersichtlich.
Tests und Tools
Auch für die Tests und das Entwicklungstooling kamen moderne Werkzeuge zum Einsatz. Zur automatischen Überprüfung der Barrierefreiheit haben wir das axe-core-Tool integriert (via `@axe-core/react`). Axe ist eine führende Open-Source-Engine für Zugänglichkeitstests, die unsere gerenderten Komponenten automatisch gegen die WCAG-Regeln durchprüft. Sobald wir die Anwendung laden, meldet Axe fehlende Kontraste, fehlende Alternativtexte oder andere Barrieren im Browser-Console-Log. So erwischen wir schnell einen Großteil der typischen WCAG-Verstöße und können sie direkt korrigieren.
Für die normalen Komponententests nutzen wir @testing-library/react. Im Gegensatz zu früheren Tools simuliert diese Bibliothek die Tests vor allem aus Sicht der Nutzenden: Sie greift auf das gerenderte DOM zu und sucht Elemente anhand von Text oder Beschriftungen, genau wie ein Mensch es tun würde. Dadurch schreiben wir Tests, die nicht an internen Details hängen, sondern wirklich überprüfen, dass Buttons, Formulare oder Links für die Nutzeenden funktionieren. Dieser nutzungszentrierte Ansatz erhöht die Zuverlässigkeit deutlich – wir erhalten Gewissheit, dass unsere Anwendung im realen Einsatz funktioniert und zugänglich ist.
Für das Build- und Test-Tooling setzen wir auf Vite und Vitest. Vite ist ein modernes Frontend-Build-Tool und ein Entwicklungsserver, der extrem schnell startet und kompiliert. Bei Vite entfällt oft langes Bundling, und dank Hot Module Replacement sehen wir Änderungen unmittelbar. Darauf abgestimmt ist Vitest, ein auf Vite basierendes Testframework. Vitest startet Tests sehr schnell und führt nur die betroffenen Prüfungen bei Codeänderungen erneut aus. Zusammen mit Vite ergibt das eine zeitgemäße, schlanke Entwicklungsumgebung, in der wir rasch entwickeln und testen können, ohne lange Wartezeiten.
Mittlerweile umfasst unsere Bibliothek rund 50 komplett gestylte UI-Komponenten, die für beide Kunden in Light- und Dark-Theme verfügbar und immer barrierefrei sind. Zum Beispiel sind Buttons, Formularfelder, Navigationselemente und vieles mehr so angelegt, dass sie sowohl optisch zum jeweiligen Markenauftritt passen als auch den strengen rechtlichen Zugänglichkeitskriterien genügen.
Fazit
Durch die Kombination von React Aria, Styled-Components, Storybook, automatisierten Accessibility-Checks und modernem Build-Tooling haben wir ein robustes System geschaffen, mit dem wir jederzeit neue Komponenten nach demselben Schema entwickeln können – schnell, übersichtlich und zugänglich.
