Dostępne formularze kontaktowe a Europejski akt o dostępności

Formularz kontaktowy to często jedyne drzwi między odwiedzającym a Twoją firmą. Jeśli da się je otworzyć tylko myszką, przy dobrym wzroku i z cierpliwością do rozmazanej obrazkowej łamigłówki, część osób po prostu zostaje na zewnątrz. Od połowy 2025 roku to już nie tylko kwestia wygody: dla wielu firm sprzedających konsumentom w UE stało się to kwestią prawną.

Czego dotyczy Europejski akt o dostępności

Europejski akt o dostępności (dyrektywa (UE) 2019/882), w skrócie EAA, obowiązuje od 28 czerwca 2025 roku. Określa wymagania dostępności dla niektórych produktów i usług oferowanych konsumentom – m.in. handlu elektronicznego, usług bankowych dla konsumentów, e-booków, łączności elektronicznej i części usług transportu pasażerskiego. W przypadku strony internetowej chodzi o cały sklep internetowy lub usługę bankową, łącznie z formularzami, przez które klienci się z Tobą kontaktują, zadają pytania albo składają reklamacje. Zwolnione są mikroprzedsiębiorstwa świadczące usługi: firmy zatrudniające mniej niż dziesięć osób, których roczny obrót lub suma bilansowa nie przekracza 2 mln euro. Oferty skierowane wyłącznie do firm z reguły nie są objęte tymi przepisami.

Każde państwo członkowskie przeniosło dyrektywę do prawa krajowego. W Niemczech jest to ustawa Barrierefreiheitsstärkungsgesetz (BFSG), w Polsce – ustawa z 2024 roku o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług. Właściwe organy i sankcje różnią się w zależności od kraju, ale techniczny punkt odniesienia jest w dużej mierze ten sam: w praktyce europejska norma EN 301 549, która z kolei opiera się na wytycznych WCAG (Web Content Accessibility Guidelines).

Dlaczego warto, nawet jeśli nie musisz

Może Twoja firma jest zwolniona albo obsługujesz wyłącznie innych przedsiębiorców. Dostępne formularze i tak się opłacają, z prostego powodu: każda osoba, która zrezygnuje w połowie, to zapytanie, które nigdy do Ciebie nie dotrze. To, co pomaga użytkownikom czytników ekranu, pomaga też komuś, kto wypełnia formularz na telefonie w pociągu, w pełnym słońcu, ze złamanym nadgarstkiem albo w obcym języku. Czytelne etykiety i pomocne komunikaty o błędach oznaczają mniej porzuconych formularzy u wszystkich – a żadna z tych zmian nie osłabia ochrony przed spamem.

Praktyczna lista kontrolna z odniesieniami do WCAG 2.2

• Widoczne etykiety powiązane z polami (1.3.1, 3.3.2): każde pole ma widoczną etykietę połączoną z nim przez for/id. Sam placeholder to nie etykieta – znika, gdy tylko zaczniesz pisać.
• Komunikaty o błędach, które mówią, jak to naprawić (3.3.1, 3.3.3): wskaż pole, opisz problem i podpowiedz poprawkę – tekstem, nie tylko czerwoną ramką. „Podaj adres e-mail w formacie imie@example.com” jest lepsze niż „Nieprawidłowe dane”.
• Pełna obsługa z klawiatury (2.1.1, 2.1.2): do każdego pola, checkboxa, CAPTCHA i przycisku wysyłania da się dotrzeć i obsłużyć je klawiszami Tab, spacja i Enter, bez pułapek klawiaturowych.
• Widoczny fokus (2.4.7): zawsze widać, które pole jest aktywne. Usunięcie obramowania fokusu przeglądarki bez zamiennika nie spełnia tego kryterium.
• Wystarczający kontrast (1.4.3): teksty, etykiety i komunikaty o błędach mają współczynnik kontrastu co najmniej 4,5:1 względem tła (3:1 dla dużego tekstu).
• Rozmiar celu (2.5.8): przyciski, checkboxy i linki mają co najmniej 24 × 24 piksele CSS albo wystarczający odstęp od innych elementów.
• Alternatywy dla CAPTCHA (1.1.1) i dostępne uwierzytelnianie (3.3.8): 1.1.1 wymaga tekstu alternatywnego i CAPTCHA w więcej niż jednej formie zmysłowej; 3.3.8 dotyczy ściśle logowania, ale jego idea dobrze się przenosi – zagadka typu przepisywanie zniekształconych liter czy rozwiązywanie działania nie powinna być jedyną drogą. Zaoferuj alternatywę albo wybierz metodę, która w ogóle nie wymaga zagadek.
• Honeypoty ukryte przed technologiami asystującymi: pole-pułapka dostaje aria-hidden="true" na elemencie nadrzędnym i tabindex="-1", żeby osoby korzystające z czytnika ekranu i klawiatury nigdy do niego nie trafiły.

