5 Barrierefreiheits-Checks vor dem Release

Führen Sie vor dem Release fünf Checks in dieser Reihenfolge durch: navigieren Sie mit der Tastatur per Tab durch die komplette UI, führen Sie einen automatisierten Scan aus, überprüfen Sie semantisches HTML und Labels, kontrollieren Sie den Farbkontrast und testen Sie bei 200 % Zoom.

Wer schon einmal ein Modal ausgeliefert hat, das Tastaturnutzer stillschweigend eingesperrt hat, und das erst Wochen später aus einem Bug-Report erfahren hat, weiß, warum es eine solche Liste gibt. Es ist genau die Art von Problem, die niemand entdeckt, solange er die Maus in der Hand hält.

Zusammen dauern die Checks nur wenige Minuten und deckt die häufigsten Barrierefreiheitsfehler auf. Kein Spezialwissen, keine teuren Tools, kein wochenlanges Einarbeiten erforderlich. Dies ist eine Pre-Ship-Checkliste für Barrierefreiheit, die Sie bei jedem Pull Request abarbeiten können – schnell und ehrlich in Bezug auf ihre eigenen Grenzen. Sie macht Ihre App nicht vollständig konform zu WCAG 2.2 (dem aktuellen Standard, im Oktober 2023 als W3C Recommendation veröffentlicht und als ISO/IEC 40500:2025 übernommen), beseitigt aber die Fehler, die echte Nutzer am stärksten beeinträchtigen. Ein wenig zu tun ist deutlich besser, als gar nichts zu tun.

1. Mit der Tastatur per Tab durch die komplette UI navigieren

Der schnellste echte Test ist kostenlos und dauert unter einer Minute: Maus weglegen, mit Tab durch die Seite navigieren und prüfen, ob der Fokus sichtbar ist, alle interaktiven Elemente erreichbar sind und jedes Modal verlassen werden kann, ohne im Fokus gefangen zu bleiben. Achten Sie auf vier Dinge: einen sichtbaren Fokusindikator auf jedem Element, eine logische Tab-Reihenfolge, die Erreichbarkeit jedes Buttons, Links und Eingabefelds sowie das Fehlen von Fokusfallen in Dropdowns oder Dialogen.

Zwei Fehler verursachen die meisten Tastaturprobleme. Erstens: Custom-Controls, die die native Outline für ein eigenes Styling entfernt haben. Falls Sie das getan haben, fügen Sie ein sichtbares :focus- (oder :focus-visible-)Styling wieder hinzu:

.custom-checkbox input:focus-visible + .box {
  outline: 2px solid #2563eb;
  outline-offset: 2px;
}

Zweitens: ein klickbares <div>. Ersetzen Sie es durch ein <button>, das standardmäßig fokussierbar ist und die Aktivierung per Enter/Leertaste sowie die Button-Rolle kostenlos mitbringt. Ein <div> bietet davon nichts:

// Not reachable by keyboard
<div onClick={handleClick}>Save</div>
// Focusable and operable by default
<button onClick={handleClick}>Save</button>

Ihr manueller Tab-Durchgang testet den Happy Path, den Sie entworfen haben. Session Replay echter Sitzungen deckt jene Tastatur- und Fokusprobleme auf, die nur im Produktivbetrieb auftreten: ein Nutzer, der in ein Modal tabbt und nicht mehr heraustabben kann, oder ein Fokus, der nach dem Schließen eines Dialogs an den Seitenanfang verschwindet und Tastaturnutzer orientierungslos zurücklässt. Replay zeigt Ihnen, wo das reale Fokusverhalten von dem abweicht, was Ihr Scan durchgewinkt hat.

2. Einen automatisierten Scan ausführen (Lighthouse + axe DevTools)

Ein Scanner findet zwischen einem Drittel und 40 % der Barrierefreiheitsprobleme einer Seite – ein grüner Score bedeutet also, dass Sie die leichten Punkte abgeräumt haben (fehlender Alt-Text, unbeschriftete Eingabefelder, zu geringer Kontrast, ein fehlendes lang-Attribut) und nicht mehr. Dieser Bereich entspricht dem, was Testing-Anbieter üblicherweise angeben, und ist eher eine Unter- als eine Obergrenze: Deques Studie von 2021 argumentiert, dass die automatisierte Abdeckung näher bei 57 % liegt, wenn man die Anzahl der gefundenen Probleme statt den Anteil der abgedeckten Erfolgskriterien zählt. In jedem Fall lassen sich die erkannten Probleme am günstigsten beheben.

