Seite 4 - Barrierefreiheit

text-wrap balance und text-wrap pretty lösen zwei unterschiedliche Probleme beim Zeilenumbruch: balance verteilt kurze Überschriften gleichmäßig auf alle Zeilen, pretty verhindert einzelne Wörter am Ende von Fließtext-Absätzen. Wer beide Werte gezielt statt austauschbar einsetzt, gewinnt spürbar sauberere Typografie ohne zusätzliches JavaScript.

Wer Barrierefreiheit nur als Checkliste abarbeitet, scheitert an jedem neuen Fall, der nicht exakt in der Liste steht. Die vier WCAG-Prinzipien Perceivable, Operable, Understandable und Robust liefern den Denkrahmen dahinter und helfen Entwicklern, unbekannte Accessibility-Probleme selbstständig einzuordnen und richtig zu lösen, statt blind Regeln zu befolgen.

Die color-contrast() Funktion aus CSS Color Level 5 lässt den Browser selbst entscheiden, welche von mehreren Textfarben zum jeweiligen Hintergrund den besten WCAG-Kontrast liefert. Das reduziert manuelle Kontrastberechnung und macht dynamisch generierte Hintergründe automatisch barrierefrei lesbar.

Hyvä Theme bringt durch sein schlankes, semantisches HTML-Fundament von Haus aus deutlich bessere Barrierefreiheit mit als klassische Luma-Themes, schließt aber nicht automatisch alle Lücken. Wer Alpine.js-Toggles ohne Fokus-Management einsetzt oder Icon-Buttons ohne zugängliche Namen auslässt, produziert echte WCAG-Verstöße. Dieser Artikel zeigt die Stärken, die häufigsten Fehler und eine praktische Checkliste für das erste Hyvä-Accessibility-Audit.

jest-axe bindet die Regel-Engine von axe-core direkt in Jest-Tests ein und prüft gerenderte React-Komponenten gegen anerkannte WCAG-Regeln. In der CI-Pipeline verhindert das, dass offensichtliche Barrierefreiheits-Verstöße unbemerkt in den Hauptzweig gelangen, ersetzt aber keine manuelle Prüfung.

Ein binärer Hell/Dunkel-Schalter deckt nur eine einzige Präferenz-Achse ab. Nutzer mit Sehschwäche, Bewegungssensibilität oder dem Wunsch nach mehr Übersicht auf kleinen Bildschirmen brauchen mehr Auswahl. Tailwind CSS Theme-Presets kombinieren Kontrast, Dichte und Bewegung zu benannten Profilen, die sich über Alpine.js auswählen und serverseitig persistieren lassen.

EN 301 549 ist in den meisten Diskussionen über digitale Barrierefreiheit der unsichtbare Unterbau: BFSG, European Accessibility Act und öffentliche Beschaffung verweisen alle auf diese Norm, ohne dass viele Projektbeteiligte je einen Blick in den eigentlichen Normtext geworfen haben. Wer nur WCAG kennt, kennt nur einen Teil davon.

ARIA überschreibt keine Optik und kein Verhalten, sondern ergänzt ausschließlich den Accessibility Tree um Rollen, Status und Eigenschaften, die Screenreader und andere assistive Technologien auswerten. Wer ARIA einsetzt, ohne die fünf Grundregeln zu kennen, baut oft unzugängliche statt zugängliche Interfaces. Dieser Beitrag zeigt anhand einer echten Tab-Komponente, wann ARIA wirklich nötig ist und wann ein natives HTML-Element die bessere Wahl bleibt.

Checkboxen, Radio-Buttons, Range-Slider und Progress-Bars tragen in jedem Browser eine andere Standardfarbe, meist irgendein Blau, das zur Markenfarbe passt oder eben nicht. Die CSS-Eigenschaft accent-color löst dieses Problem mit einer einzigen Zeile, ohne dass native Tastatursteuerung, Fokus-Ringe oder Screenreader-Semantik verloren gehen.

Die Auswahl der Zahlungsmethode ist ein eigenständiges Barrierefreiheitsthema, unabhängig vom restlichen Checkout-Formular: Radiobuttons werden aus Marketinggründen oft optisch als Karten verkleidet, Zahlungsanbieter wie PayPal und Stripe betten eigene iFrames ein, deren internes Fokusverhalten außerhalb der eigenen Kontrolle liegt, und ein 3-D-Secure-Modal reisst den Nutzer mitten im Zahlungsvorgang auf eine fremde Domain. Wer diese drei Bausteine sauber zusammensetzt, verhindert, dass Screenreader-Nutzer genau am letzten Schritt vor dem Kaufabschluss scheitern.