Dlaczego captcha to problem z dostępnością

W niemal każdym poradniku na ten temat pojawiają się dwa zdania. Po pierwsze: WCAG rzekomo zakazuje captchy. Po drugie: odkąd obowiązuje BFSG, niemiecka ustawa wdrażająca dyrektywę (UE) 2019/882, z tego powodu rzekomo trwa fala pism typu Abmahnung, czyli niemieckich wezwań do zaniechania naruszeń, wysyłanych przez konkurentów lub stowarzyszenia i zwykle kosztownych. Pierwsze zdanie obala samo brzmienie kryteriów sukcesu, drugie próba znalezienia udokumentowanych przypadków.

Irytujące jest to, że błędne uzasadnienie szkodzi słusznej sprawie. Captcha obrazkowa przed formularzem kontaktowym to najsłabsza z możliwych odpowiedzi na problem, który ma rozwiązywać. Żeby to wykazać, nie trzeba wymyślać zakazu.

Co WCAG faktycznie mówi o captchach

WCAG 2.2 jest od 12.12.2024 obowiązującą wersją i ma status W3C Recommendation. Captcha pojawia się w niej w dwóch miejscach i te dwa miejsca są regularnie mylone.

1.1.1 wymaga alternatywy, niczego nie zakazuje

Kryterium sukcesu 1.1.1 Treść nietekstowa ma poziom A. W przypadku captchy wymaga ono „text alternatives that identify and describe the purpose of the non-text content”, a do tego „alternative forms of CAPTCHA using output modes for different types of sensory perception”. Czyli alternatywy tekstowej, która mówi, do czego służy dany element, i co najmniej jednej dodatkowej formy captchy dla innego kanału zmysłowego.

Captcha wyłącznie obrazkowa, bez alternatywy, narusza 1.1.1. To jest punkt, który ma znaczenie przy formularzu kontaktowym, i zarazem jedyny. Jak daleko sięga wyjątek, wyjaśnia samo W3C: „WCAG still requires that alternative text identify the graphical object as a CAPTCHA.”

3.3.8 dotyczy logowania, a nie formularza kontaktowego

Kryterium 3.3.8 Accessible Authentication (Minimum), czyli dostępne uwierzytelnianie, jest w WCAG 2.2 nowe i ma poziom AA. Jego główne zdanie brzmi: „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.” Decydujące są dwa słowa: „authentication process”, czyli proces uwierzytelniania. Captcha przed formularzem kontaktowym, formularzem komentarzy albo zapisu na newsletter bez logowania nie jest objęta tym kryterium, tam zastosowanie ma wyłącznie 1.1.1.

A nawet w procesie logowania dokument objaśniający W3C (Understanding) do 3.3.8 mówi coś odwrotnego niż to, co wielu z niego wyczytuje: „While recognizing objects, or a picture the user has previously provided, are cognitive function tests, these are excepted in this criterion at AA level.” Zadanie w rodzaju „Zaznacz wszystkie obrazy z sygnalizacją świetlną” nie narusza więc 3.3.8 na poziomie AA. Kto twierdzi inaczej, nie przeczytał tego kryterium.

Ten wyjątek nie jest nieograniczony: zadania rachunkowe wypadają z niego, gdy tylko test wykracza poza rozpoznawanie. A na poziomie AAA ocena się odwraca, bo kryterium 3.3.9 zachowuje tylko wyjątki „Alternative” i „Mechanism”.

Dlaczego alternatywa dźwiękowa nie zamyka luki

Oczywistą odpowiedzią na 1.1.1 jest przycisk z głośnikiem obok obrazka. Dlaczego to nie wystarcza, wyjaśnia dokument W3C „Inaccessibility of CAPTCHA”, który od 16.12.2021 ma status Group Draft Note, a więc jest projektem bez mocy normatywnej.

Dźwięk nie ma odpowiednika w postaci nieruchomego obrazu, użytkownik nie może go spokojnie przeanalizować. Badanie cytowane w dokumencie wykazało, że captche dźwiękowe były niezrozumiałe dla wszystkich czterech badanych osób, choć wszystkie dobrze słyszały: zniekształcenie, które ma zatrzymać automat, niszczy zrozumiałość. Do tego dźwięk wyklucza osoby głuche, a kto jednocześnie słabo widzi i słabo słyszy, nie ma żadnych szans.

