Barrierefreiheit#

Das Theme bringt Barrierefreiheit durch drei Schichten: shadcn/ui-Komponenten (basierend auf Radix UI) liefern tastatur- und screenreader-konforme UI-Primitiven; KERN-UX-Komponenten ergänzen korrekte ARIA-Attribute; das Theme selbst stellt semantisches HTML, Skip-Navigation und Sprachversionen bereit. Für korrekte Inhaltsstruktur — insbesondere Überschriftenhierarchien — sind die Autor:innen verantwortlich.

Eingebaute Maßnahmen#

Semantisches HTML#

Das Theme rendert Markdown-Inhalte als semantisch korrektes HTML:

• Listen verwenden <ul>, <ol>, <li>
• Tabellen verwenden <table>, <thead>, <tbody>, <th>, <td>
• Zitate werden als <blockquote> gerendert
• Code-Blöcke verwenden <pre> und <code>

ARIA-Attribute#

ARIA (Accessible Rich Internet Applications) ist ein W3C-Standard, der HTML um Zusatzinformationen für Screenreader ergänzt. Screenreader lesen sichtbaren Text vor — aber Icon-Buttons, Ladeanimationen oder dynamisch aktualisierte Bereiche haben oft keinen sichtbaren Text. ARIA-Attribute füllen diese Lücke:

• aria-label gibt einem Element eine Bezeichnung, die nur Screenreader vorlesen — z. B. „Menü öffnen" an einem Icon-Button ohne Beschriftung
• aria-describedby verknüpft ein Eingabefeld mit einem erklärenden Text, der zusätzlich zum Label vorgelesen wird
• aria-invalid signalisiert Screenreadern, dass ein Formularfeld einen Fehler enthält
• aria-live markiert Bereiche, deren Inhalt sich dynamisch ändert — Screenreader lesen Änderungen automatisch vor, ohne dass der Fokus dort sein muss
• aria-hidden blendet dekorative Elemente (z. B. Icons neben Beschriftungen) für Screenreader aus, damit sie nicht doppelt vorgelesen werden

KERN-UX-Komponenten setzen diese Attribute konsistent:

• Formularfelder: aria-describedby für Hinweis- und Fehlertexte, aria-invalid bei Validierungsfehlern
• Feedback-Formular: aria-busy und aria-label am Submit-Button, aria-live="polite" für Statusmeldungen
• Navigation: aria-label an Menü-Toggle, Breadcrumb, Suche, Theme- und Sprachumschalter
• Code-Blöcke: aria-label am Kopieren-Button

Tastaturnavigation und Radix UI#

shadcn/ui baut auf Radix UI auf, das die offiziellen WAI-ARIA Design Patterns implementiert. ARIA-Rollen, Zustände und Tastaturmuster werden automatisch korrekt gesetzt — ohne manuellen Aufwand. Konkret:

Zusätzlich ist die Suche über Tastaturkürzel aufrufbar (Cmd/Ctrl+K, /).

Screenreader-Unterstützung#

• Icon-Buttons enthalten versteckte Beschriftungen (sr-only-Klasse)
• Ladezustände werden als Screenreader-Text ausgegeben
• Dynamische Inhalte (Feedback-Erfolgsmeldung, Suchergebnisse) nutzen aria-live-Regionen

Sprachversionen#

Die Theme-Konfiguration unterstützt Links zu:

• Leichte Sprache (accessibilityLanguages.leichteSpracheHref)
• Gebärdensprache (accessibilityLanguages.gebaerdenSprachenHref)

Diese Links erscheinen in der Navigation und ermöglichen den Zugang zu barrierefreien Alternativversionen.

WCAG-Konformität#

Das Theme zielt auf WCAG 2.1 Level AA-Konformität. Barrierefreiheit lässt sich auf zwei Wegen prüfen:

Automatisiert — Die optionale CI-Komponente accessibility-checker führt pa11y-ci nach dem Build aus. pa11y lädt die fertigen HTML-Seiten im Headless-Browser, analysiert den DOM und meldet Verstöße gegen WCAG 2.1 AA als SARIF-Report in der Pipeline. Damit lassen sich maschinell prüfbare Kriterien zuverlässig abdecken: fehlende Alt-Texte, unzureichende Farbkontraste, fehlende Formular-Labels oder falsch genutzte ARIA-Attribute. Wie du die Komponente einbindest, beschreibt Barrierefreiheitsprüfung einrichten.

Manuell — Rund 30 % der WCAG-Kriterien sind nicht automatisch prüfbar: ob ein Alt-Text den Bildinhalt tatsächlich beschreibt, ob die Tastaturnavigation einer Seite sinnvoll geordnet ist oder ob Texte inhaltlich verständlich sind. Diese Aspekte erfordern Tests mit echten Screenreadern (z. B. NVDA, VoiceOver).

Verantwortung der Autor:innen#

Das Theme stellt die technische Grundlage bereit. Die folgenden Aspekte liegen in der Verantwortung der Autor:innen: