CAPTCHA und Barrierefreiheit: was die WCAG und das W3C sagen

Warum ist ein CAPTCHA ein Problem für die Barrierefreiheit?

Weil eine Aufgabe eine Fähigkeit voraussetzt: sehen, hören, lesen, sich erinnern, genau zielen. Ein CAPTCHA, das nur auf einer davon beruht, versperrt den Personen die Tür, denen sie fehlt, genau dort, wo der Besucher schreiben, sich registrieren oder sich anmelden will.

Siehe: Glossar: CAPTCHA

Was sagen die WCAG 2.2 zum CAPTCHA?

Die WCAG 2.2 sind eine Empfehlung des W3C, erstmals veröffentlicht am 5. Oktober 2023; die hier gelesene Fassung ist die vom 12. Dezember 2024. Zwei ihrer Kriterien betreffen das CAPTCHA. Die Zitate unten sind der englische Originaltext, der massgeblich ist; eine deutsche Übersetzung dieser Fassung haben wir beim W3C nicht gefunden. Nach jedem Zitat steht sein Sinn auf Deutsch.

Das Erfolgskriterium 1.1.1, «Non-text Content» (Nicht-Text-Inhalt, Stufe A), verlangt für jeden Nicht-Text-Inhalt eine Textalternative, ausser in den Situationen, die es aufzählt. Die des CAPTCHA: “If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.” Sinngemäss: Dient ein Nicht-Text-Inhalt dazu zu bestätigen, dass eine Person und kein Computer auf die Inhalte zugreift, so sind Textalternativen vorhanden, die den Zweck des Inhalts benennen und beschreiben, und es werden alternative CAPTCHA-Formen für verschiedene Sinneswahrnehmungen angeboten, um unterschiedlichen Behinderungen gerecht zu werden.

Das Erfolgskriterium 3.3.8, «Accessible Authentication (Minimum)» (Barrierefreie Authentifizierung, Minimum, Stufe AA): “A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:” Sinngemäss: Ein kognitiver Funktionstest (etwa sich ein Passwort merken oder ein Rätsel lösen) wird in keinem Schritt eines Authentifizierungsprozesses verlangt, ausser dieser Schritt bietet mindestens eines der Folgenden (jedes wird in der Norm mit seinem Namen eingeleitet):

• Alternative: “Another authentication method that does not rely on a cognitive function test.” Sinngemäss: eine andere Authentifizierungsmethode, die nicht auf einem kognitiven Funktionstest beruht.
• Mechanism: “A mechanism is available to assist the user in completing the cognitive function test.” Sinngemäss: ein Mechanismus hilft der Person, den Test zu bestehen.
• Object Recognition: “The cognitive function test is to recognize objects.” Sinngemäss: Der Test besteht darin, Objekte zu erkennen.
• Personal Content: “The cognitive function test is to identify non-text content the user provided to the website.” Sinngemäss: Der Test besteht darin, einen Nicht-Text-Inhalt zu erkennen, den die Person der Website geliefert hat.

Das Erläuterungsdokument des W3C leitet daraus ab: Ist ein CAPTCHA Teil einer Authentifizierung, muss es eine Methode ohne kognitiven Funktionstest geben, ausser der Test fällt unter eine Ausnahme. Objekterkennung und persönliche Inhalte sind Ausnahmen auf Stufe AA, aber nicht auf Stufe AAA (Kriterium 3.3.9), und das Dokument empfiehlt, sie wenn möglich zu vermeiden. Eine Audio-Alternative, die abgeschrieben werden muss, erfüllt die Ausnahme «Alternative» nicht.

Das Kriterium 3.3.8 betrifft die Anmeldung an einem bestehenden Konto: Das Erläuterungsdokument hält fest, dass es weder das Anlegen eines Benutzernamens noch das Eröffnen eines Kontos abdeckt. Das Kriterium 1.1.1 betrifft den Nicht-Text-Inhalt eines CAPTCHA, wo auch immer er steht, auch in einem Kontaktformular.

Was sagt das W3C zu den Alternativen?

Die Arbeitsgruppe des W3C für Barrierefreiheit (Accessible Platform Architectures) hat eine Note verfasst, «Inaccessibility of CAPTCHA», auf Englisch. Die gelesene Fassung ist ein Entwurf der Note vom 16. Dezember 2021: Weder das W3C noch seine Mitglieder haben sie gebilligt, und das Dokument hält fest, dass man sie nur als laufende Arbeit zitieren soll. Ihre Schlussfolgerungen, zusammengefasst:

• Ein Besucher sollte nicht mehr Aufgaben bewältigen müssen, als es die Sicherheit der Website unbedingt verlangt;
• Wird ein interaktives CAPTCHA für nötig gehalten, ist es sehr nützlich, die Häufigkeit, mit der es gezeigt wird, so weit wie möglich zu begrenzen, und es müssen mehrere alternative Aufgaben angeboten werden, die verschiedene sensorische und kognitive Fähigkeiten ansprechen;
• Das W3C bevorzugt Ansätze ohne Interaktion, die keine Hürde für die Barrierefreiheit darstellen; sie können die Person aber einer Erhebung personenbezogener Daten aussetzen;
• Es gibt keine einzige ideale Lösung: Zweck und Wirksamkeit jedes eingesetzten CAPTCHA müssen vor der Einführung geprüft und danach genau beobachtet werden.

Was tun, konkret?

• Entfernen Sie die Aufgabe, wenn Sie können: Prüfung auf dem Server, Begrenzung der Übermittlungen und eine unsichtbare Bot-Prüfung (man spricht manchmal von einem «unsichtbaren CAPTCHA») verlangen vom Besucher nichts.
• Wenn Sie ein CAPTCHA behalten, bieten Sie mehrere Arten von Aufgaben an, und bei einem Login eine Möglichkeit, darauf zu verzichten.
• Bieten Sie einen anderen Weg an, Sie zu erreichen, wenn eine Übermittlung abgelehnt wird: zum Beispiel eine E-Mail-Adresse.
• Testen Sie nur mit der Tastatur und mit einem Screenreader, und verfolgen Sie nach der Inbetriebnahme die zu Unrecht abgelehnten Besucher.
• Sehen Sie nach, was eine Prüfung ohne Aufgabe misst: Das W3C erinnert daran, dass sie personenbezogene Daten preisgeben kann.

Siehe: Glossar: unsichtbares CAPTCHA · Häufige Fragen: Kann Antisy echte Besucher blockieren? · Dokumentation: erhobene Daten und Datenschutz

Wo Antisy in diesem Ablauf steht

Antisy zeigt dem Besucher nichts an: weder ein Kästchen zum Ankreuzen noch ein Rätsel. Es gibt also keine Aufgabe, die barrierefrei gemacht werden müsste. Das macht ein Formular aber nicht barrierefrei, und Antisy sagt nicht, dass Ihr Formular die WCAG erfüllt: Die Beschriftungen, die Kontraste und die Tastaturbedienung bleiben die Ihres Formulars.

Die Prüfung hat ihre eigenen Grenzen, die die Website nennt. Der Browser führt eine kurze Berechnung im Hintergrund aus: Ein sehr langsames Gerät, das sie nicht rechtzeitig beendet, wird abgelehnt, in jedem Modus. Ist das Script blockiert, wird das Formular ohne Token gesendet, und eine Übermittlung ohne Token wird nicht durchgelassen, wenn die Browser-Erfassung für die Website eingeschaltet ist. Die Antwort ist allow oder deny, ohne Grund: Sie müssen selbst eine Seite für die Ablehnung vorsehen, die einen anderen Weg bietet, Sie zu erreichen.

Antisy nennt keine Erkennungsrate.

Siehe: Häufige Fragen: Was ist der Unterschied zwischen Antisy und einem CAPTCHA? · Glossar: Berechnung im Hintergrund · Dokumentation: wenn das Script nicht läuft · Dokumentation: ein echter Besucher wird abgelehnt · Dokumentation: wie streng ablehnen · Startseite: was das Script misst und wie lange

Stand des Angebots

Der Zugang erfolgt über eine Warteliste. Die API und das Dashboard sind seit dem 27. Oktober 2026 in Betrieb, gehostet bei Infomaniak in Genf; noch ist kein Kunde in Produktion. Das Pilotprojekt hat am 9. November 2026 mit unseren eigenen Formularen begonnen.

Siehe: Das Pilotprojekt · Der Warteliste beitreten

Häufige Fragen