W formularzach nie chodzi tylko o to, żeby „coś nie przeszło”. Chodzi o to, żeby użytkownik dostał jasny sygnał: błąd wystąpił, a także które konkretne pole (element formularza) jest w błędzie i na czym polega problem. To jest sedno WCAG 3.3.1 Error Identification.
W praktyce wiele stron „robi wszystko” wizualnie: pokazuje formularz ponownie, podświetla pole, a czasem wyświetla ogólny komunikat typu „sprawdź dane”. Problem w tym, że osoba z ograniczeniami może nie mieć szansy szybko zlokalizować, gdzie dokładnie leży kłopot. Dlatego copy do błędów musi prowadzić „z pola na pole”, a nie zostawiać użytkownika z domysłami.
W tym artykule przełożymy wymaganie 3.3.1 na proste zasady pisania: strukturę komunikatu, mikrocopy do etykietowania błędu, wsparcie nawigacji oraz wymagania, które musi spełnić interfejs w codziennym wdrożeniu.
WCAG 3.3.1 w 60 sekund: co musi wiedzieć użytkownik po błędzie
Co znaczy „identyfikacja” w praktyce copy
WCAG 3.3.1 Error Identification dotyczy sytuacji, gdy formularz automatycznie wykryje błąd wejścia. Wtedy użytkownik powinien dostać w tekście dwie rzeczy: informację, że błąd wystąpił, oraz identyfikację konkretnego elementu/pola, które jest źródłem problemu. Sam fakt, że formularz „znowu się pojawił”, nie wystarcza, jeśli użytkownik nie dostaje jednoznacznego sygnału, że walidacja nie powiodła się i gdzie.
Copy nie może być ogólnikiem. Komunikat ma wskazać pole/etykietę i opisać charakter problemu. To znaczy: użytkownik nie ma zgadywać, czy błąd dotyczy formatu, zakresu wartości, braku danych w wymaganym polu, czy też wpisu, który po walidacji okazał się nieakceptowalny.
Warto pamiętać o typowych przypadkach „input error”. Najczęściej chodzi o brak wartości w polu wymaganym albo wpis, który nie przechodzi walidacji formatu lub nie mieści się w dozwolonych wartościach. Twoje zdanie ma brzmieć tak, żeby użytkownik od razu zrozumiał, jakiego rodzaju korekta jest potrzebna.
Copywriting do formularzy: wzorzec komunikatu błędu (pole → problem → wskazówka)
Domknięcie 3.3.1 vs. „następny krok” z 3.3.3
Skuteczny komunikat błędu w formularzu ma prosty szkielet: pole → problem → wskazówka. Przy czym „pole + problem” to fundament zgodności z WCAG 3.3.1, a „wskazówka” powinna pojawić się wtedy, gdy da się ją sensownie i bezpiecznie podać jako sugestię korekty.
Jak to ułożyć redakcyjnie? Zacznij od identyfikacji: w treści komunikatu powiedz, które pole jest w błędzie. Najlepiej użyj tej samej nazwy, którą użytkownik widzi w formularzu (etykieta). Następnie opisz charakter walidacji: czy brakuje wymaganej wartości, czy wpis ma zły format albo jest nieakceptowalny.
Dopiero później dodawaj „co dalej”. Wspiera to WCAG 3.3.3 Error Suggestion, czyli podejście do przekazania sugestii korekty, gdy są znane i właściwe. W praktyce to oznacza ostrożność: jeśli nie masz podstaw, by podać, jak użytkownik ma poprawić dane, nie „zawieszaj” komunikatu na niekonkretnych domysłach. Dobre copy nie karze za zgadywanie, tylko daje kierunek w zakresie walidacji wejścia.
Najlepsze komunikaty nie dublują informacji w nieskończoność. Liczy się czytelna kolejność: najpierw identyfikacja pola i opis błędu w tekście, a dopiero potem (jeśli zasadne) sugestia korekty. Dzięki temu użytkownik wie, co jest nie tak i jaką część formularza ma przepracować.
Etykietowanie błędu i „brak zgadywania”: jak podać kontekst w UI
Mechanizm „lista błędów” jako wsparcie copy
Użytkownik nie powinien szukać błędu jak skarbu. Jeżeli komunikat identyfikuje pole, a jednocześnie interfejs pozwala szybko nawigować do miejsca problemu, „koszt znalezienia” spada. To jest praktyczna implementacja ducha 3.3.1: brak zgadywania, gdzie jest błąd.
Dobrym dodatkiem copy’owym jest mechanizm typu „lista błędów”. Taka lista zbiera komunikaty w jednym miejscu: każdy element zawiera identyfikację pola i krótki opis charakteru problemu, a dalej użytkownik może przejść do właściwego pola. W efekcie komunikat przestaje być tylko informacją, a staje się nawigacją.
Jak pisać treść w liście, żeby działała redakcyjnie? Pisz krótko i „z pola na pole”: zacznij od nazwy pola, a dopiero potem dopisz, na czym polega walidacja. Nie próbuj w liście wyjaśniać wszystkiego, co możliwe. Lista ma ułatwić lokalizację, a pełny opis może znaleźć się przy polu.
W ramach komunikacji możesz też wspierać użytkownika nawigacyjnym sygnałem na górze strony (np. zapowiedź, że są błędy i że lista pozwala do nich przejść). Przy osobach korzystających z technologii asystujących to często różnica między „znalazłem” a „muszę zgadywać”.
- W komunikacie przy polu: etykieta pola + opis charakteru walidacji.
- W liście błędów: skrócona wersja „etykieta + co jest nie tak”, żeby użytkownik mógł szybko wybrać właściwe miejsce.
- W tekście wspierającym na górze: informacja, że błąd wystąpił i że użytkownik może przejść do pól z błędami.
Co z dostępnością techniczną: dlaczego samo „ładne słowa” nie zawsze wystarczą
„Identyfikacja pola” wymaga, by UI było czytelne dla AT
Wiele zespołów myśli o komunikacie błędu jak o samym tekście. Copywriting jest ważny, ale WCAG 3.3.1 ma też warunek praktyczny: użytkownik ma otrzymać identyfikację pola/elementu w kontekście błędu. Jeśli komponenty formularza nie są programowo rozpoznawalne, technologie asystujące mogą nie „złapać”, że komunikat dotyczy konkretnej kontrolki, albo mogą nie odczytać statusu i zmiany.
W objaśnieniach dotyczących dostępności zwraca się uwagę na to, by nazwa, rola i wartość były możliwe do programowego ustalenia, a zmiany informacji były dostępne dla technologii asystujących. W codziennym wdrożeniu oznacza to, że „identyfikacja pola” nie jest tylko kwestią brzmienia komunikatu, ale też tym, jak interfejs mapuje komunikat do konkretnego elementu.
Dlatego najlepsze efekty daje współpraca copy + wdrożenie. Tekst ma wskazać pole i opisać błąd, ale interfejs ma też zapewnić, że użytkownik dostanie to jako informację o konkretnym polu, a nie jako losowy komunikat gdzieś na stronie.
To szczególnie ważne, gdy formularz korzysta z własnych komponentów lub nietypowych rozwiązań UI. Wtedy mikrocopy może być poprawne językowo, ale jeśli komponent nie przekazuje prawidłowych informacji o statusie błędu, użytkownik może nie dostać identyfikacji tak, jak zakłada kryterium.
Przykładowe sformułowania (do adaptacji) + antywzorce
Szybka adaptacja do różnych typów walidacji
Poniżej masz przykładowe wzorce komunikatów, które da się łatwo dopasować do formularzy. Traktuj je jako formaty, a nie gotowce „na każde pole”. Klucz jest prosty: etykieta (identyfikacja) + opis problemu walidacji. „Co dalej” dodawaj wtedy, gdy możesz zasugerować korektę w ramach znanych reguł.
- Wzorzec dla braku wartości w polu: „Pole [nazwa etykiety] jest wymagane. Uzupełnij je, aby kontynuować.”
- Wzorzec dla złego formatu: „W polu [nazwa etykiety] wpis ma nieprawidłowy format. Sprawdź dane i popraw je zgodnie z wymaganiami.”
- Wzorzec dla nieakceptowalnej wartości: „W polu [nazwa etykiety] wpisana wartość jest niedozwolona. Wybierz wartość, która spełnia warunki.”
Jak to przekuć na komunikat przy polu i w liście błędów? Najpierw identyfikacja: użyj dokładnie takiej nazwy, jaką użytkownik widzi w formularzu. Potem dopisz krótki opis: brak wymaganej wartości, niepoprawny format lub nieakceptowalna wartość po walidacji. Na tym etapie nie musisz obiecywać cudów ani tłumaczyć „dlaczego” w ogóle.
Antywzorce, które zwiększają zgadywanie:
- „Wystąpił błąd w formularzu.” Bez wskazania pola użytkownik nie wie, co poprawić.
- „Sprawdź dane.” To też za mało, bo nie opisuje charakteru problemu walidacji.
- „Coś poszło nie tak.” Komunikat nie identyfikuje elementu w błędzie i nie ułatwia lokalizacji.
- Komunikat wyłącznie wizualny (np. sama zmiana koloru) bez czytelnego tekstu opisującego problem.
Jeśli chcesz szybciej dopasować komunikat do typu walidacji, potraktuj to jak prostą decyzję redakcyjną: czy błąd dotyczy braku wartości, formatu, czy dozwolonych wartości? Od tego zależy pierwsze zdanie opisu. Reszta to konsekwentne utrzymanie jednej logiki: identyfikacja pola i opis problemu w tekście.
Checklist redakcyjny: zanim wyślesz komunikaty błędów do walidacji
Czego nie robić: 3 najczęstsze błędy w mikrocopy
Przed wdrożeniem komunikatów błędów warto przejść szybki test redakcyjny. Nie chodzi o to, żeby „mieć tekst”, tylko żeby ten tekst realizował cel kryterium: użytkownik ma dostać identyfikację pola i opis problemu, a następnie ewentualnie sugestię korekty wtedy, gdy ma to sens.
- Nie pisz komunikatu bez identyfikacji pola/elementu. Jeśli użytkownik nie dostaje informacji „które pole”, zostaje zgadywanie.
- Nie dawaj ogólników zamiast opisu charakteru walidacji. „Sprawdź dane” lub „błąd” nie podpowiadają, czy problem to brak wartości, format, czy niedozwolona wartość.
- Nie pomijaj wsparcia lokalizacji błędów, jeśli użytkownik może mieć trudność ze skanowaniem formularza. Mechanizm typu lista błędów lub „skocz do błędów” zmniejsza koszty szukania.
A teraz checklist, którą możesz skopiować do procesu pracy z zespołem:
- Czy komunikat jednoznacznie sygnalizuje, że błąd wystąpił, a nie tylko pokazuje formularz ponownie?
- Czy komunikat identyfikuje konkretne pole w tekście (np. używa etykiety widocznej w formularzu)?
- Czy opisuje charakter problemu walidacji wejścia (brak wartości, nieprawidłowy format, niedozwolona wartość)?
- Czy „co dalej” pojawia się jako sugestia korekty tylko wtedy, gdy jest właściwe i nie wprowadza w błąd?
- Czy masz element UI, który ułatwia dotarcie do błędnego miejsca (lista błędów / mechanizm nawigacji)?
- Czy komunikacja jest projektowana razem z wdrożeniem, tak aby identyfikacja pola była czytelna dla technologii asystujących?
Podsumowując: WCAG 3.3.1 opiera się na dwóch rdzeniach komunikatu — identyfikacji pola/elementu w błędzie oraz opisaniu charakteru problemu w tekście. Informacja „co dalej” to osobna logika, którą warto dodawać jako sugestię korekty wtedy, gdy jest to właściwe. Najlepsze efekty daje połączenie dobrego copywritingowego wzorca (pole → problem → wskazówka) z tym, jak wdrożony interfejs mapuje komunikaty i zmiany do konkretnych elementów formularza. Skontroluj to w całym przepływie użytkownika, nie tylko „na słowach”. Skontaktuj się z Aleteksty.pl, aby omówić artykuły, teksty na stronę, opisy produktów lub regularną obsługę treści.
