Wie funktioniert es?
barrieretest.at nutzt automatisierte Tests für einen schnellen Erstcheck. Optional kann eine KI-Analyse ergänzt werden, wenn Sie sie aktivieren und die Funktion verfügbar ist. Hier erfahren Sie, was hinter den Kulissen passiert und wo die Grenzen liegen.
Überblick: Was passiert bei einem Test?
Ein Test öffnet Ihre Seite genau einmal in einem Headless-Browser. In dieser Sitzung läuft zuerst eine technische Analyse mit axe-core, und — optional — auf derselben Seite eine KI-basierte semantische Analyse (Vision + Text). Beide Phasen teilen sich denselben Browser, um doppelten Aufwand zu vermeiden.
Phase 1: Technische Analyse mit axe-core
Die Open-Source-Engine axe-core wird direkt in der geladenen Seite ausgeführt und prüft den DOM auf Verstöße gegen WCAG 2.1-Kriterien. Sie erkennt z.B. fehlende Alt-Texte, Kontrast-Probleme oder fehlende Labels. Abgewickelt wird das über die Open-Source-Bibliothek @barrieretest/core.
Phase 2: KI-basierte Analyse (optional)
Wenn aktiviert, erstellt das System direkt im selben Browser einen Screenshot und extrahiert relevante HTML-Elemente. Diese Daten werden an ein Vision-Modell bei Nebius AI gesendet, das semantische Probleme erkennen kann, die technische Tools übersehen (z.B. unklare Beschriftungen, verwirrende Layouts, nicht passende ARIA-Labels). Schlägt dieser Schritt fehl, bleiben die technischen Ergebnisse davon unberührt.
Phase 3: Score-Berechnung & Ergebnis
Basierend auf den gefundenen Problemen wird ein Score von 0-100 berechnet. Das System interpretiert den Score und gibt Ihnen konkrete Handlungsempfehlungen.
Datenminimierung und Tracking
Der Dienst ist bewusst datensparsam gebaut: so wenig Tracking wie möglich, aber genug technische Verarbeitung, um Tests durchzuführen, Missbrauch zu begrenzen und Fehler zu finden.
- Keine Werbeprofile, kein Retargeting und keine versteckten Newsletter-Anmeldungen.
- Cookielose Reichweitenmessung mit Plausible für grobe Nutzungsstatistiken.
- Minimierte Server-Access-Logs ohne IP-Adresse, User-Agent, Referrer oder Query-String.
- Bei einem Test werden URL und IP-Adresse für Durchführung, Rate-Limiting und Zugriffsschutz verarbeitet.
- Personenbeziehbare Audit-Rohdaten werden grundsätzlich bis zu 30 Tage gespeichert und danach anonymisiert.
Welche Daten werden an die KI übertragen?
Die KI-Analyse ist optional. Wenn Sie sie aktivieren, werden folgende Daten an den KI-Anbieter (Nebius AI) übertragen:
Übertragene Daten:
- •Screenshot: Ein PNG-Bild Ihrer Website (1280x720 Pixel, nur oberhalb der Falz, kein Full-Page)
- •HTML-Kontext: Ausschnitte des HTML-Codes, um der KI Kontext zu geben (Details siehe unten)
- •URL: Die getestete URL (für Referenz im Ergebnis)
HTML-Kontext: Was genau wird extrahiert?
Um die KI-Analyse effizient zu halten, werden nur relevante Teile des HTML-Codes extrahiert. Folgende Limits gelten:
| Element-Typ | Limit | Beschreibung |
|---|---|---|
| <head> | 1.000 Zeichen | Anfang des <head>-Bereichs (Metadaten, Titel) |
| <body> | 8.000 Zeichen | Anfang des <body>-Bereichs (Hauptinhalt) |
| ARIA-Elemente | max. 50 Elemente | Elemente mit aria-label, aria-labelledby, etc. |
| Formular-Elemente | max. 50 Elemente | input, select, textarea, button |
| Bilder | max. 30 Elemente | <img>-Tags mit alt-Attributen |
| Landmarks | max. 50 Elemente | main, nav, aside, header, footer, [role] |
Diese Limits sind fest konfiguriert und wurden so gewählt, dass die KI-Analyse effizient und kostengünstig bleibt, während ausreichend Kontext für eine sinnvolle Analyse bereitgestellt wird.
Wie wird der Score berechnet?
Der Barrierefreiheits-Score reicht von 0 bis 100 Punkten. Die Berechnung basiert auf den gefundenen Problemen und deren Schweregrad.
Berechnungsformel
Jede Website beginnt mit der perfekten Punktzahl.
Nach 2 Vorkommen desselben Problems werden nur noch 50% der Punkte abgezogen. Dies verhindert, dass ein einziges wiederkehrendes Problem den Score zu stark drückt.
Der Score wird auf 5 Punkte begrenzt (oder 1 Punkt bei mehr als 100 Problemen).
Beispiel-Berechnungen
Szenario 1: Keine Probleme gefunden
Berechnung: 100 - 0 = 100
Ergebnis: 100 Punkte (Ausgezeichnet)
Szenario 2: 1 kritisches + 2 mittlere Probleme
Berechnung: 100 - 26 (kritisch) - 3 (mittel) - 3 (mittel) = 68
Ergebnis: 68 Punkte (Gut)
Szenario 3: 2 kritische + 5 schwerwiegende Probleme
Berechnung: 100 - 26 (kritisch #1) - 26 (kritisch #2) - 10×5 (schwerwiegend) = 48 - 50 = -2 → min. 5
Ergebnis: 5 Punkte (Schwerwiegend)
Was bedeutet mein Score?
Basierend auf Ihrem Score werden Sie in eine von fünf Kategorien eingeteilt, jeweils mit konkreten Handlungsempfehlungen:
Keine oder sehr wenige automatisch erkennbare Probleme. Regelmäßige manuelle Tests werden empfohlen.
Einige kleinere Probleme gefunden. Diese sollten behoben werden.
Mehrere Probleme gefunden. Ein professionelles Audit wird empfohlen.
Viele Probleme gefunden. Priorisieren Sie zentrale Nutzerflüsse zeitnah.
Sehr viele kritische Probleme. Starten Sie zeitnah mit einer fokussierten Prüfung und den wichtigsten Nutzerflüssen.
Aktuelle Einschränkungen
Wichtig: Automatisierte Tests können nur etwa 30-40% aller WCAG-Kriterien prüfen. Viele Aspekte der Barrierefreiheit erfordern manuelle Prüfungen oder Tests mit assistiven Technologien.
Eine praktische Checkliste für Unternehmen finden Sie im Solasit-Beitrag „Barrierefreie Website prüfen“.
Was kann NICHT automatisch geprüft werden?
- Semantische Korrektheit: Ob Überschriften logisch strukturiert sind und Inhalte sinnvoll beschreiben
- Alt-Text-Qualität: Ob Alt-Texte wirklich aussagekräftig sind (nicht nur ob sie vorhanden sind)
- Tastaturnavigation: Ob die Website vollständig per Tastatur bedienbar ist (Tab-Reihenfolge, Focus-Management)
- Screenreader-Kompatibilität: Wie gut die Website mit JAWS, NVDA, VoiceOver etc. funktioniert
- Verständlichkeit: Ob Texte einfach verständlich sind (Plain Language)
- Kognitive Barrierefreiheit: Ob die Navigation konsistent und vorhersehbar ist
Technische Einschränkungen
- Single-Page-Analyse: Es wird nur die angegebene URL getestet, nicht die gesamte Website
- Viewport: Der Screenshot wird in 1280x720 Pixeln erstellt (Desktop-Ansicht)
- JavaScript-Apps: Bei dynamisch geladenen Inhalten kann es zu Verzögerungen kommen
- Cookie-Banner: Das Tool versucht automatisch Cookie-Banner zu schließen, kann aber nicht alle Varianten erkennen
- KI-Limits: Nur die ersten 50 ARIA-Elemente, 50 Formular-Elemente, 30 Bilder und 50 Landmarks werden analysiert
Open Source & Transparenz
barrieretest.at nutzt folgende Open-Source-Technologien:
- @barrieretest/core (MIT) - Eigene Open-Source-Bibliothek, bündelt die Orchestrierung von axe-core-Tests und der semantischen KI-Analyse
- axe-core (MPL-2.0) - Engine für technische Barrierefreiheits-Prüfungen
- Puppeteer (Apache 2.0) - Browser-Automatisierung
- Next.js (MIT) - Frontend-Framework
- React (MIT) - UI-Library
Die Limits und Scoring-Logik wurden sorgfältig entwickelt, um eine ausgewogene Balance zwischen Genauigkeit, Performance und Kosteneffizienz zu gewährleisten.
Fragen oder Anmerkungen?
Wenn Sie Fragen zur Funktionsweise haben oder mehr über professionelle Barrierefreiheits-Audits erfahren möchten, kontaktieren Sie uns gerne:
Weitere Informationen: