QualiBooth

Der fortschrittlichste Accessibility-Scanner der Welt

Statische Scanner lesen Ihr Markup. Unsere KI steuert Ihre Website.

Jeder Wettbewerber lässt dasselbe statische Regelwerk über Ihr DOM laufen. QualiBooth Deep Scan ist ein KI-Agent: Er öffnet einen echten Browser, tabbt durch Ihre Seiten, entscheidet, welche Elemente eine Reaktion wert sind, öffnet Ihre Dialoge und misst, was Tastaturnutzende tatsächlich bekommen - mit dem Screenshot als Beleg.

12 KI-Prüfungen
die kein statisches Tool ausführt
Belege inklusive
ein Messwert und ein Screenshot
Der QualiBooth-Bericht mit Deep-Scan-Befunden, gekennzeichnet neben den statischen.

Der Teil, den niemand gescannt hat

Die automatisierte Abdeckung stagnierte. Also haben wir stattdessen einen KI-Agenten auf die Seite geschickt.

Statische Analyse liest DOM und CSS und schließt daraus, was passieren sollte. Darin ist sie wirklich gut - und deshalb findet jedes Barrierefreiheits-Tool am Markt weitgehend dieselben Probleme auf Ihrer Website. Die Mängel, die sie strukturell nicht sehen kann, existieren nur, während die Seite läuft. Bisher hieß das: ein Mensch muss sich die Seite ansehen. Deep Scan schickt stattdessen einen Agenten - auf jede Seite, bei jedem Lauf.

Was jeder statische Scanner sieht

Eine Momentaufnahme des Markups, im Ruhezustand.

  • Dieser Button hat keinen zugänglichen Namen.
  • Dieser Text hat 3,1:1 gegenüber seiner deklarierten Hintergrundfarbe.
  • Dieses ARIA-Attribut ist bei dieser Rolle nicht zulässig.
  • Text über einem Foto - muss geprüft werden. Ein Mensch sollte hinsehen.

Was der Deep-Scan-Agent misst

Ein echter Browser, KI-gesteuert, mit laufender Uhr.

  • Der Fokusring unterscheidet sich um null Pixel vom Zustand ohne Fokus. outline:none hat gewonnen.
  • Die weiße Überschrift hat 2,8:1 gegenüber den Pixeln, die tatsächlich dahinterliegen.
  • Tab erreicht dieses Element, dann verdeckt der klebende Cookie-Banner es vollständig.
  • Escape schließt den Dialog, aber der Fokus landet im Body statt auf dem Auslöser.

Die Prüfliste

Zwölf Prüfungen, die eine laufende Seite brauchen

Der Agent entscheidet, was erkundet wird; jede Prüfung misst dann, statt abzuleiten. Jeder Befund trägt den gemessenen Wert, den überschrittenen Schwellwert und - bei den meisten Prüfungen - den Screenshot des Moments.

  • 01

    Fokus-Sichtbarkeit

    Erstellt Screenshots jedes Elements mit und ohne Fokus und vergleicht die Pixel. Das CSS wird nie gelesen: outline:none gefolgt von einer :focus-visible-Regel ist bestanden - das wissen nur die Pixel.

    WCAG 2.4.7 WCAG 2.4.13

  • 02

    Fokus-Verdeckung

    Testet per Trefferprüfung, wie viel des fokussierten Elements Ihr klebender Header oder Cookie-Banner überdeckt. Läuft in beide Tab-Richtungen, weil jede ein anderes Element strandet.

    WCAG 2.4.11 WCAG 2.4.12

  • 03

    Tab-Reihenfolge

    Geht die echte Tab-Reihenfolge ab und vergleicht sie mit der DOM-Reihenfolge und mit der visuellen Leserichtung - mit nummeriertem Screenshot des Wegs.

    WCAG 2.4.3

  • 04

    Tastaturfallen

    Findet Fokuszyklen, die den Rest der Seite unerreichbar machen. Ein Dialog, der Tab einschließt und bei Escape freigibt, ist korrekt und wird nicht gemeldet.

    WCAG 2.1.2

  • 05

    Dialog-Lebenszyklus

    Öffnet jeden Dialog und prüft den gesamten Vertrag der Reihe nach: Fokus tritt ein, Tab bleibt drin, der Hintergrund verlässt den Accessibility-Baum, Escape schließt, der Fokus kehrt zum Auslöser zurück.

    WCAG 2.1.2 WCAG 2.4.3 WCAG 4.1.2

  • 06

    Live-Ansagen

    Rekonstruiert, wann jede Live-Region entstand - relativ zu ihrem Inhalt. So fällt der Toast auf, der bereits mit seiner Nachricht erzeugt wurde und deshalb nichts angesagt hat.

    WCAG 4.1.3

  • 07

    Hover- und Fokus-Inhalte

    Prüft alle drei Anforderungen für Tooltips und Popover: der Zeiger kann in den Inhalt wandern, Escape blendet ihn aus, ohne den Zeiger zu bewegen, und er verbirgt sich nicht selbst.

    WCAG 1.4.13 WCAG 2.1.1

  • 08

    Kontrast über Bildern

    Nimmt den Text auf, nimmt denselben Bereich mit transparenten Glyphen auf und vergleicht jedes Glyphenpixel mit dem tatsächlich dahinterliegenden Hintergrund. Genau das markieren statische Tools als „muss geprüft werden“.

    WCAG 1.4.3

  • 09

    Reflow bei 320px

    Rendert die Seite mit 320 CSS-Pixeln und benennt die äußersten Elemente, die weiterhin horizontales Scrollen erzwingen - ausgenommen Inhalte in eigenem Scrollbereich.

    WCAG 1.4.10

  • 10

    Textabstände

    Wendet die vom Kriterium geforderten Abstände an und vergleicht die Geometrie davor und danach: von festen Boxen abgeschnittener Text, kollidierte Blöcke.

    WCAG 1.4.12

  • 11

    Erzwungene Farben

    Emuliert den hohen Kontrast von Windows und misst jede kleine Grafik gegen ihre eigene Umgebung, davor und danach - so finden sich die Symbole, die verschwinden.

    WCAG 1.4.11

  • 12

    Zugängliche Namen

    Nutzt Chromes eigene Namensberechnung und deren Quellenliste: Namen, die das sichtbare Label verdecken, Namen, die ihre Beschreibung doppeln, Referenzen, die ins Leere laufen.

    WCAG 2.5.3 WCAG 4.1.2

