WCAG 3.3.4 Zapobieganie błędom (prawnym, finansowym, w danych)

Kryterium sukcesu 3.3.4 chroni przed kosztownymi pomyłkami, których nie da się cofnąć. Osoba z trudnościami w czytaniu może przestawić cyfry w ilości, osoba z niepełnosprawnością ruchową może nacisnąć zły przycisk, a użytkownik czytnika ekranu może nie zauważyć, że wybrano zły rozmiar. Gdy skutkiem jest opłacone zamówienie albo usunięte konto, konsekwencje są realne. To poziom AA; w normie EN 301 549 kryterium to występuje jako punkt 9.3.3.4.

Czego wymaga kryterium

Kryterium dotyczy stron internetowych, które:

• powodują dla użytkownika zobowiązania prawne lub transakcje finansowe (złożenie zamówienia, zawarcie umowy, płatność);
• modyfikują lub usuwają dane kontrolowane przez użytkownika w systemach przechowywania danych (dane konta, adresy, zapisane dane);
• albo wysyłają odpowiedzi użytkownika w teście.

Na takich stronach musi być spełniony co najmniej jeden z poniższych warunków:

1. Odwracalność: wysłanie można cofnąć, na przykład anulować w określonym czasie.
2. Sprawdzenie: wprowadzone dane są sprawdzane pod kątem błędów, a użytkownik ma możliwość ich poprawienia.
3. Potwierdzenie: dostępny jest mechanizm przejrzenia, potwierdzenia i poprawienia informacji przed ostatecznym wysłaniem.

Kryterium dotyczy poważnych pomyłek. Nie wymaga potwierdzenia przy każdym zapisie czy edycji.

Typowe błędy w sklepie internetowym

Każdy z poniższych przypadków nie spełnia kryterium tylko wtedy, gdy nie jest dostępna żadna z trzech możliwości — na przykład gdy zamówienia nie da się też anulować:

• przyciski „Kup teraz” lub zakup jednym kliknięciem, które od razu składają płatne zamówienie, bez kroku podsumowania i bez możliwości anulowania;
• proces zamówienia, w którym ostatni krok przed płatnością nie pokazuje produktów, ilości, adresu i kwoty łącznej;
• podsumowanie zamówienia, którego nie da się edytować — aby zmienić adres, trzeba zaczynać od początku;
• „Usuń konto” lub „Usuń wszystkie zapisane adresy”, które działają natychmiast, bez potwierdzenia i bez cofnięcia;
• zapis na subskrypcję, który zobowiązuje do płatności cyklicznych bez pokazania warunków przed potwierdzeniem.

Jak to sprawdzić

Automatycznie: nasz skaner nie ma reguły dla tego kryterium. Nie składa zamówień ani nie usuwa danych, dlatego potrzebna jest kontrola ręczna.

Ręcznie: należy przejść ścieżkę zakupu z produktem testowym i zatrzymać się przed płatnością. Sprawdzić, czy przed ostatnim przyciskiem można zobaczyć i zmienić wszystko — produkty, ilość, adres dostawy, sposób dostawy, kwotę łączną. Następnie sprawdzić strefę konta: usunąć adres lub konto i zobaczyć, czy jest potwierdzenie, sprawdzenie lub możliwość cofnięcia. Zanotować możliwości anulowania oferowane po złożeniu zamówienia.

Jak to naprawić

• Dodać krok podsumowania albo sprawić, by ostatni krok zamówienia pokazywał wszystkie szczegóły z linkami „Edytuj”.
• Stosować jasny przycisk końcowy, na przykład „Zamawiam i płacę”, oddzielony od „Dalej”.
• Prosić o potwierdzenie przed usunięciem konta lub danych albo oferować możliwość przywrócenia.
• Walidować dane (adres, kartę, ilość) i pozwalać użytkownikom je poprawić przed złożeniem zamówienia.

Powiązane kryteria

• 3.3.1 Identyfikacja błędu — błędy są wskazywane tekstem.
• 3.3.3 Sugestie korekty błędów — użytkownicy dowiadują się, jak poprawić błędy.
• 3.3.7 Zbędne ponowne wprowadzanie danych — bez wpisywania tych samych danych ponownie w jednym procesie.

Najczęstsze pytania

Czy każdy proces zamówienia potrzebuje strony podsumowania?

Nie. 3.3.4 wymaga co najmniej jednej z trzech możliwości: wysłanie jest odwracalne, dane są sprawdzane i użytkownik może je poprawić albo istnieje sposób na przejrzenie i potwierdzenie danych przed finalizacją. Krok podsumowania to jeden z popularnych sposobów.

Czy 3.3.4 dotyczy usuwania konta lub adresu?

Tak. Kryterium obejmuje strony, które modyfikują lub usuwają dane kontrolowane przez użytkownika w systemach przechowywania danych, więc usunięcie konta, zapisanego adresu lub listy życzeń powinno być odwracalne, sprawdzane lub potwierdzane.

Czy 3.3.4 wymaga okna potwierdzenia przy każdym zapisie?

Nie. W3C wyjaśnia, że chodzi o zapobieganie poważnym, trudnym do odwrócenia pomyłkom, takim jak masowa utrata danych, a nie o potwierdzanie każdej edycji.