Warum Lighthouse kein BFSG-Check ist

Lighthouse ist nützlich. WAVE ist nützlich. axe ist nützlich.

Aber ein Scanner ist kein BFSG-Check.

Ein Scanner zeigt technische Hinweise. Er beantwortet aber nicht automatisch die eigentliche Frage: Welche Website-Flows sind relevant, was blockiert die Nutzung, was muss zuerst behoben werden und was gehört in einen nachvollziehbaren Maßnahmenplan?

Genau hier liegt der Unterschied zwischen einem Scan und einem Prüfworkflow.

Kurzantwort

Lighthouse kann technische Accessibility-Probleme sichtbar machen. Ein BFSG-orientierter Prüfprozess muss aber zusätzlich Scope, Nutzerflows, manuelle Checks, Dokumentation, Priorisierung, Retest und Reporting berücksichtigen.

Ein guter Scanner ist ein Input. Er ist nicht das Ergebnis.

Was Lighthouse gut kann

Lighthouse kann schnell Hinweise liefern, zum Beispiel:

• fehlende oder problematische Labels
• Kontrastprobleme
• fehlende Alt-Texte
• grundlegende ARIA-Probleme
• technische Accessibility-Warnungen
• Performance- und Best-Practice-Hinweise

Das ist wertvoll, besonders als erster technischer Einstieg.

Aber es bleibt ein automatisierter Blick auf einzelne technische Punkte.

Was Lighthouse nicht sauber entscheidet

Ein Scanner kann Ihnen nicht zuverlässig sagen:

• ob eine Website oder ein Shop überhaupt in den relevanten Scope fällt
• ob der Checkout als vollständiger Nutzerflow funktioniert
• ob Zahlung, Login, Buchung oder Formulare praktisch bedienbar sind
• ob Fehlermeldungen verständlich genug sind
• ob ein Nutzer mit Tastatur durch den Prozess kommt
• ob ein Finding für den Kunden kritisch oder nachrangig ist
• ob Expert Review oder Legal Review nötig ist
• wie daraus ein kundenverständlicher Report wird

Das ist der Bereich, in dem viele Projekte stecken bleiben.

Es gibt dann eine Liste mit 47 Issues. Aber niemand weiß, was zuerst passieren soll.

Warum Scope vor Scanner kommt

Bevor Sie scannen, müssen Sie grob verstehen:

• Ist die Website B2C-relevant?
• Gibt es einen Online-Shop?
• Gibt es Checkout oder Zahlung?
• Gibt es Buchung, Login oder Formulare?
• Gibt es digitale Dienstleistungen?
• Gibt es Anlage-3-relevante Informationen?
• Gibt es kritische Nutzerflows, die manuell geprüft werden müssen?

Wenn diese Fragen offen sind, ist der Scanner nur ein technischer Schnappschuss.

Er zeigt Symptome, aber nicht den Prüfrahmen.

BFSG-relevant wird es oft im Flow

Gerade bei Websites und Online-Shops entsteht die eigentliche Relevanz selten nur auf der Startseite. Wichtiger sind oft:

• Produktsuche
• Produktdetailseite
• Warenkorb
• Checkout
• Zahlungsfunktion
• Login
• Kontaktformular
• Buchungsformular
• Fehlermeldungen
• Bestätigungsseite
• mobile Ansicht

Ein Button kann technisch korrekt aussehen und trotzdem im Nutzerflow Probleme erzeugen.

Ein Formular kann teilweise zugänglich sein und trotzdem am Fehlerzustand scheitern.

Ein Checkout kann im Scanner okay wirken und trotzdem bei Tastaturbedienung unbrauchbar sein.

Der bessere Workflow

Ein sinnvoller Prüfprozess sieht eher so aus:

Scope
→ Website-Flows
→ Scanner-Ergebnisse
→ manuelle Checks
→ Findings
→ Priorisierung
→ Maßnahmenplan
→ Retest
→ Kundenreport

Der Scanner kommt also nicht weg. Er bekommt nur seinen richtigen Platz.

Mini-Checkliste

Bevor Sie Scanner-Ergebnisse an einen Kunden weitergeben, prüfen Sie:

• Ist der Scope dokumentiert?
• Sind die kritischen Website-Flows klar?
• Wurde Checkout/Zahlung/Login/Formular manuell geprüft?
• Sind Findings nach Nutzerwirkung priorisiert?
• Gibt es Screenshots oder Evidenz?
• Ist klar, was nicht feststellbar ist?
• Gibt es einen Retest-Plan?
• Gibt es eine kundenverständliche Zusammenfassung?

Wenn nicht, haben Sie wahrscheinlich noch keinen Report, sondern nur Rohmaterial.

Dieser Artikel ist keine Rechtsberatung, keine Zertifizierung und keine Konformitätsgarantie. Er beschreibt einen strukturierten Prüf- und Dokumentationsansatz.