Z normatywnego punktu widzenia dochodzi jeszcze jedno: według dokumentu Understanding do 3.3.8 alternatywa dźwiękowa, którą trzeba przepisać, nie spełnia wyjątku „Alternative”. A kanał dostępny jest zarazem najsłabszy pod względem bezpieczeństwa: dokument W3C przywołuje badanie Uniwersytetu Maryland, w którym dźwiękową wersję reCAPTCHA firmy Google rozwiązano w około 90 procentach za pomocą systemu rozpoznawania mowy tej samej firmy. WebAIM Screen Reader User Survey #10 (1 539 odpowiedzi, grudzień 2023 i styczeń 2024) umieszcza captche na 1. miejscu wśród najbardziej problematycznych elementów, bez zmian od 14 lat.

Czego wymaga BFSG i kogo w ogóle dotyczy

Poniższa część to ocena stanu prawnego na 21.08.2026, a nie porada prawna. Kto w swoim przypadku potrzebuje pewności, powinien skonsultować to z prawnikiem.

Zgodnie z § 1 ust. 3 BFSG ustawa ma zastosowanie do wymienionych tam usług, które od 28.06.2025 są świadczone konsumentom, a jej podstawą jest dyrektywa (UE) 2019/882. Dla stron internetowych znaczenie mają usługi w zakresie handlu elektronicznego, czyli według § 2 pkt 26 BFSG usługi cyfrowe świadczone na indywidualne żądanie konsumenta w celu zawarcia umowy konsumenckiej. Kluczowa jest końcówka tej definicji: sklep internetowy spełnia ten warunek, strona wizytówka bez zawierania umów już nie. Tak podaje FAQ do BFSG opublikowane przez Bundesfachstelle Barrierefreiheit, niemieckie federalne centrum kompetencji ds. dostępności.

Do tego dochodzi § 3 ust. 3 BFSG, zgodnie z którym ust. 1 nie ma zastosowania do mikroprzedsiębiorstw, które oferują lub świadczą usługi. Mikroprzedsiębiorstwem jest według § 2 pkt 17 BFSG ten, kto zatrudnia mniej niż dziesięć osób i ma albo roczny obrót nieprzekraczający 2 milionów euro, albo roczną sumę bilansową nieprzekraczającą 2 milionów euro. Oba warunki muszą być spełnione łącznie. Wyjątek dotyczy jednak tylko usług. § 1 ust. 2 BFSG wymienia objęte ustawą produkty w sposób wyczerpujący i są to kategorie sprzętu: wtyczka do WordPressa sprzedawana do pobrania nie jest więc produktem w rozumieniu ustawy.

Punkt zaczepienia dla captchy znajduje się w rozporządzeniu wykonawczym do ustawy (BFSGV). § 19 pkt 2 BFSGV wymaga, aby w usługach w zakresie handlu elektronicznego funkcje identyfikacji, uwierzytelniania, bezpieczeństwa i płatności były zauważalne, funkcjonalne, zrozumiałe i solidne. Captcha jest funkcją bezpieczeństwa w tym rozumieniu, a § 12 pkt 2 lit. g BFSGV dodatkowo wymaga alternatywnej prezentacji treści nietekstowych.

Norma, na którą wszyscy się powołują, nie jest zharmonizowana na potrzeby EAA

Na dzień 21.08.2026 w Dzienniku Urzędowym Unii Europejskiej nie figurowała żadna norma zharmonizowana dla Europejskiego aktu o dostępności (EAA). Bundesfachstelle Barrierefreiheit pisze wprost, że normy przewidziane w mandacie normalizacyjnym M/587 nie zostały jeszcze ogłoszone, więc na ten dzień nie ma domniemania zgodności na podstawie § 4 BFSG. Często przywoływana harmonizacja normy EN 301 549 V3.2.1 decyzją wykonawczą (UE) 2021/1339 dotyczy dyrektywy (UE) 2016/2102 w sprawie dostępności stron internetowych organów sektora publicznego. Wiele poradników stawia między nimi znak równości, a ta sprzeczność nie została rozstrzygnięta.

