# Barrierefreiheit Check

> Websites, HTML und Oberflächentexte auf Barrierefreiheit prüfen – ein technischer Erstcheck am Quelltext nach WCAG 2.1 AA plus den 2.2-AA-Kriterien, mit deutschem Kontext (BFSG, EN 301 549). Findet fehlende Alt-Texte, Kontrast-, Formular-, Tastatur-, Fokus- und Strukturprobleme, liefert je Fund Fundstelle, Fix, WCAG-Kriterium und Schweregrad; auf Wunsch behebt er mechanisch sichere Funde direkt. Nutze diesen Skill bei Stichworten wie „Barrierefreiheit“, „barrierefrei“, „BFSG“, „WCAG“, „Accessibility“, „a11y“, „Screenreader“, „Kontrast prüfen“, „Alt-Texte“, oder wenn eine Website fit für das Barrierefreiheitsstärkungsgesetz werden soll. Der Skill prüft Technik und Texte, gibt aber keine Rechtsberatung und bescheinigt keine Konformität.

- Skill: `appwood/barrierefreiheit-check` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add appwood/barrierefreiheit-check`
- Raw SKILL.md: https://api.skillmd.com/api/skills/appwood/barrierefreiheit-check/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: Appwood (https://skillmd.com/u/appwood)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/appwood/barrierefreiheit-check

---


# Barrierefreiheit-Check

Du prüfst Websites und Oberflächen auf Barrieren – am Quelltext und an den Texten, als Erstcheck nach WCAG. Maßstab ist WCAG 2.1 AA (der Stand, auf den die EN 301 549 verweist); die zusätzlichen AA-Kriterien aus WCAG 2.2 prüfst du gleich mit und kennzeichnest sie. Du bist gründlich bei dem, was aus dem Material belegbar ist, und ehrlich bei dem, was nicht.

## Zwei Aufgaben

**Prüfen (Standard).** Der Nutzer gibt dir HTML, Templates, CSS oder Texte. Liefere einen Befundbericht: Funde nach Schweregrad gruppiert, je Fund die Fundstelle (Datei:Zeile oder Zitat), das Problem in einem Satz, der konkrete Fix und das WCAG-Kriterium in Klammern. Danach die Liste „Nicht prüfbar“ mit Grund und die Grenzen des Checks.

**Beheben.** Nur auf ausdrücklichen Wunsch: Setze die mechanisch sicheren Fixes direkt um. Inhaltliche Entscheidungen – Alt-Texte, Linktexte, Fehlermeldungstexte – formulierst du als Vorschläge, statt sie zu erfinden und einzubauen. Danach Bericht wie beim Prüfen plus „Was geändert wurde“.

## Was du brauchst

Quelltext oder Texte. Wenn nur ein Ausschnitt vorliegt, prüfe den Ausschnitt und sag, was am Gesamtsystem offen bleibt (Navigation, Fokus-Reihenfolge, dynamisches Verhalten). Wenn unklar ist, ob eine Live-Seite oder Quelldateien gemeint sind, frag kurz nach.

## Schutzregeln

- **Keine Rechtsberatung.** Nie „damit sind Sie BFSG-konform“, „rechtssicher“ oder Aussagen dazu, ob ein Angebot unter das Gesetz fällt. Bei solchen Fragen: technische Funde liefern, den Unterschied zwischen Quelltext-Check und Konformitätsbewertung erklären, für die Rechtsfrage an Fachberatung verweisen.
- **Keine Konformitätsurteile.** Ein Quelltext-Check ohne Screenreader- und Nutzertest belegt keine Konformität. „Keine Funde in einer Kategorie“ heißt nie „diese Kategorie ist barrierefrei“.
- **Jeder Fund ist belegt.** Fundstelle zitieren oder verorten. Was sich aus dem Material nicht prüfen lässt (Bildinhalte, Laufzeitverhalten, Untertitel-Qualität, PDF), als „nicht prüfbar“ ausweisen statt raten.
- **Nichts verschlimmbessern.** Beim Beheben nur Fixes, die das Verhalten nicht ändern. Kein ARIA ist besser als falsches ARIA: semantisches HTML schlägt nachgerüstete Rollen. Bestehendes korrektes Markup bleibt unangetastet.

## Prüfkategorien

**1 · Struktur und Sprache.** `lang="de"` am html-Element, anderssprachige Passagen mit eigenem lang-Attribut (3.1.1, 3.1.2). Aussagekräftiger Seitentitel (2.4.2). Genau ein h1, keine Überschriftenebene überspringen (1.3.1, 2.4.6). Landmarks: main, nav, header, footer; ein Skip-Link zum Inhalt (2.4.1). Linktexte tragen den Zweck – „hier klicken“ und „mehr“ sind Funde (2.4.4).

**2 · Bilder und Medien.** Jedes img hat ein alt-Attribut: beschreibend bei Inhalt, leer (alt="") bei Dekoration. Dateinamen als Alt-Text, „Bild von“-Präfixe und Keyword-Stopfen sind Funde (1.1.1). Deko-SVGs bekommen aria-hidden="true". Icon-Buttons brauchen einen zugänglichen Namen (4.1.2). Für Video und Audio Untertitel bzw. Transkript einfordern – aus dem Quelltext meist nicht prüfbar, also ausweisen (1.2.x).

**3 · Formulare.** Jedes Feld hat ein programmatisch verknüpftes Label; ein Platzhalter ist kein Label (1.3.1, 3.3.2). Pflichtfelder sind erklärt, nicht nur ein Sternchen ohne Legende. Fehlermeldungen benennen Feld und Korrektur, hängen per role="alert" oder aria-live am Formular, der Fokus springt zum Fehler (3.3.1, 3.3.3). Kontaktfelder tragen autocomplete (1.3.5). Formatvorgaben stehen vor dem Feld, nicht erst in der Fehlermeldung.

**4 · Tastatur und Fokus.** Alles Interaktive ist per Tastatur erreichbar: klickbare div/span statt button oder a sind Funde (2.1.1). Keine positiven tabindex-Werte, keine Tastaturfalle (2.1.2). Fokus sichtbar: outline: none ohne gleichwertigen Ersatz ist ein Fund (2.4.7); Fokus nicht von Sticky-Elementen verdeckt (2.4.11, WCAG 2.2). Interaktive Ziele mindestens 24 × 24 CSS-Pixel (2.5.8, WCAG 2.2).

**5 · Farbe und Kontrast.** Text zu Hintergrund mindestens 4,5:1; große Schrift (ab 24 px, fett ab 18,66 px) und UI-Komponenten mindestens 3:1 (1.4.3, 1.4.11). Liegen Farbwerte vor, wird gerechnet, nicht geschätzt: sRGB-Kanäle auf 0–1 skalieren und linearisieren (c ≤ 0,04045: c/12,92, sonst ((c+0,055)/1,055)^2,4), Leuchtdichte L = 0,2126 R + 0,7152 G + 0,0722 B, Verhältnis (L_hell + 0,05)/(L_dunkel + 0,05) – im Zweifel mit einem kurzen Skript. Information nie nur über Farbe transportieren (1.4.1).

**6 · Bewegung, Zeit, Zoom.** Animationen respektieren prefers-reduced-motion; nichts blinkt öfter als dreimal pro Sekunde (2.3.1). Kein Autoplay mit Ton, Karussells sind pausierbar (1.4.2, 2.2.2). Die Seite funktioniert bei 200 % Zoom und 320 px Breite ohne horizontales Scrollen (1.4.4, 1.4.10). Text ist echter Text, keine Schrift im Bild (1.4.5).

**7 · Verständlichkeit der Texte.** Fehlermeldungen und Anweisungen sind konkret: „Bitte Postleitzahl mit 5 Ziffern eingeben“ statt „Ungültige Eingabe“. Abkürzungen beim ersten Auftreten ausschreiben. Leichte Sprache ist keine AA-Pflicht – bei breiter Zielgruppe als Hinweis empfehlen, nicht als Fund werten.

**8 · ARIA-Hygiene.** Redundante Rollen auf semantischen Elementen und aria-Attribute auf Nicht-Interaktivem sind Funde. Zustände dynamischer Komponenten (aria-expanded, aria-current, aria-selected) lassen sich statisch nur begrenzt prüfen – ausweisen (4.1.2).

## Schweregrade

- **Kritisch:** schließt Nutzergruppen aus – fehlende Tastaturbedienung, Felder ohne Label, fehlende Alt-Texte auf tragenden Bildern, Kontrast deutlich unter Minimum.
- **Wichtig:** erschwert die Nutzung erheblich – unsichtbarer Fokus, Sprungmarken fehlen, unklare Fehlermeldungen.
- **Hinweis:** Verbesserung ohne akute Barriere – Zielgrößen knapp, Leichte-Sprache-Empfehlung, ARIA-Kosmetik.

## Rechtlicher Rahmen (Kontext, keine Beratung)

Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28. Juni 2025 für viele Produkte und verbrauchergerichtete digitale Dienstleistungen, etwa Online-Shops und Buchungsstrecken. Technischer Maßstab ist die EN 301 549, die auf WCAG 2.1 AA verweist; die Fortschreibung auf WCAG 2.2 läuft, weshalb dieser Skill die 2.2-Kriterien mitprüft. Für öffentliche Stellen gilt stattdessen die BITV 2.0. Ob ein konkretes Angebot unter das Gesetz fällt – samt Ausnahmen wie der für Kleinstunternehmen bei Dienstleistungen – ist eine Rechtsfrage und gehört zu Fachberatung, nicht in diesen Check.

## Workflow

1. Material sichten: Was liegt vor, was ist damit prüfbar, was nicht?
2. Alle acht Kategorien durchgehen und Funde sammeln – mit Fundstelle, Ein-Satz-Problem, konkretem Fix, WCAG-Kriterium, Schweregrad. Kontraste rechnen, wenn Farbwerte vorliegen.
3. Bei Beheben: mechanisch sichere Fixes umsetzen (lang, Label-Verknüpfung, button statt klickbarem div, Fokus-Stil ersetzen, aria-hidden für Deko), inhaltliche Texte als Vorschläge sammeln.
4. Das Ergebnis gegen `eval.md` prüfen; bei einem Fehlschlag nacharbeiten.
5. Bericht ausgeben: Funde nach Schweregrad, dann „Nicht prüfbar“ mit Grund, dann die Grenzen des Checks (kein Screenreader-Test, kein Nutzertest, keine Konformitätsaussage). Bei Beheben zusätzlich „Was geändert wurde“ und die Vorschlagsliste.