PrincepsDigital

Startseite/Barrierefreiheit & BFSG

Barrierefreiheit lässt sich nicht auf einen Tool-Score reduzieren

Automatisierte Tests finden wichtige technische Fehler. Ob ein Angebot im konkreten Fall gesetzliche Anforderungen erfüllt und für Menschen tatsächlich gut nutzbar ist, braucht zusätzlich Kontext und manuelle Prüfung.

Technische Einordnung, keine Rechtsberatung: Jonathan Fürst

WCAG
technischer Standard
BFSG
Anwendbarkeit im Einzelfall
Automatik
nur Teilabdeckung
Ergebnis
Befunde plus manuelle Liste

WCAG, EN 301 549 und BFSG sind nicht dasselbe

WCAG 2.2 beschreibt international anerkannte Erfolgskriterien für zugängliche Webinhalte. EN 301 549 ist eine europäische Norm für Barrierefreiheitsanforderungen an IKT. Das BFSG ist deutsches Recht und gilt abhängig von Angebot, Rolle, Unternehmens- und Übergangskontext.

Aus einem automatisierten Scan darf deshalb keine pauschale Aussage „BFSG-konform“ entstehen. Schon die Frage, ob das Gesetz auf einen konkreten Dienst anwendbar ist, benötigt Informationen, die eine Website allein oft nicht zuverlässig liefert.

EbeneFrageAudit-Ergebnis
TechnikIst ein Kriterium maschinell verletzt?belegter automatischer Befund
BedienungFunktioniert der Pfad mit Tastatur und Hilfsmitteln?manuelle oder hybride Prüfung
InhaltIst Text, Alternative oder Anweisung angemessen?fachliche Bewertung
RechtWelche Pflicht gilt für dieses Angebot?individuelle rechtliche Einordnung

Was sich automatisiert belastbar prüfen lässt

Regelbasierte Werkzeuge können unter anderem fehlende zugängliche Namen, bestimmte Semantikfehler, Kontrastprobleme, ungültige ARIA-Beziehungen, Formularbeschriftungen und programmatisch messbaren Overflow erkennen. Browsermessungen ergänzen Fokuszustände, Zielgrößen und Reflow.

Jeder Fehler sollte das betroffene Element, die URL, den Browserzustand und die zugrunde liegende Regel nennen. Eine bloße Anzahl „Accessibility Errors“ reicht für die Behebung nicht aus.

Automatisch bestanden ist nicht vollständig bestanden

Viele WCAG-Erfolgskriterien sind kontextabhängig oder nur teilweise automatisierbar. Nicht geprüfte Kriterien dürfen nicht stillschweigend als erfüllt gezählt werden.

Was Menschen prüfen müssen

  1. Sind Alternativtexte im konkreten Nutzungskontext hilfreich und nicht redundant?
  2. Ist die gesamte Aufgabe mit Tastatur in sinnvoller Reihenfolge bedienbar?
  3. Werden Screenreader-Nutzende über Zustände, Fehler und Änderungen informiert?
  4. Sind Überschriften, Anweisungen, Linktexte und Fehlermeldungen verständlich?
  5. Bleibt die Funktion bei Textvergrößerung, Zoom und angepassten Abständen erhalten?
  6. Sind Videos, Audio und zeitabhängige Inhalte mit passenden Alternativen versehen?
  7. Verursachen Animation, Zeitlimits oder komplexe Gesten vermeidbare Barrieren?
  8. Funktionieren kritische Pfade mit realen Hilfsmitteln und Nutzenden?

Ein belastbarer Prüfprozess

  1. Scope und Anwendbarkeit: Dienste, Nutzergruppen, Ausnahmen und kritische Pfade klären.
  2. Automatischer Lauf: repräsentative Templates, Viewports und Zustände erfassen.
  3. Tastatur und Zoom: Navigation, Formulare, Dialoge und Reflow manuell testen.
  4. Assistive Technologien: zentrale Abläufe mit geeigneten Screenreader-/Browser-Kombinationen prüfen.
  5. Redaktion: Alternativen, Sprache, Anweisungen und Medien bewerten.
  6. Behebung und Retest: Komponenten statt Einzelseiten korrigieren und Regressionen verhindern.

Ein komponentenbasierter Fehler – etwa ein unzugänglicher Dialog – kann Hunderte Seiten betreffen. Der Report muss Fundstellen deduplizieren, die Reichweite aber sichtbar lassen.

Welche Fehler zuerst behoben werden sollten

Priorität entsteht nicht allein aus einer WCAG-Stufe. Ein Fehler ist besonders dringlich, wenn er eine wesentliche Aufgabe vollständig verhindert, viele Templates betrifft, keine Alternative besitzt oder Menschen regelmäßig ausschließt.

  1. Blockierende Tastaturfallen, unbedienbare Navigation und nicht zugängliche Authentifizierung.
  2. Formulare ohne Namen, erkennbare Fehler oder verständliche Korrekturmöglichkeit.
  3. Kritische Inhalte, die bei Zoom, Reflow oder Screenreader-Nutzung verschwinden.
  4. Systemische Komponentenfehler mit großer Reichweite.
  5. Danach lokale, nicht blockierende und rein redaktionelle Einzelprobleme.

Wie ein seriöses Ergebnis formuliert wird

Ein Bericht kann sagen: „Im ausgeführten automatischen Profil wurden keine Verstöße erkannt“, „potenzielles Risiko“ oder „manuelle Prüfung erforderlich“. Er sollte nicht behaupten, eine Website sei vollständig barrierefrei oder rechtssicher, wenn nur ein automatischer Lauf stattgefunden hat.

Technische Barrieren priorisieren

Der Audit verbindet automatisierte Evidenz mit einer sichtbaren manuellen Prüfliste. Die rechtliche Bewertung bleibt getrennt.

Audit anfragen

Primärquellen