3.3.4 Zapobieganie błędom (prawne, finansowe, dane)

Krótko

Przy ważnych działaniach użytkownik musi móc cofnąć wysłanie, poprawić dane albo sprawdzić i potwierdzić informacje przed finalną decyzją.

Problem w praktyce

Użytkownik robi przelew, składa wniosek, usuwa konto, wysyła odpowiedzi testowe albo zatwierdza zamówienie. Jeden błąd może mieć skutki prawne, finansowe lub organizacyjne.

Jeśli system od razu finalizuje działanie, użytkownik nie ma czasu zauważyć literówki, złej kwoty, błędnego adresu, przypadkowego usunięcia danych albo odpowiedzi zaznaczonej przez pomyłkę.

Kogo to dotyczy

• Osób z trudnościami poznawczymi, które potrzebują więcej czasu na sprawdzenie decyzji.
• Osób niewidomych korzystających z czytników ekranu, które mogą przeoczyć kontekst długiego procesu.
• Osób słabowidzących, które mogą pomylić podobne pola, kwoty albo przyciski.
• Osób z niepełnosprawnością ruchową, które mogą przypadkowo aktywować kontrolkę.
• Osób korzystających z klawiatury, sterowania głosem albo przełączników.
• Osób starszych, zmęczonych, zestresowanych lub działających pod presją czasu.
• Użytkowników bankowości, sklepów, usług publicznych, systemów medycznych, rekrutacyjnych i edukacyjnych.

Dobry przykład

• Przed złożeniem zamówienia użytkownik widzi podsumowanie koszyka, adresu, dostawy i płatności oraz może wrócić do edycji.
• Przy przelewie system pokazuje odbiorcę, numer rachunku, kwotę i tytuł przed zatwierdzeniem.
• Przy usuwaniu danych system prosi o potwierdzenie albo pozwala odzyskać usunięte dane.
• Przy formularzu prawnym użytkownik zaznacza świadome potwierdzenie i ma jasny opis skutków wysłania.
• Przy teście użytkownik może przejrzeć odpowiedzi przed końcowym wysłaniem.
• Po zakupie użytkownik ma jasno opisany czas na zmianę lub anulowanie zamówienia, jeśli to jest wybrany mechanizm zabezpieczenia.

Zły przykład

• Przycisk „Wyślij” od razu składa wiążący wniosek, bez podsumowania i potwierdzenia.
• Usunięcie konta następuje po jednym kliknięciu i nie da się go cofnąć.
• System pobiera płatność bez pokazania końcowej kwoty i danych odbiorcy.
• Test zamyka się natychmiast po kliknięciu „Zakończ”, bez możliwości przejrzenia odpowiedzi.
• Komunikat ostrzegawczy jest ukryty w regulaminie, a nie w samym procesie.
• Przycisk ma niejasną etykietę, na przykład „Dalej”, mimo że finalizuje ważne działanie.

Jeden z trzech mechanizmów

3.3.4 nie wymaga zawsze tego samego rozwiązania. Dla działań objętych kryterium wystarczy jeden skuteczny mechanizm:

• Odwrócenie: użytkownik może cofnąć, anulować albo odtworzyć działanie po wysłaniu.
• Sprawdzenie: system sprawdza dane, wskazuje błędy i daje użytkownikowi możliwość poprawy.
• Potwierdzenie: użytkownik może przejrzeć, potwierdzić i poprawić informacje przed finalnym wysłaniem.

Ważne jest to, żeby zabezpieczenie działało przed poważną konsekwencją albo pozwalało ją realnie odwrócić.

Przykłady kodu

<h2>Sprawdź zamówienie</h2>
<dl>
  <dt>Kwota do zapłaty</dt>
  <dd>249,00 zł</dd>
  <dt>Adres dostawy</dt>
  <dd>ul. Prosta 10, 00-001 Warszawa</dd>
</dl>
<a href="/koszyk/adres">Zmień adres dostawy</a>
<button type="submit">Potwierdzam i kupuję</button>

<label>
  <input
    type="checkbox"
    name="confirm-application"
    required
  >
  Rozumiem, że wysłanie wniosku rozpoczyna procedurę
  i potwierdzam poprawność danych.
</label>
<button type="submit">Wyślij wniosek</button>

<h2>Potwierdź usunięcie konta</h2>
<p>
  Usuniemy profil, historię zgłoszeń i zapisane adresy.
  Tej operacji nie można cofnąć.