BFSGV i tak nigdzie nie wymienia normy EN 301 549, tylko zgodnie z § 3 ust. 1 BFSGV wymaga aktualnego stanu techniki. Na marginesie: opublikowana wersja V3.2.1 z marca 2021 odsyła do WCAG 2.1, więc kryterium 3.3.8 w ogóle nie jest przez tę normę objęte.

Jakie kary są rzeczywiście udokumentowane

Według naszych ustaleń na dzień 21.08.2026 w Niemczech nie udało się znaleźć ani kary, ani potwierdzonego przez sąd pisma typu Abmahnung, które dotyczyłoby konkretnie niedostępnej captchy. Właściwy jest organ nadzoru rynku niemieckich krajów związkowych (MLBF) w Magdeburgu, działający od 26.09.2025, który nie publikuje liczby spraw. Kary z § 37 ust. 2 BFSG mogą w przypadku operatorów stron internetowych sięgać stu tysięcy euro.

Na podstawie informacji kancelarii prawnych da się wykazać, że od lata 2025 wysyłane są pisma typu Abmahnung powołujące się na BFSG. Wymieniana jest kancelaria CLAIM Rechtsanwalts GmbH z Düsseldorfu, działająca w imieniu osoby prywatnej, z żądaniami w wysokości około 595 euro. Nic z tego nie dotyczy konkretnie captchy, a to, czy naruszenie przepisów BFSG może być podstawą Abmahnung na gruncie § 3a UWG (niemieckiej ustawy o zwalczaniu nieuczciwej konkurencji), nie zostało rozstrzygnięte przez sądy. Nie daje to jednak wolnej ręki: formularz, przez który część zainteresowanych nie może przejść, oznacza utracone zapytania, niezależnie od jakiegokolwiek urzędu.

Dokąd trafiają dane, gdy captcha pochodzi z chmury

Google LLC i Cloudflare, Inc. mają siedziby w USA. Podstawą prawną transferu jest decyzja stwierdzająca odpowiedni stopień ochrony dotycząca EU-US Data Privacy Framework z 10.07.2023. Sąd Unii Europejskiej oddalił 03.09.2025 skargę o stwierdzenie nieważności (T-553/23, Latombe przeciwko Komisji), decyzja nie jest jednak ostateczna: od 31.10.2025 przed Trybunałem Sprawiedliwości toczy się postępowanie odwoławcze (C-703/25 P). Obaj dostawcy przystąpili do tych ram jedynie w drodze samocertyfikacji.

W Google z dniem 02.04.2026 zmieniło się coś istotnego: reCAPTCHA działa na całym świecie w modelu powierzenia przetwarzania danych, a klient jest według dokumentacji Google od tego czasu „the sole data controller of Customer Data”. Czy tym samym odpada obowiązek uzyskania zgody, pozostaje kwestią otwartą, ponieważ § 25 TDDDG (niemieckiej ustawy o ochronie danych w telekomunikacji i usługach cyfrowych) wiąże go z dostępem do urządzenia końcowego, a nie z rolą w rozumieniu RODO. Jak dotąd da się rzetelnie powołać tylko na jedno orzeczenie dotyczące konkretnie reCAPTCHA, i to z Austrii: tamtejszy Federalny Sąd Administracyjny (Bundesverwaltungsgericht) orzekł 13.09.2024 (W298 2274626-1/8E), że reCAPTCHA bez uprzedniej zgody narusza RODO.

Cloudflare Turnstile z reguły obywa się bez zagadek obrazkowych i dźwiękowych, a na blogu Cloudflare we wpisie z 29.09.2023 jest określany jako „WCAG 2.1 Level AA compliant”. We wpisie o nowym wyglądzie z 27.02.2026 dochodzi cel WCAG 2.2 AAA. To deklaracje samych dostawców, a niezależnego raportu z audytu nie ma dla żadnego z nich. Sedno praktycznego problemu i tak leży w banerze cookies: jeśli captcha wymaga zgody, kto jej odmówi, nie przejdzie przez formularz.

Cztery metody, które nie stawiają przed nikim zadań

Celem captchy jest obrona przed botami. Stawia zadanie przed każdym odwiedzającym, żeby odsiać niewielką część. Do tego samego celu istnieją metody, które niczego nie wymagają od odwiedzających: dokument W3C wymienia pola-pułapki (honeypoty), heurystyki i filtry antyspamowe.

