Checkliste für Software-Barrierefreiheit (WCAG 2.2)

Was ist eine Checkliste für Software-Barrierefreiheit?

Eine Checkliste für Software-Barrierefreiheit ist eine Liste konkreter Ja-oder-Nein-Prüfungen, mit denen ein Team eine Website oder App auf Barrieren für Menschen mit Behinderungen untersucht. Gute Listen beruhen auf WCAG-Erfolgskriterien, sind nach dem Bedarf der Nutzer gegliedert (wahrnehmbar, bedienbar, verständlich, robust) und laufen in Design, Entwicklung und Release mit. Eine Checkliste findet häufige Probleme früh. Konformität belegt sie allein nicht.

Was geprüft wird

• Tastatur. Lässt sich jedes Bedienelement allein mit der Tastatur erreichen und nutzen, in sinnvoller Reihenfolge und ohne Falle?
• Sichtbarer Fokus. Ist das fokussierte Element klar erkennbar (WCAG 2.4.7, Stufe AA)?
• Textalternativen. Haben aussagekräftige Bilder eine Beschreibung, dekorative keine? Siehe barrierefreie Bilder.
• Kontrast. Erreicht Text 4,5:1, bei großer Schrift 3:1 (mindestens 18 Punkt oder 14 Punkt fett; WCAG 1.4.3, Stufe AA)? Siehe barrierefreie Farbpaletten.
• Zielgröße. Sind Zeigerziele mindestens 24 mal 24 CSS-Pixel groß oder so angeordnet, dass sie die Ausnahmen erfüllen (WCAG 2.5.8, neu in 2.2, Stufe AA)?
• Formulare. Hat jedes Feld eine Beschriftung, und werden Fehler als Text beschrieben und assistiver Technik mitgeteilt?
• Struktur und Namen. Sind Überschriften, Landmarken und Namen von Bedienelementen aussagekräftig, und wird ARIA nur eingesetzt, wo natives HTML nicht reicht?
• Medien. Haben Video und Audio Untertitel oder Transkripte? Siehe barrierefreie Medien.
• Layout und Zoom. Funktioniert die Oberfläche bei Skalierung und auf kleinen Bildschirmen? Siehe barrierefreies Layout.

So setzen Sie die Liste ein

• Wählen Sie zuerst Standard und Stufe, meist WCAG 2.2 AA.
• Prüfen Sie Entwürfe vor dem Bau dagegen und gehen Sie sie pro Feature im Code-Review durch.
• Lassen Sie automatische Scans über die am Code erkennbaren Punkte laufen und prüfen Sie den Rest von Hand mit Screenreader und Tastatur. Siehe manuelle Tests und automatisierte Tests.
• Protokollieren Sie jeden Fehler mit Seite, Kriterium und Lösung und prüfen Sie danach erneut.

Beispielpunkte

Ein konkreter Punkt liest sich wie ein Test: "Auf der Checkout-Seite von oben mit Tab durchgehen. Jedes Feld und jede Schaltfläche erhält in der Bildschirmreihenfolge einen sichtbaren Fokusrahmen, und die Eingabetaste sendet das Formular ab." Bestanden oder nicht, mit genannter Seite.

Häufige Fehler

• Eine abgehakte Liste oder einen sauberen Lighthouse-Lauf als Beleg für WCAG-Konformität behandeln. Automatische Werkzeuge prüfen nur einen Teil.
• Sie einmal vor dem Launch statt bei jedem Release durchgehen.
• Assistive Technik auslassen, etwa Screenreader und Schaltersteuerung.
• ARIA ergänzen, wo sauberes HTML das Problem löst.

Wo LoadFocus ins Spiel kommt

LoadFocus führt kein vollständiges Barrierefreiheits-Audit durch und stellt keine Konformitätsberichte aus. Das Page-Speed-Monitoring führt geplante Lighthouse-Audits mit einem Accessibility-Score aus, der zwischen manuellen Prüfungen Rückschritte bei den am Code erkennbaren Punkten anzeigen kann. Mehr dazu in Performance-Tests und Barrierefreiheit.

Häufige Fragen

Genügt eine Checkliste, um WCAG-Konformität zu behaupten?

Nein. Eine Checkliste findet häufige Probleme, aber Konformität wird pro Erfolgskriterium an einer repräsentativen Stichprobe beurteilt, und ein Teil davon erfordert manuelle Bewertung. Die Liste ist ein gutes Arbeitswerkzeug, kein Zertifikat.

Auf welche WCAG-Stufe soll die Checkliste zielen?

Üblich ist Stufe AA von WCAG 2.2. Prüfen Sie, ob Kunde, Gesetz oder Vertrag einen bestimmten Standard oder eine Version nennen.

Welche schnellen Erfolge bringt eine Checkliste für Software-Barrierefreiheit?

Volle Tastaturbedienung mit sichtbarem Fokus, Beschriftungen an jedem Formularfeld, Alternativtexte bei aussagekräftigen Bildern und ausreichender Textkontrast beheben einen großen Teil der häufigen Fehler.

Lässt sich die ganze Checkliste automatisieren?

Nein. Scanner wie Lighthouse und axe finden am Code erkennbare Probleme, aber Punkte wie logische Tab-Reihenfolge, sinnvolle Alternativtexte und das Verhalten mit Screenreader braucht einen Menschen.