</p>
<a href="/konto">Anuluj i wróć do konta</a>
<button type="submit">Tak, usuń moje konto</button>

<form action="/konto/usun" method="post">
  <button type="submit">Usuń konto</button>
</form>

Przykład graficzny

To jest statyczny schemat procesu. Pokazuje, czy użytkownik ma szansę sprawdzić, poprawić, potwierdzić albo cofnąć operację przed poważnym skutkiem.

Jak sprawdzić

1. Znajdź formularze i działania, które powodują skutki prawne, finansowe, zmianę lub usunięcie danych użytkownika albo wysłanie odpowiedzi testowych.
2. Sprawdź, czy przed finalnym wysłaniem użytkownik może przejrzeć informacje.
3. Sprawdź, czy użytkownik może poprawić dane przed finalną decyzją.
4. Sprawdź, czy działanie można cofnąć, anulować albo odtworzyć po wysłaniu, jeśli to jest wybrany mechanizm.
5. Sprawdź, czy system wskazuje błędy i daje możliwość ich poprawy, jeśli opiera się na walidacji.
6. Sprawdź, czy końcowy przycisk jasno opisuje konsekwencję, na przykład „Potwierdzam i kupuję”.
7. Przejdź proces klawiaturą i upewnij się, że da się dotrzeć do edycji, anulowania i potwierdzenia.
8. Sprawdź proces czytnikiem ekranu.
9. Nie oceniaj wyłącznie jednego ekranu. Sprawdź cały proces od wpisania danych do finalnego wysłania.

Co sprawdzi automat, a czego nie

Automat może wykryć część problemów technicznych w formularzu, na przykład brak etykiet, błędne relacje pól, niektóre niedostępne kontrolki albo problemy z kolejnością fokusu.

Automat zwykle nie oceni, czy dane działanie jest prawnie lub finansowo ważne, czy potwierdzenie wystarcza, czy użytkownik rzeczywiście może cofnąć operację ani czy tekst przycisku jasno opisuje konsekwencję. To wymaga ręcznego przejścia procesu.

Typowe błędy

• Brak podsumowania przed płatnością, przelewem albo wysłaniem wniosku.
• Brak możliwości powrotu do edycji danych z ekranu podsumowania.
• Nieodwracalne usuwanie danych po jednym kliknięciu.
• Niejasne etykiety przycisków, takie jak „Dalej”, „OK” albo „Zapisz”, gdy działanie ma poważny skutek.
• Potwierdzenie ukryte w regulaminie, a nie w procesie.
• Brak informacji, jak długo można anulować albo zmienić transakcję.
• Walidacja pokazuje błąd, ale nie pozwala wrócić do poprawy danych.
• Proces działa myszą, ale klawiaturą trudno wrócić do poprawy lub anulowania.

Powiązane kryteria

• 3.3.1 Identyfikacja błędu - wskazanie, gdzie jest błąd i jaki to błąd.
• 3.3.2 Etykiety lub instrukcje - informacje potrzebne przed wpisaniem danych.
• 3.3.3 Sugestie korekty błędów - podpowiedzi po wykryciu błędu.
• 3.3.6 Zapobieganie błędom (wszystkie) - podobna zasada na poziomie AAA dla wszystkich formularzy wymagających wysłania informacji.
• 4.1.3 Komunikaty o stanie - ogłaszanie komunikatów bez zmiany fokusu.
• 2.4.3 Kolejność fokusu - logiczne przechodzenie przez kroki procesu klawiaturą.

Źródła

• WCAG 2.2: 3.3.4 Error Prevention (Legal, Financial, Data) (otwiera się w nowym oknie).
• Understanding WCAG 3.3.4: Error Prevention (Legal, Financial, Data) (otwiera się w nowym oknie).
• How to Meet WCAG 3.3.4: Error Prevention (Legal, Financial, Data) (otwiera się w nowym oknie).
• G164: Providing a stated time within which an online request may be amended or canceled (otwiera się w nowym oknie).
• G98: Providing the ability for the user to review and correct answers before submitting (otwiera się w nowym oknie).
• G155: Providing a checkbox in addition to a submit button (otwiera się w nowym oknie).
• G99: Providing the ability to recover deleted information (otwiera się w nowym oknie).
• G168: Requesting confirmation to continue with selected action (otwiera się w nowym oknie).