Barrierefreiheit

Farbunabhängigkeit
→ Information wird nie ausschließlich durch Farbe vermittelt

Textkontraste ausreichend
→ Kontrastverhältnis mind. 4,5:1 (normale Schrift), 3:1 (große/fette Schrift)

Keine feste Ausrichtung erforderlich
→ Inhalte funktionieren auch im Hoch- und Querformat

Zielgröße interaktiver Elemente
→ Buttons/Links mind. 24×24 px, außer im engen Kontext (neu in 2.2)

Semantisches HTML
→ HTML-Elemente passen zum Inhalt (z. B. Listen, Tabellen, Zitate)

Logische Reihenfolge im DOM
→ Inhalte erscheinen in sinnvoller Reihenfolge für Screenreader

Überschriftenstruktur korrekt
→ Hierarchie von h1 bis h6 wird logisch eingehalten

Skalierbarkeit & Responsivität
→ Inhalte bleiben bei 200 % Zoom und 320px Breite nutzbar

Fehlerfreier Quelltext
→ Keine Validierungsfehler, saubere ARIA-Verwendung

Fokus-Indikator gut sichtbar
→ Tastaturfokus klar erkennbar

Linktexte verständlich
→ aus sich heraus oder durch Kontext eindeutig

Navigation konsistent
→ Navigationselemente verhalten sich auf allen Seiten gleich

Tastaturbedienbarkeit
→ Alle Inhalte und Funktionen sind ohne Maus nutzbar

Logische Fokusreihenfolge
→ Fokus wandert in erwartbarer Reihenfolge durch die Seite

Sprunglinks oder ARIA-Landmarks
→ ermöglichen das Überspringen sich wiederholender Inhalte

Drag & Drop ist alternativ nutzbar
→ z. B. per Tastatur (neu in 2.2)

Keine blockierenden Eingabehilfen
→ z. B. Onscreen-Keyboards dürfen Fokus nicht stören (neu in 2.2)

Beschriftung mit Label-Element
→ Jedes Eingabefeld ist mit label verknüpft, kein Placeholder-Ersatz

Fehlermeldungen verständlich
→ Klare Hinweise zum fehlerhaften Feld

Hinweise zur Eingabe vorhanden
→ z. B. Formatangaben oder Beispiele

Kritische Eingaben absicherbar
→ z. B. bei rechtlichen oder finanziellen Angaben

Captchas mit Alternative
→ z. B. reCAPTCHA mit barrierefreiem Zugriff

Feldgruppen mit fieldset und legend
→ bei mehrteiligen Formularen

ALT-Texte bei Bildern
→ beschreibend bei Inhalt, leer bei Deko

Keine Bildschrift für Inhalte
→ Inhalte nicht als Bildgrafik einbinden (Logos okay)

Videos mit Sprache haben Untertitel
→ synchron, genau und gut lesbar

Videos ohne Sprache haben Kontext
→ kurzer Beschreibungstext (Kontext) kann nötig sein, z. B. per aria-describedby, ALT-Text oder flankierendem Fließtext.

Reine Audio-Inhalte haben Transkript
→ z. B. bei Podcasts

Nur-Musik-Videos ohne Untertitel
→ aber evtl. mit erklärendem Text zum Inhalt

Keine Autoplay-Medien ohne Steuerung
→ Stopp-/Pausenfunktion vorhanden

Keine Blitz-Inhalte
→ nichts flackert häufiger als 3x pro Sekunde

PDFs sind barrierefrei
→ mit Tags, Lesereihenfolge, Alternativtexten etc.
PDFs gelten als „nicht-webbasierte Dokumente“ und müssen ebenfalls zugänglich gestaltet sein, z. B. mit Tags, Lesereihenfolge, ALT-Texten für Bilder, sinnvollen Überschriften usw.

Zugängliche Statusanzeigen
→ z. B. bei Formularen (aria-live bei Erfolg/Fehler)

Keine unerwarteten Änderungen
→ Fokus oder Inhalte verändern sich nicht ohne Ankündigung

Nativ PDFs als Alternative 

Nativ PDF Alternativ bereitgestellt:
WCAG 2.2 erlaubt interaktive Lösungen, sofern eine gleichwertige Alternative verfügbar ist. Ein nativer Link zur PDF-Datei ist diese Alternative.

Verhältnismäßigkeit beachtet (BFSG)
Die Verbesserung der Nutzererfahrung durch das Plugin ist zulässig, wenn die barrierefreie Nutzung weiterhin möglich bleibt.

Keine unnötige Barriere
Menschen mit Screenreader, Tastaturbedienung oder Mobilgeräten können das native PDF öffnen und nutzen.

Strukturierte Tabellen
→ Tabellen haben thead, th, caption, sinnvolle Überschriften

Barrierefreiheit bei Plugins prüfen
→ Drittanbieter-Elemente wie Cookie-Consent, Buchungstools, Formulare etc. müssen zugänglich sein – wenn nicht, besser Alternativen nutzen oder deklarieren

Nicht vollständig barrierefreie Funktionen dokumentieren
→ Wenn bestimmte Funktionen nicht barrierefrei umsetzbar sind, den Grund festhalten (z. B. technisches Limit, Plugin ohne Schnittstelle, zu hoher Aufwand)

Umgehungsmöglichkeiten anbieten
→ Alternative Wege bereitstellen (z. B. Kontaktformular, E-Mail, Hilfe-Abschnitt)

Nutzerhinweis auf der Website platzieren
→ Freiwilliger Hinweistext an geeigneter Stelle (z. B. in der Fußzeile oder im Hilfebereich)

Verhältnismäßigkeit berücksichtigen (nur BFSG)
→ Barrierefreiheit muss nur umgesetzt werden, wenn sie technisch/wirtschaftlich zumutbar ist

Künftige Verbesserung einplanen
→ Teil-Barrierefreiheit darf nicht dauerhaft sein – dokumentierte Absicht zur Optimierung zeigen


Beispiel Nutzer Hinweis:

BITV-Vorgaben:

• ❌ Keine „Erklärung zur Barrierefreiheit“ auf der Website

• ❌ Kein Feedback-Mechanismus für Barrieren erforderlich

• ❌ Kein jährliches Update oder Prüfbericht über den Stand der Barrierefreiheit

• ❌ Keine Zertifizierung oder Prüfung durch eine staatliche Stelle

• ❌ Keine Pflicht zur BITV-konformen Gestaltung von Verwaltungsvorgängen, z. B. Online-Anträgen

➡ Gilt nur für öffentliche Stellen laut § 12 BGG i. V. m. BITV 2.0

WCAG AAA (nicht verpflichtend, auch für niemanden)

• ❌ Keine Audiodeskription von Videos erforderlich (nur AAA)

• ❌ Keine erweiterten Kontrastverhältnisse (z. B. 7:1 bei Fließtext)

• ❌ Keine „erweiterten kognitiven Unterstützungen“

• ❌ Kein Fokus auf Gebärdensprache oder Leichte Sprache

➡ Gilt nur für Level AAA, das selbst viele öffentliche Stellen nicht vollständig umsetzen