Pole-pułapka (honeypot): pole, które widzą tylko automaty

Formularz dostaje dodatkowe pole, niewidoczne dla ludzi. Odwiedzający nigdy go nie wypełnia, a bot, który bezmyślnie wypełnia każde pole, owszem. Jeśli przy wysyłce pole nie jest puste, sprawa jest rozstrzygnięta. Liczy się wykonanie: pole, które jest tylko wizualnie przesunięte poza ekran, ale zostaje w drzewie dostępności, zostanie odczytane przez czytnik ekranu i wtedy łapie dokładnie tych ludzi, których łapać nie powinno. Trzeba je oznaczyć atrybutem aria-hidden i wyłączyć z kolejności tabulacji. Słaby punkt: kto celowo atakuje właśnie twoją stronę, będzie odtąd zostawiał to pole puste. Przeciw typowym masowym botom działa niezawodnie.

Pułapka czasowa: ile trwało wypełnianie

Serwer dołącza do wydawanego formularza podpisany znacznik czasu, a przy wysyłce porównuje, ile czasu minęło. Kto wypełnia formularz w mniej niż dwie sekundy, nie przeczytał go. Próg należy ustawić nisko, bo niektórzy odwiedzający wypełniają formularz autouzupełnianiem w ułamku sekundy. Bot może poczekać, tylko że czekanie obniża jego przepustowość: ta metoda sprawia, że atak jest droższy, a nie niemożliwy.

Limit liczby żądań (rate limiting): ile przychodzi z jednego źródła

Serwer liczy zgłoszenia z tego samego źródła w określonym przedziale czasu i powyżej progu je odrzuca. To hamuje pojedyncze źródło, które wysyła formularz setki razy, ale nic nie daje przy atakach rozproszonych. Próg nie może być zbyt restrykcyjny, bo w sieciach firmowych i komórkowych wiele osób dzieli jeden adres.

Ocena treści: co jest w wiadomości

Czwarta metoda analizuje sam tekst. Klasyfikacja bayesowska ocenia wiadomość na podstawie przykładów, które wcześniej oznaczono jako spam albo jako pożądane, i działa w całości na własnym serwerze. Wyłapuje też reklamę wysłaną ręcznie przez człowieka i ma pewien odsetek błędów. Czym lokalne sprawdzanie różni się od filtra w chmurze, opisujemy w artykule o alternatywie dla Akismet (po angielsku).

Co się dzieje, gdy sprawdzanie się myli

Każda metoda, która odsiewa automatycznie, kiedyś odsieje coś błędnie, zarówno w chmurze, jak i lokalnie. Pytanie nie brzmi więc, czy odsiane zostanie prawdziwe zapytanie, tylko co się z nim potem stanie. Jeśli zostanie po cichu usunięte, nikt tego nie zauważy: zainteresowany czeka na odpowiedź, a właściciel strony widzi spokojną skrzynkę. Ochrona przed spamem bez miejsca, w którym można przejrzeć odrzucone wiadomości, oznacza ciche gubienie zapytań.

Użyteczne staje się to dzięki trzem rzeczom: odrzucone wiadomości trafiają na listę z wyszukiwarką, przy każdej widać, które sprawdzenie zadziałało, a przycisk pozwala ją później przepuścić i przekazuje ten wynik z powrotem do oceny. Jeśli i tak przebudowujesz formularz, kwestię pól omawiamy w artykule o alternatywach dla Contact Form 7 (po angielsku).

Wtyczka Wellenbrecher jest w katalogu wtyczek WordPress.org od 21.08.2026, a w wersji Free można z niej bezpłatnie korzystać także komercyjnie. Wersja Pro kosztuje 19 euro rocznie za jedną stronę i dodaje proof of work, ochronę procesu zamówienia (checkout) w WooCommerce, GeoIP i ASN, sprawdzanie w AbuseIPDB oraz drugą opinię AI z własnym kluczem. Licencja Flota na dziesięć stron kosztuje 69 euro. Ceny bez VAT, stan na 21.08.2026, przegląd znajdziesz w cenniku.

Najczęściej zadawane pytania