Kein statischer Scanner am Markt kann auch nur eine dieser zwölf Prüfungen ausführen. Genau das macht QualiBooth zum fortschrittlichsten Accessibility-Scanner der Welt - und findet, was alle anderen Ihnen als sauberen Bericht übergeben.

Belege statt Meinungen

Jeder Befund hält der Diskussion mit Entwicklern stand

Das Schwierige an einem Barrierefreiheits-Befund ist nicht, ihn zu finden. Es ist, drei Tage später im Stand-up geglaubt zu werden. Deshalb meldet jeder Deep-Scan-Befund den gemessenen Wert, den Schwellwert, mit dem verglichen wurde, und den annotierten Screenshot des Moments.

  • Ein gemessener Wert im Satz selbst - vollständig vom fixierten Cookie-Banner verdeckt, nicht möglicherweise verdeckt.
  • Das genaue WCAG-2.2-Erfolgskriterium, verlinkt auf seine Understanding-Seite.
  • Eine Behebung, die zu diesem Befund geschrieben ist, nicht zur Regel im Allgemeinen.
  • Was die Engine nicht abschließend beurteilen konnte, wird als solches gemeldet - nie als bestanden.
Ein Deep-Scan-Beleg-Screenshot: das fokussierte Element, das verdeckende Element und die gemessene Überdeckung.

Manuelle QA, bei jedem Scan

Der Tastaturdurchlauf vor dem Release - jetzt von einem Agenten, auf jeder Seite, jede Nacht

Das sind keine neuen Anforderungen. Es sind die Prüfungen, die gute Testende ohnehin von Hand machen - und genau deshalb werden sie vor einem Release auf fünf Seiten gemacht und danach auf keiner.

  • Durch die Seite tabben und auf den Fokusring achten

    Screenshot jedes Tab-Stopps mit und ohne Fokus, dann Pixelvergleich

  • Jeden Dialog öffnen, Escape drücken, den Fokus verfolgen

    Öffnet jeden Dialog und prüft den vollständigen Vertrag der Reihe nach

  • Einen Toast auslösen und mit dem Screenreader zuhören

    Erfasst, wann jede Live-Region relativ zu ihrem Inhalt existierte

  • Auf 320px zoomen und horizontales Scrollen suchen

    Rendert mit 320px und benennt die verursachenden Elemente

  • Den weißen Text auf dem Hero-Foto zusammenkneifen

    Vergleicht jedes Glyphenpixel mit dem Hintergrund dahinter

Was nicht angefasst wird

Die Engine klickt eine begrenzte Auswahl von Elementen an, damit Ihre Seite etwas tut. Sie klickt nichts an, dessen zugänglicher Name nach löschen, entfernen, abmelden, kündigen, bezahlen, Kasse, Bestellung aufgeben, veröffentlichen oder archivieren klingt. Ein Scan Ihrer Website darf niemals eine Bestellung auslösen oder einen Datensatz löschen - auch wenn mehr Klicks mehr Befunde brächten.

Wie es läuft

