Najważniejsze wnioski
- Błąd w koszyku musi być opisany tekstem. Czerwone obramowanie, ikona lub zmiana koloru mogą wspierać komunikat, ale nie mogą być jego jedynym nośnikiem.
- Najpraktyczniejszy wzorzec łączy podsumowanie błędów na początku formularza z komunikatem umieszczonym bezpośrednio przy błędnym polu.
- Komunikat powinien odpowiadać na trzy pytania: co jest nieprawidłowe, gdzie jest problem i co użytkownik może zrobić dalej.
- Dla czytników ekranu liczy się nie tylko widoczny tekst, lecz także programowe powiązanie błędu z polem, właściwie użyty fokus i ostrożne komunikaty dynamiczne.
- Widget dostępności może pomóc użytkownikowi zwiększyć tekst, kontrast lub czytelność interfejsu, ale błędów walidacji, struktury formularza i integracji płatności nie zastąpi bezpośrednia naprawa w kodzie.
Dla zarządzającego
Komunikaty błędów w checkoutcie są częścią jakości usługi, zaufania i dostępności cyfrowej. Priorytetem nie jest napisanie większej liczby alertów, lecz uporządkowanie procesu: jasne zasady formularza, konkretne odpowiedzi systemu, diagnostyka techniczna oraz regularne testy klawiaturą i czytnikiem ekranu.
Dla sprzedaży
Jeżeli klient pyta, czy widget rozwiąże problemy z checkoutem, odpowiedź powinna być uczciwa: WCAGbot wspiera wygodę korzystania ze strony, między innymi przez kontrast, powiększenie tekstu i funkcje czytania. Komunikaty błędów w koszyku wymagają jednak audytu oraz naprawy źródłowej formularza, płatności i obsługi fokusu.
Dostępne komunikaty błędów w koszyku i płatności powinny pomagać użytkownikowi od razu poprawić problem, a nie tylko informować, że system zatrzymał zamówienie. W praktyce oznacza to tekstowy opis błędu, wskazanie konkretnego pola lub etapu, podpowiedź dalszego działania oraz poprawne przekazanie informacji czytnikowi ekranu.
W checkoutcie użytkownik jest blisko decyzji zakupowej. Jeśli po kliknięciu „Zapłać” zobaczy tylko „Wystąpił błąd”, nie wie, czy ma poprawić kod pocztowy, sprawdzić dane karty, wybrać inną metodę płatności czy poczekać na usunięcie awarii. To jednocześnie problem UX, obsługi klienta i dostępności cyfrowej.
Najważniejsze wnioski
- Nie używaj samego koloru, ikony ani czerwonej ramki jako informacji o błędzie.
- Komunikat przy polu powinien wyjaśniać problem prostym językiem i podawać sposób poprawy.
- Po wysłaniu formularza pokaż podsumowanie błędów oraz zapewnij logiczne przejście fokusu.
- Nie kasuj poprawnie wpisanych danych po błędzie walidacji lub nieudanej płatności.
- Testuj checkout na klawiaturze, z czytnikiem ekranu i przy powiększonym tekście.
Dobry komunikat błędu nie mówi użytkownikowi, że zrobił coś źle. Mówi mu, co system rozpoznał i jak bezpiecznie przejść dalej.
Dlaczego komunikat błędu w checkoutcie ma tak duże znaczenie?
Koszyk i płatność łączą wiele procesów: walidację adresu, wybór dostawy, zgodę na regulamin, działanie bramki płatniczej, kontrolę ryzyka oraz komunikację z bankiem. Jeden krótki alert może w rzeczywistości oznaczać zupełnie różne sytuacje.
- Błąd danych: nieprawidłowy format telefonu, brak numeru lokalu, błędny kod pocztowy.
- Błąd płatności: odrzucenie przez bank, nieaktualna karta, niezgodność danych rozliczeniowych.
- Brak dostępności metody: dana metoda płatności nie działa dla koszyka, kraju lub urządzenia.
- Błąd techniczny: przerwana sesja, timeout, awaria integracji albo problem po stronie dostawcy.
Te sytuacje wymagają innych komunikatów. Nie należy jednak ujawniać klientowi poufnych informacji technicznych, reguł antyfraudowych ani pełnych kodów odpowiedzi operatora. Szczegół diagnostyczny powinien trafić do logów lub panelu administratora, a użytkownik powinien dostać bezpieczną i użyteczną instrukcję.
Jeżeli porządkujesz cały proces dostępności sklepu, zacznij od szerszej checklisty dostępności sklepu internetowego. Warto też rozumieć, jak cztery zasady WCAG działają na konkretnych elementach e-commerce: wyjaśnia to artykuł Cztery zasady WCAG na przykładzie sklepu internetowego.
Jak powinien wyglądać dostępny komunikat błędu?
Najlepiej traktować komunikat jako krótką instrukcję. Powinien być widoczny, zrozumiały i dostępny programowo. W3C w kryterium WCAG 3.3.1 wskazuje, że automatycznie wykryty błąd należy zidentyfikować i opisać użytkownikowi tekstem. To wyklucza wzorzec, w którym jedyną zmianą jest czerwony kolor pola.
1. Nazwij konkretny problem
Zamiast „Niepoprawne dane” napisz: „Wpisz kod pocztowy w formacie 00-000”. Zamiast „Błąd karty” napisz: „Nie udało się potwierdzić płatności tą kartą. Sprawdź dane albo wybierz inną metodę płatności”.
Unikaj języka obwiniającego, na przykład „Źle wpisałeś dane”. Użytkownik może korzystać z autouzupełniania, dyktowania, klawiatury ekranowej albo może napotkać problem po stronie systemu. Komunikat ma opisywać stan formularza, nie oceniać osobę.
Droga użytkownika od błędu do poprawnego zamówienia
2. Wskaż miejsce błędu
Komunikat powinien znajdować się blisko pola i być z nim powiązany. W kodzie często stosuje się na przykład aria-describedby, aby czytnik ekranu odczytał etykietę, instrukcję oraz tekst błędu jako kontekst pola. Przy wykrytym błędzie pole może otrzymać stan aria-invalid="true", ale sama właściwość nie zastępuje opisu błędu.
ARIA pomaga tylko wtedy, gdy odpowiada rzeczywistemu zachowaniu komponentu. Niepoprawne role, ukrywanie tekstu lub nadmiar komunikatów dynamicznych mogą utrudnić obsługę. Przed wdrożeniem sprawdź praktyczne zasady opisane w artykule ARIA bez pułapek: kiedy pomaga, a kiedy psuje dostępność?.
3. Nie polegaj wyłącznie na kolorze
Czerwony kolor może wzmacniać komunikat, ale nie może być jedynym sygnałem. Dodaj tekst, ikonę z dostępną nazwą albo widoczną etykietę „Błąd”. Zadbaj też o kontrast tekstu komunikatu, obramowania i wskaźnika fokusu. W szczególności nie ukrywaj informacji w jasnoczerwonym tekście na białym tle, którego część użytkowników nie odczyta komfortowo.
Możesz otworzyć panel WCAGbot na własnej stronie i sprawdzić checkout przy zwiększonym tekście lub w wybranym trybie kontrastu. To dobre ćwiczenie doświadczeniowe: zobaczysz, czy komunikat pozostaje widoczny, nie nachodzi na przycisk i nie znika poza ekranem. Funkcje kontrastu, skali tekstu i czytania opisujemy w materiale Kontrast, większy tekst i czytanie treści w WCAGbot.
4. Podpowiedz, co zrobić dalej
WCAG 3.3.3 dotyczy sugestii poprawy, gdy jest ona znana i jej ujawnienie nie zagraża bezpieczeństwu lub celowi formularza. Dla kodu pocztowego, adresu, daty czy telefonu zwykle da się przekazać konkretną wskazówkę. Dla płatności trzeba zachować ostrożność.
| Sytuacja | Komunikat niewystarczający | Komunikat użyteczny | Co sprawdzić technicznie |
|---|---|---|---|
| Brak pola obowiązkowego | „Błąd formularza” | „Wpisz adres e-mail, aby otrzymać potwierdzenie zamówienia.” | Etykieta, required, opis błędu, fokus |
| Nieprawidłowy format | „Telefon jest błędny” | „Wpisz numer telefonu zawierający 9 cyfr.” | Reguła walidacji zgodna z komunikatem |
| Odrzucona płatność | „Płatność nie powiodła się” | „Nie udało się potwierdzić płatności. Spróbuj ponownie lub wybierz inną metodę.” | Stan bramki, kod dla administratora, możliwość ponowienia |
| Awaria checkoutu | „Wystąpił błąd” | „Nie możemy teraz połączyć się z płatnością. Twoje dane w formularzu zostały zachowane. Spróbuj ponownie za chwilę lub wybierz inną metodę.” | Status integracji, log zdarzenia, numer referencyjny |
Jak połączyć podsumowanie błędów, fokus i komunikat przy polu?
Sam komunikat obok pola nie zawsze wystarczy. Gdy użytkownik wysyła długi formularz, może nie wiedzieć, że kilka błędów znajduje się wyżej na stronie. Praktyczny wzorzec ma dwa poziomy.
- Na początku formularza pojawia się podsumowanie, np. „Formularz zawiera 3 błędy. Popraw pola oznaczone poniżej.”
- Każdy punkt podsumowania prowadzi linkiem do odpowiedniego pola.
- Przy polu znajduje się pełny, tekstowy komunikat.
- Po wysłaniu formularza fokus trafia do podsumowania albo do pierwszego błędnego pola — wybór trzeba przetestować w konkretnym układzie.
- Po poprawieniu danych komunikat i stan błędu aktualizują się bez dezorientowania użytkownika.
Komunikat ogólny a komunikat użyteczny
Nie ustawiaj automatycznie fokusu w sposób, który przerywa użytkownikowi pisanie przy każdej literze. Walidacja „w trakcie wpisywania” bywa pomocna dopiero po opuszczeniu pola lub po wpisaniu pełnej wartości. Szczególnie w polach karty, kodu CVC i telefonu zbyt wczesna walidacja może tworzyć serię komunikatów, zanim użytkownik skończy wprowadzać dane.
Przetestuj również, czy cały proces da się obsłużyć bez myszy. Instrukcję prostego testu znajdziesz w artykule Nawigacja klawiaturą: test strony bez myszy w 15 minut.
WCAGbot Accessibility Path dla błędów w checkoutcie
Ten schemat porządkuje pracę nad komunikatami błędów bez udawania, że jedno narzędzie rozwiąże wszystkie bariery.
- Zmapuj błędy: spisz komunikaty dla adresu, dostawy, rabatów, konta i każdej metody płatności.
- Rozdziel przyczyny: oddziel błędy danych, odrzucenia płatności, niedostępność metody i awarie techniczne.
- Popraw źródło: wdroż tekst, powiązanie z polem, obsługę fokusu oraz zachowanie danych.
- Przetestuj scenariusze: użyj klawiatury, czytnika ekranu, powiększenia tekstu i widoku mobilnego.
- Wesprzyj użytkownika: dodaj funkcje dostępności, takie jak kontrast, czytelna czcionka lub większy tekst.
- Monitoruj: analizuj zdarzenia techniczne bez zapisywania w analityce wrażliwych danych płatniczych.
Mini-scenariusz: nieudana płatność kartą
Scenariusz ilustracyjny — nie opisuje wdrożenia u konkretnego klienta. Użytkownik wypełnia adres, wybiera dostawę i wpisuje dane karty. Po kliknięciu przycisku płatności bramka zwraca ogólne odrzucenie.
W słabym wariancie strona pokazuje czerwony napis „Płatność nieudana”, czyści część formularza i nie przenosi fokusu. Użytkownik nie wie, czy zamówienie zostało złożone, czy środki zostały pobrane ani czy powinien próbować ponownie.
W lepszym wariancie checkout zachowuje dane niezbędne do kontynuacji, pokazuje podsumowanie „Nie udało się potwierdzić płatności” i przekazuje dostępne opcje: „Spróbuj ponownie” oraz „Wybierz inną metodę płatności”. Czytnik ekranu otrzymuje komunikat dynamiczny po zakończeniu próby, a administrator widzi techniczny kod zdarzenia w bezpiecznym logu. Jeśli sklep nie może potwierdzić statusu transakcji, komunikat powinien jasno powiedzieć, że zamówienie nie zostało potwierdzone, zamiast składać niezweryfikowane zapewnienia.
Gdzie kończy się rola widgetu dostępności?
WCAGbot może być szybkim pierwszym krokiem do dostępności: użytkownik może uruchomić między innymi tryby kontrastu, powiększenie tekstu, czytelną czcionkę, funkcje skupienia czy czytanie treści. To może ułatwić odczyt komunikatu i obsługę strony osobie z konkretną potrzebą.
Widget nie naprawi jednak logiki walidacji checkoutu, nie zagwarantuje poprawnej informacji przekazywanej czytnikowi ekranu i nie zmieni działania zewnętrznej bramki płatniczej. Komunikaty błędów wymagają audytu oraz naprawy źródłowej w kodzie i treści. Więcej o tej granicy przeczytasz w materiale Widget dostępności a zgodność z WCAG: uczciwe porównanie.
W szerszym kontekście warto odróżniać wytyczne WCAG, normę EN 301 549 i wymagania prawne dotyczące usług. Zestawienie tych pojęć znajduje się w artykule WCAG 2.1, WCAG 2.2 i EN 301 549 — czym się różnią?. Informacje dotyczące Polskiego Aktu o Dostępności wymagają każdorazowej analizy zakresu usługi i aktualnego stanu prawnego; nie należy sprowadzać ich wyłącznie do instalacji widgetu.
Anatomia dostępnego błędu pola formularza
Checklista przed publikacją zmian w checkoutcie
- Czy każdy błąd ma widoczny opis tekstowy?
- Czy komunikat mówi, którego pola lub etapu dotyczy?
- Czy użytkownik dostaje konkretną wskazówkę, gdy można ją bezpiecznie podać?
- Czy kolor nie jest jedynym nośnikiem informacji?
- Czy błąd jest programowo powiązany z właściwym polem?
- Czy fokus po wysłaniu formularza prowadzi do informacji o błędzie?
- Czy poprawnie wpisane dane pozostają zachowane?
- Czy komunikaty są testowane na telefonie, klawiaturze i z czytnikiem ekranu?
- Czy komunikat dla klienta jest oddzielony od kodu technicznego dla zespołu?
- Czy zespół zna właściciela procesu dla błędów bramki płatniczej?
FAQ
Czy czerwone obramowanie pola wystarcza jako komunikat błędu?
Nie. Kolor może wspierać informację, ale użytkownik powinien otrzymać również tekstowy opis problemu i sposób jego poprawy.
Czy każdy błąd musi być odczytywany automatycznie przez czytnik ekranu?
Informacja o błędzie powinna być dostępna dla technologii asystujących. Sposób ogłoszenia zależy od zachowania formularza: inne rozwiązanie stosuje się po wysłaniu formularza, a inne przy dynamicznej walidacji pola.
Czy należy stosować aria-live do każdego błędu?
Nie. Nadmiar komunikatów dynamicznych może przerywać pracę użytkownika czytnika ekranu. Używaj ich celowo, zwłaszcza po zmianie stanu wynikającej z działania użytkownika.
Co powinien zawierać komunikat o odrzuconej płatności?
Powinien wyjaśniać, że płatność nie została potwierdzona, oraz proponować bezpieczny następny krok, na przykład ponowienie próby lub wybór innej metody. Nie powinien ujawniać wrażliwych danych ani szczegółów reguł bezpieczeństwa.
Czy po błędzie płatności można zachować dane karty?
To zależy od architektury płatności, wymogów bezpieczeństwa i dostawcy bramki. Zasadą UX jest niekasowanie danych bez potrzeby, ale dane płatnicze wymagają odrębnej oceny technicznej i zgodnościowej.
Czy podsumowanie błędów na górze formularza wystarczy?
Nie zawsze. Najlepiej połączyć je z komunikatami przy polach oraz linkami prowadzącymi do miejsc wymagających poprawy.
Jak testować błędy klawiaturą?
Wypełnij formularz bez myszy, celowo zostaw błędne dane, wyślij go i sprawdź kolejność fokusu, widoczność wskaźnika oraz możliwość poprawienia każdego pola.
Czy WCAGbot naprawi błędne komunikaty w checkoutcie?
Nie. WCAGbot może wspierać użytkownika funkcjami widoczności i czytelności, ale tekst, walidacja, ARIA, fokus i integracja płatności wymagają naprawy w źródle strony.
Czy dostępne komunikaty błędów są istotne w Shopify i WordPressie?
Tak. Problem dotyczy każdej platformy, ale zakres możliwych zmian zależy od używanego motywu, wtyczek, checkoutu oraz konfiguracji dostawcy płatności.
Czy komunikat „Spróbuj ponownie później” jest wystarczający?
Tylko wtedy, gdy system rzeczywiście nie może teraz wykonać działania i nie ma bezpieczniejszej wskazówki. Warto dodać informację, czy dane zostały zachowane, czy można użyć innej metody i gdzie uzyskać pomoc.
Podsumowanie
Dostępny komunikat błędu w koszyku nie jest ozdobnym alertem. To element procesu zakupu, który ma pozwolić użytkownikowi zrozumieć problem i odzyskać kontrolę nad kolejnym krokiem. Zacznij od najczęstszych błędów adresu i płatności, popraw ich treść oraz obsługę w kodzie, a następnie przetestuj cały scenariusz bez myszy i z technologiami asystującymi.
Dodaj funkcje dostępności swojej strony i przetestuj WCAGbot: https://wcagbot.pl/#kontakt.