Führen Sie den Scan über das Lighthouse-Panel in den Chrome DevTools aus: DevTools öffnen, das Lighthouse-Panel auswählen, Accessibility aktivieren und den Report generieren. Ein Durchlauf, der nur die Barrierefreiheit prüft, ist schnell erledigt. Lighthouses Accessibility-Audit basiert auf dem Open-Source-Regelsatz axe-core von Deque, führt aber nur einen Teil davon aus. Ergänzen Sie daher die axe DevTools-Extension, die den vollständigen Regelsatz anwendet und sich ausschließlich auf Barrierefreiheit konzentriert. Beheben Sie zuerst die Probleme der Kategorien Critical und Serious.

3. Semantisches HTML und Labels überprüfen

Screenreader vermitteln Struktur über Semantik – verwenden Sie also das Element, das zur Aufgabe passt: <button> für Aktionen, <a href> für Navigation, <ul>/<li> für Listen, <nav> und <main> als Landmarks und Überschriften in der richtigen Reihenfolge (h1 → h2 → h3, ohne Ebenen zu überspringen). Wenn alles ein <div> ist, liest ein Screenreader „Gruppe, Gruppe, Gruppe” vor und die Seite verliert ihre Struktur.

Jedes Eingabefeld braucht ein zugehöriges <label>; Buttons, die nur ein Icon enthalten, benötigen ein aria-label, damit sie nicht bloß als „Button” angekündigt werden:

<label htmlFor="email">Email</label>
<input id="email" type="email" />

<button aria-label="Copy to clipboard" onClick={copy}>
  <ClipboardIcon />
</button>

Ein häufiges Fehlerbild in der Produktion: Eine hochwertig aussehende Drittanbieter-Komponentenbibliothek liefert nicht barrierefreies Markup aus – etwa ein Accordion oder eine Combobox, deren <input> kein <label> besitzt, sodass ein Screenreader nichts ankündigt. Eine schöne Komponente ist keine Garantie. Inspizieren Sie das DOM, das die Bibliothek rendert, und prüfen Sie, ob die Labels wirklich vorhanden sind.

4. Farbkontrast prüfen und sich nicht allein auf Farbe verlassen

Für Level AA benötigt Text ein Kontrastverhältnis von mindestens 4,5:1 bei normalem Text und 3:1 bei großem Text (18pt/24px oder 14pt/18,66px fett), gemäß WCAG-Erfolgskriterium 1.4.3. Behandeln Sie beide Werte als harte Untergrenzen. Es wird nicht aufgerundet – ein gemessener Wert von 4,499:1 fällt also durch. Für Interface-Komponenten und bedeutungstragende Icons gilt eine separate, niedrigere Schwelle von 3:1 gegenüber angrenzenden Farben (SC 1.4.11 Non-Text Contrast). Das heißt: Eine bestandene Textfarbe garantiert nicht, dass auch Ihre Buttons und Formularrahmen bestehen.

Lighthouse markiert viele Textkontrast-Verstöße; der WebAIM Contrast Checker bestätigt die exakten Verhältnisse. Konkret: #999999 auf Weiß ergibt 2,85:1 und fällt durch; #595959 auf Weiß ergibt 7:1 und besteht.

Kontrast ist nicht die ganze Geschichte. Signalisieren Sie einen Fehler niemals allein über Farbe. Ein roter Rahmen ist für viele farbenblinde Nutzer unsichtbar – kombinieren Sie ihn deshalb mit einem Icon und Text, damit die Bedeutung auch ohne Farbe erhalten bleibt. Setzen Sie eine Meldung wie „⚠ E-Mail ist erforderlich” neben das Feld, nicht nur einen roten Rahmen.

5. Auf 200 % zoomen und reduzierte Bewegung berücksichtigen

Bei 200 % Browser-Zoom darf sich nichts überlappen, abgeschnitten werden oder horizontales Scrollen erzwingen. Halten Sie Ctrl/Cmd gedrückt und drücken Sie +, bis der Zoom 200 % erreicht, und klicken Sie sich dann durch: Container mit fester Breite und pixelbasierte Größenangaben sind die üblichen Verdächtigen. Größenangaben in rem und ein zusätzliches overflow-wrap halten Layouts flexibel:

.container { max-width: 60rem; padding: 1rem; }
p { overflow-wrap: break-word; }