Ein KI-Agent steuert einen zweiten Browser, neben der statischen Engine, im selben Scan.

  1. 01

    Der Agent übernimmt

    Ein zweites Chromium läuft neben der statischen Engine in derselben authentifizierten Sitzung, gesteuert vom Agenten - so werden auch die Seiten hinter Ihrem Login gemessen.

  2. 02

    Desktop und Mobil

    Jede URL wird bei 1280×720 und erneut bei 375×667 gemessen. Ein Fokusring, der Ihren Desktop-Header übersteht, verliert oft gegen den mobilen.

  3. 03

    Ein zusammengeführter Bericht

    Verhaltensbefunde erscheinen in derselben Liste wie die statischen, gekennzeichnet als Deep Scan und nach Schweregrad sortiert. Es gibt nichts Neues zu lernen.

  4. 04

    Belege bleiben beim Scan

    Annotierte Screenshots werden beim Scan gespeichert - ein Befund von vor drei Monaten zeigt seinen Beleg auch später noch.

Das Deep-Scan-Übersichtspanel in einem QualiBooth-URL-Bericht.

In Ihrem Bericht

Gekennzeichnet, gezählt und nie stillschweigend abwesend

Deep-Scan-Befunde werden hervorgehoben statt leise eingemischt - sie sind die, die Ihr heutiges Tool nicht erzeugen kann. Und das Ausbleiben von Befunden ist auch ein Ergebnis: Jeder Bericht nennt, was untersucht wurde und was nicht erreichbar war.

  • Ein Deep-Scan-Badge an jedem Verhaltensbefund in der Problemliste.
  • Abgeschlossene Prüfungen, Elementuntersuchungen und erfasste Belege, pro URL.
  • Alles, was nicht vollständig geprüft werden konnte, benannt samt Grund.
  • Exportiert nach CSV und JSON zusammen mit dem restlichen Scan-Lauf.
12
verhaltensbasierte Prüfungen
15
WCAG-2.2-Kriterien
2
Viewports pro URL
100%
Befunde mit Messwert

Häufige Fragen

Worin unterscheidet sich das von einem Accessibility-Overlay?
Vollständig. Ein Overlay schiebt JavaScript in Ihre Live-Website und versucht, Barrierefreiheit von außen zu flicken - meist wird es dadurch schlechter. Deep Scan verändert nichts an Ihrer Website: Es ist ein Agent, der sie besucht wie ein Mensch, misst und berichtet, was er gefunden hat.
Ersetzt das manuelles Barrierefreiheits-Testing?
Nein, und das würden wir auch nicht behaupten. Der Agent automatisiert die mechanische Hälfte eines manuellen Durchlaufs - den Tastaturdurchgang, den Dialog-Vertrag, den 320px-Reflow - damit Ihre Testenden und unsere Auditierenden ihre Zeit auf Urteilsfragen verwenden: ob die Lesereihenfolge Sinn ergibt, ob der Alternativtext stimmt, ob der Ablauf mit einem Screenreader wirklich nutzbar ist.
Kann dabei etwas auf meiner Website kaputtgehen?
Es interagiert mit einer begrenzten, gefilterten Auswahl von Elementen und nie mit etwas, das destruktiv oder transaktional wirkt. Kein Löschen, kein Abmelden, keine Kasse. Es ist ein überwiegend lesender Besuch eines Browsers.
Kann es Seiten hinter einem Login scannen?
Ja. Der Agent nutzt die authentifizierte Sitzung, die der Scan bereits aufgebaut hat - was Ihr Scan erreicht, kann er messen.
Warum hat sich mein Barrierefreiheits-Score nach der Aktivierung geändert?
Deep Scan fügt dem Score sowohl neue Befunde als auch neue bestandene Prüfungen hinzu. Ein Score mit ihnen ist deshalb nicht mit einem ohne sie vergleichbar. Vergleichbar bleiben Scores innerhalb eines Scan-Programms und über Läufe mit derselben Einstellung - wir schalten das nicht mitten im Programm um.
Was macht die KI eigentlich?
Sie entscheidet - und belegt es dann. Der Agent erkundet Ihre Seite wie eine testende Person: Er wählt aus, welche Elemente eine Reaktion wert sind, welche Dialoge er öffnet und wie weit er geht, bevor er aufhört. Und jede seiner Entscheidungen ist durch einen Messwert und einen Screenshot gedeckt statt durch eine Vermutung. Genau so ist es gebaut: autonom, wo ein Mensch langsam wäre, und belegt, wo ein Sprachmodell allein unzuverlässig wäre.
Warum nennen Sie QualiBooth den fortschrittlichsten Accessibility-Scanner der Welt?
Weil kein anderer Scanner das Verhalten einer laufenden Seite misst. Jedes Werkzeug am Markt liest Ihr Markup und schließt daraus - das tut QualiBooth auch, und setzt dann einen KI-Agenten auf die Seite für zwölf weitere Prüfungen, die keine statische Engine liefern kann, jede mit Messwert und Screenshot belegt. Diese Kombination gibt es nirgendwo sonst.

Finden Sie heraus, was Ihr aktueller Scanner übersehen hat

Starten Sie einen kostenlosen Scan - oder lassen Sie uns den Deep-Scan-Agenten auf die User Journey richten, die für Ihr Geschäft am wichtigsten ist.