CAPTCHA i honeypoty: gdzie ochrona przed spamem spotyka się z dostępnością

Ściśle rzecz biorąc, kryterium 3.3.8 dotyczy logowania i uwierzytelniania, a nie formularzy kontaktowych. Idea, która za nim stoi, dobrze się jednak przenosi: przepisywanie zniekształconych liter, rozwiązywanie działań czy wybieranie sygnalizatorów z siatki obrazków całkowicie wyklucza część osób. Rozwiązania, które zwykle działają bez żadnej zagadki – np. Cloudflare Turnstile, Friendly Captcha, honeypot połączony z kontrolą czasu albo filtrowanie po stronie serwera, jak Akismet – zatrzymują spam, nie każąc odwiedzającym niczego udowadniać. Honeypot jest jednak przyjazny tylko wtedy, gdy jest naprawdę niewidoczny – także dla czytników ekranu i klawiatury:

<div class="hp" aria-hidden="true">
  <label for="hp-website">Zostaw to pole puste</label>
  <input type="text" id="hp-website" name="website"
         tabindex="-1" autocomplete="off">
</div>
<!-- CSS: .hp { position: absolute; left: -10000px; } -->

Przetestuj swój formularz w kwadrans

1. 1Odłóż myszkę i wypełnij cały formularz wyłącznie klawiaturą. Czy docierasz do każdego pola i przycisku wysyłania i czy zawsze widzisz, gdzie jesteś?
2. 2Wyślij formularz pusty, a potem z błędnym adresem e-mail. Czy błędy pojawiają się jako tekst przy właściwym polu i czy wiadomo, co poprawić?
3. 3Otwórz stronę na telefonie albo powiększ widok przeglądarki do 200%. Czy wszystko jest czytelne, czy w przyciski łatwo trafić palcem i czy baner cookies albo widżet czatu nie zasłania przycisku wysyłania?
4. 4Włącz czytnik ekranu (VoiceOver, NVDA lub TalkBack) i posłuchaj: czy każde pole jest odczytywane razem z etykietą i czy honeypot milczy?
5. 5Uruchom automatyczny test, np. axe-core. Szybko wyłapie brakujące etykiety i problemy z kontrastem, ale nie wszystko – opisane wyżej kroki ręczne nadal są potrzebne.

Jeśli wolisz zacząć od ogólnego obrazu, formexposed sprawdza Twoje publiczne formularze z zewnątrz, niczego nie wysyłając. Testy dostępności uruchamiają axe-core dla każdego formularza, wskazują CAPTCHA bez dostępnej alternatywy oraz honeypoty odczytywane przez czytniki ekranu, a także sprawdzają formularz na telefonie – wielkość pól dotykowych, nakładki zasłaniające przycisk wysyłania, przewijanie w poziomie. Darmowe sprawdzenie pokazuje ogólny poziom, a te szczegóły zawiera pełny raport. To dobry punkt wyjścia do powyższej listy, ale nie zastąpi testów z udziałem prawdziwych ludzi.