Berücksichtigen Sie außerdem prefers-reduced-motion: Kapseln Sie nicht essenzielle Animationen in eine Media Query, damit Nutzer, die in ihrem Betriebssystem reduzierte Bewegung eingestellt haben, nicht davon beeinträchtigt werden. Die Einstellung verlangt, dekorative Bewegung zu reduzieren, nicht jede Animation zu entfernen – lassen Sie deshalb alles laufen, was Bedeutung trägt (ein Lade-Spinner, ein Fortschrittsindikator).

@media (prefers-reduced-motion: reduce) {
  /* Target the decorative motion, not every animation on the page.
     Loading spinners and other essential feedback should keep moving. */
  .parallax,
  .carousel-autoplay,
  .hero-animation {
    animation: none;
    transition: none;
  }
}

Bonus, 60 Sekunden: Aktivieren Sie einen Screenreader und hören Sie zu. Unter macOS drücken Sie Cmd + F5 für VoiceOver; unter Windows installieren Sie das kostenlose NVDA. Tabben Sie durch die Seite und prüfen Sie, ob Überschriften, Labels und Eingabefelder mit echter Bedeutung angekündigt werden.

Ausliefern – und dann tiefer einsteigen

Diese fünf Checks sind eine Untergrenze, keine Obergrenze. Sie lassen komplexe ARIA-Patterns, Fokusverwaltung in Single-Page-Apps und barrierefreie Datentabellen außen vor – alles echte Arbeit für einen anderen Tag. Nehmen Sie sich Ihr nächstes Feature vor, führen Sie die fünf Checks durch, bevor Sie den PR öffnen, und beheben Sie die gefundenen Critical-Probleme. Wenn Sie tiefer einsteigen möchten, sind WCAG 2.2, WebAIM und die Accessibility-Dokumentation von MDN die primären Quellen, die Ihre Zeit wert sind. Barrierefreiheit ist eine Richtung, in die man sich bewegt – und wer diese fünf Checks umsetzt, kommt ihr heute schon näher.

FAQs

Welches Kontrastverhältnis brauche ich für Barrierefreiheit?

Für WCAG 2.2 Level AA benötigt normaler Text ein Kontrastverhältnis von mindestens 4,5:1 gegenüber dem Hintergrund, großer Text (18pt/24px oder 14pt/18,66px fett) mindestens 3:1, gemäß Erfolgskriterium 1.4.3. Interface-Komponenten und bedeutungstragende Icons fallen unter ein separates Kriterium, 1.4.11, das 3:1 gegenüber angrenzenden Farben verlangt. Zu keinem der Werte darf aufgerundet werden – ein gemessener Wert von 4,499:1 fällt also durch.

Erkennen automatisierte Barrierefreiheits-Tools alles?

Nein. Lighthouse und axe deckenzwischen einem Drittel und 40 Prozent der Barrierefreiheitsprobleme auf, überwiegend die leichten Punkte wie fehlenden Alt-Text, unbeschriftete Eingabefelder, zu geringen Kontrast und ein fehlendes lang-Attribut. Sie können nicht beurteilen, ob ein Alt-Text sinnvoll ist, ob die Tab-Reihenfolge logisch ist oder ob der Fokus nach einer Interaktion verwaltet wird. Ein grüner Lighthouse-Score räumt die günstigen Korrekturen ab, nicht die gesamte Seite – kombinieren Sie deshalb jeden Scan mit Tastatur- und Screenreader-Tests.

Was ist der Unterschied zwischen Lighthouse und axe DevTools?

Lighthouses Accessibility-Audit basiert auf dem axe-core-Regelsatz von Deque, führt davon jedoch nur einen Teil aus – neben Audits zu Performance, SEO und Best Practices, alle über das Lighthouse-Panel in den Chrome DevTools. Die Browser-Extension axe DevTools führt den vollständigen axe-core-Regelsatz aus und konzentriert sich ausschließlich auf Barrierefreiheit. Nutzen Sie Lighthouse für einen schnellen Durchgang und anschließend axe DevTools für eine tiefere, rein auf Barrierefreiheit ausgerichtete Abdeckung.

Welcher WCAG-Version sollte ich 2026 folgen?

Folgen Sie WCAG 2.2, dem aktuellen Standard. Sie wurde im Oktober 2023 zur W3C Recommendation, im Dezember 2024 aktualisiert und ist inzwischen auch ISO/IEC 40500:2025, die mit der Version von Oktober 2023 identisch ist. WCAG 3.0 existiert nur als Working Draft, den das W3C regelmäßig überarbeitet; eine Candidate Recommendation ist für Ende 2027 vorgesehen, eine endgültige Recommendation nicht vor 2028 zu erwarten. WCAG 3.0 ist heute für nichts maßgeblich.