Barrierefreie
Komponenten
Wie moderne UI-Toolchains Accessibility angehen – und warum wir in Europa auch bei der Barrierefreiheit eigene Wege gehen müssen, um barrierefreie Websites und Apps für alle verfügbar und realisierbar zu machen.
Es gibt großartige Tools da draußen – von Radix bis Shadcn. Sie zeigen, was technisch möglich ist. Und in Projekten mit eigenem Frontend-Server, mit Headless-CMS, mit Vercel und Next.js nutzen auch wir diese Werkzeuge.
Aber: Die meisten Projekte in Deutschland und Europa sehen anders aus. Headless SaaS ist teuer – vor allem, wenn Datenschutz ernst genommen wird. Vercel? US-Unternehmen. Amazon? DSGVO nur mit Aufwand. WorkOS? Grandios, aber nicht konform.
Wir können all das bauen – DSGVO-konform. Mit Next.js auf eigenen Servern. Mit Strapi als Headless-CMS. Mit sinnvollen Setups, die europäischen Datenschutz nicht umgehen – sondern erfüllen.
Aber die Realität ist: Die meisten Webprojekte hierzulande haben andere Voraussetzungen – kleinere Budgets, bestehende Systeme wie WordPress, Typo3 oder Wagtail. Und dort gibt es keine drop-in Lösungen für echte Accessibility. Genau das treibt uns an.
Genau deshalb entwickeln wir via11y: UI-Komponenten, die barrierefrei sind – ohne Build-Prozess, ohne React-Teams, ohne Vendor-Lock-in.
Komponenten im Vergleich
Der Vergleich der Dialog-Komponente zeigt beispielhaft worauf wir bei der Erstellung von via11y Komponenten achten, was sie im Vergleich zu bewährten React-Komponenten ausmacht und für wen sie gut ist.
Dialog – via11y (Vanilla JS + Tailwind)
Dieser Dialog ist Teil von via11y – unserer barrierefreien UI-Bibliothek für moderne, framework-unabhängige Webprojekte. Er basiert vollständig auf den WAI-ARIA Empfehlungen und erfüllt alle wesentlichen Anforderungen: Sichtbarkeit, Tastaturführung, Escape-Verhalten, Fokussteuerung und semantische Rollen.
Anders als viele React-basierte Lösungen lässt sich via11y direkt in bestehende Systeme integrieren – ob WordPress, TYPO3 oder statisches HTML. Selbst in modernen htmx- oder Astro-Projekten funktioniert der Dialog reibungslos, ohne Build-Step oder Abhängigkeiten.
- Keine Abhängigkeiten, kein Build-Step
- Fokus-Handling, Escape, Click-out, `aria`
- Einsetzbar in WordPress, TYPO3, statischem HTML
Dialog – shadcn/ui (React + Radix)
Verglichen mit Radix UI – einem bewährten Standard für React-Projekte. Technisch stark, aber nur nutzbar mit Build-Prozess und modernem Framework-Setup.
- Hohe A11y-Standards, ausgereifte Architektur
- Sehr gute Tastaturbedienung und Fokus-Management
- Frameworkabhängig: React + Vite + npm zwingend
- Nicht drop-in-fähig für klassische Systeme oder reine HTML-Umgebungen
- Eingeschränkte Robustheit bei dynamischer DOM-Injektion (Portals)
A11Y-Komponenten
Bald auch als interaktive, barrierefreie via11y-Komponenten
Accessible Tabs
Funktionen
- Automatische oder manuelle Aktivierung
- Volle Tastaturnavigation mit Pfeiltasten
- Responsives Verhalten, semantisch korrekt
Diese Tabs basieren auf Radix UI – sie unterstützen vollständige Tastaturnavigation, rollenbasiertes Markup und dynamische Sichtbarkeit. Ideal für strukturierte Inhalte oder Formulare.
- Rollen: `tab`, `tabpanel`, `tablist`
- Tastatur-Navigation mit Pfeiltasten
- Nur mit React + Build-Prozess nutzbar
Accessible Tables
| Name | Rolle | |
|---|---|---|
| Anna Maier | anna@example.org | Redaktion |
| Jonas Klein | jonas@barrierefrei.net | Frontend |
| Lea Kühn | lea@ngo-mail.de | UX Research |
* Basierend auf der shadcn/ui Table-Komponente – erweitert um
semantische A11y-Standards wie scope und caption.
Diese Tabelle ist semantisch korrekt aufgebaut und wird von Screenreadern zuverlässig interpretiert. Interaktive Inhalte sind mit der Tastatur erreichbar – z. B. Buttons oder Links in Zellen. Ideal für Admin-Interfaces, Übersichten oder Reports.
-
<table>,<thead>,<th scope="col">gesetzt - Fokus-State sichtbar für Tastaturnutzer
- Visuell klar strukturiert, auch bei vielen Daten
Warum also via11y?
React + Radix ist super – für Banken, Tech-Startups, Plattformen mit großem Budget. Doch die Realität vieler Webprojekte sieht anders aus:
- Next.js ist in Deutschland kaum verbreitet
- Pflicht-CMS in Behörden lassen kein Server-JS im Frontend zu
- Bildung, Vereine, Stiftungen: keine Buildpipeline, kein React-Team
- Projekte < 100k € brauchen Lösungen ohne Overhead
Gleichzeitig erreichen uns immer mehr Anfragen nach barrierefreien Websites für NGOs und mittelständische Unternehmen – ohne React, ohne aufwändiges Setup, aber mit hohen Ansprüchen an Usability und Teilhabe.
Accessible UI, die wirklich funktioniert.
Darum entsteht via11y: Eine wachsende Sammlung funktionaler, barrierefreier UI-Komponenten, die sich direkt in bestehende Systeme wie WordPress oder Django einbinden lassen – ganz ohne Build-Prozess.
Unser Ziel: via11y als Open-Source-Bibliothek zu veröffentlichen – zugänglich, wartbar, kompatibel mit echten Projekt-Realitäten. Getragen von Menschen, Organisationen und Kommunen, die Accessibility nicht nur als Pflicht sehen, sondern als Teil echter digitaler Teilhabe. Wenn sich genügend Engagierte zusammentun, machen wir das möglich.
Übrigens: Wenn Sie ein barrierefreies Webprojekt umsetzen möchten – oder prüfen wollen, ob eine Beteiligung an einem Open-Source-Ansatz wie via11y für Sie sinnvoll wäre – schreiben Sie uns einfach.
Lust auf ein Gespräch?
Wir freuen uns über ernst gemeinte Anfragen – egal ob für konkrete Projekte oder zur Weiterentwicklung von via11y.