3.3.6 Zapobieganie błędom (wszystkie)

Krótko

Gdy użytkownik wysyła dane, powinien mieć możliwość sprawdzenia, poprawienia, potwierdzenia albo cofnięcia działania, nawet jeśli nie chodzi o sprawy prawne lub finansowe.

Problem w praktyce

Użytkownik wysyła formularz kontaktowy, zapisuje się do newslettera, publikuje komentarz, wysyła zgłoszenie, zapisuje ustawienia profilu albo kończy ankietę. Wpisuje literówkę, wybiera złą opcję albo klika „Wyślij” za wcześnie.

Jeśli system od razu kończy proces, użytkownik nie ma szansy zauważyć błędu, wrócić do edycji ani cofnąć działania. Skutek może nie być prawny ani finansowy, ale nadal jest realny: błędny adres e-mail, zgłoszenie bez ważnej informacji, publiczny komentarz z pomyłką albo profil zapisany z nieaktualnymi danymi.

Kogo to dotyczy

• Osób z trudnościami poznawczymi, które potrzebują spokojnego kroku sprawdzenia.
• Osób z dysleksją lub trudnościami w czytaniu, które mogą przestawić litery, cyfry albo pola.
• Osób niewidomych korzystających z czytników ekranu, które przechodzą przez proces liniowo i mogą potrzebować jasnego podsumowania.
• Osób słabowidzących, które mogą przeoczyć fragment formularza albo pomylić podobne pola.
• Osób z niepełnosprawnością ruchową, które mogą przypadkowo aktywować przycisk.
• Osób korzystających z klawiatury, sterowania głosem, przełączników lub urządzeń mobilnych.
• Wszystkich użytkowników, którzy działają w pośpiechu, pod presją albo na długim formularzu.

Dobry przykład

• Przed wysłaniem formularza kontaktowego użytkownik widzi podsumowanie: imię, e-mail, temat i treść wiadomości.
• Z ekranu podsumowania można wrócić do edycji danych bez utraty wpisanej treści.
• Proces ma jasny krok „Sprawdź i potwierdź”, a nie niejednoznaczne „Dalej”.
• Użytkownik może anulować proces przed finalnym wysłaniem.
• Po wysłaniu komentarza można go edytować albo cofnąć publikację przez określony czas, jeśli pasuje to do serwisu.
• System jasno mówi, co stanie się po potwierdzeniu, na przykład: „Wyślemy wiadomość do działu obsługi i kopię na podany adres e-mail”.

Zły przykład

• Formularz wysyła dane od razu po kliknięciu „Wyślij”, bez podsumowania i bez możliwości cofnięcia.
• Po przejściu dalej użytkownik nie może wrócić do edycji danych.
• Proces wielokrokowy nie ma kroku potwierdzenia, mimo że użytkownik przesyła dużo informacji.
• Przycisk nie mówi, co się stanie, na przykład „OK” zapisuje publiczny komentarz.
• Komunikat „Gotowe” pojawia się po wysłaniu, ale nie daje możliwości cofnięcia tam, gdzie cofnięcie byłoby możliwe i pomocne.
• System kasuje wpisaną treść po błędzie albo po powrocie do poprzedniego kroku.

Przykłady kodu

<form action="/newsletter/potwierdz" method="post">
  <section aria-labelledby="newsletter-review-heading">
    <h2 id="newsletter-review-heading">
      Sprawdź dane przed zapisem
    </h2>

    <p>
      Włącz Wizję wyśle newsletter na podany adres.
    </p>

    <dl>
      <dt>Adres e-mail</dt>
      <dd>a11y@wlaczwizje.pl</dd>

      <dt>Usługa</dt>
      <dd>Newsletter Włącz Wizję</dd>
    </dl>

    <p>
      Sprawdź dane. Możesz wrócić do edycji
      albo potwierdzić zapis.
    </p>

    <a href="/newsletter?step=edit">
      Wróć do edycji
    </a>

    <button type="submit">
      Potwierdzam zapis do newslettera
    </button>
  </section>
</form>

<section aria-labelledby="confirm-report-heading">
  <h2 id="confirm-report-heading">
    Potwierdź wysłanie zgłoszenia
  </h2>

  <p>
    Sprawdź podsumowanie zgłoszenia.
    Jeśli coś jest nie tak, wróć do edycji.
  </p>

  <a href="/zgloszenie/edycja">
    Wróć do edycji zgłoszenia
  </a>

  <form action="/zgloszenie/wyslij" method="post">
    <button type="submit">
      Potwierdzam i wysyłam zgłoszenie
    </button>
  </form>
</section>

<h2>Komentarz został opublikowany</h2>
<p>
  Możesz cofnąć publikację przez 10 minut.
</p>
<a href="/komentarz/cofnij">Cofnij publikację komentarza</a>

<form action="/ankieta/wyslij" method="post">
  <textarea name="opinia"></textarea>
  <button type="submit">Wyślij</button>
</form>

Przykład graficzny

To statyczny schemat procesu. Pokazuje, czy użytkownik ma szansę sprawdzić, poprawić, potwierdzić albo cofnąć wysłanie danych.

Jak sprawdzić

1. Znajdź wszystkie miejsca, w których użytkownik wysyła informacje: formularze kontaktowe, komentarze, ankiety, zgłoszenia, newslettery i ustawienia profilu.
2. Sprawdź, czy proces ma jeden z mechanizmów: cofnięcie, sprawdzenie z poprawą albo potwierdzenie przed wysłaniem.
3. Przejdź proces z błędnymi danymi i sprawdź, czy można je poprawić bez utraty wpisanej treści.
4. Sprawdź, czy ekran podsumowania, jeśli istnieje, ma jasny link lub przycisk powrotu do edycji.
5. Sprawdź, czy finalny przycisk mówi, co się stanie po aktywacji.
6. Jeśli system oferuje cofnięcie, sprawdź, czy informacja o tym jest widoczna i zrozumiała.
7. Przejdź proces klawiaturą.
8. Sprawdź proces czytnikiem ekranu albo z osobą, która go używa.
9. Nie oceniaj tylko pojedynczego pola. Oceń cały proces wysyłania danych.

Co sprawdzi automat, a czego nie

Automat może wykryć część problemów technicznych: brak etykiet pól, błędne relacje formularza, niedostępne kontrolki, problemy z kolejnością fokusu albo zbyt ogólne przyciski.

Automat zwykle nie oceni, czy proces daje realne zabezpieczenie przed błędem. Nie zrozumie sam, czy użytkownik może wrócić do edycji, czy cofnięcie działa w praktyce, czy krok „Podsumowanie” jest wystarczająco jasny i czy dany formularz rzeczywiście wymaga mechanizmu zapobiegania błędom.

Typowe błędy

• Brak podsumowania przed wysłaniem długiego formularza.
• Brak możliwości edycji danych z ekranu podsumowania.
• Przycisk „Dalej” albo „OK” kończy proces, choć użytkownik nie wie, że to finalne wysłanie.
• System nie pozwala cofnąć komentarza, wiadomości albo zgłoszenia, mimo że technicznie byłoby to możliwe.
• Powrót do poprzedniego kroku kasuje wpisane dane.
• Formularz wielokrokowy nie pokazuje, ile kroków zostało i kiedy nastąpi wysłanie.
• Komunikat sukcesu nie wyjaśnia, co stało się z danymi.
• Zabezpieczenie jest tylko wizualne, na przykład kolor ostrzeżenia bez jasnego tekstu.

Powiązane kryteria

• 3.3.1 Identyfikacja błędu - gdy system wykrywa błąd i musi go wskazać.
• 3.3.2 Etykiety lub instrukcje - gdy użytkownik potrzebuje informacji przed wpisaniem danych.
• 3.3.3 Sugestie korekty błędów - gdy błąd został wykryty i można podać sugestię naprawy.
• 3.3.4 Zapobieganie błędom (prawne, finansowe, dane) - węższy wymóg poziomu AA dla ważnych operacji.
• 4.1.3 Komunikaty o stanie - gdy komunikat o wyniku działania powinien być ogłoszony bez przenoszenia fokusu.
• 1.3.1 Informacje i relacje - gdy struktura formularza i relacje muszą być dostępne programowo.

Źródła

• WCAG 2.2: 3.3.6 Error Prevention (All) (otwiera się w nowym oknie).
• Understanding WCAG 3.3.6: Error Prevention (All) (otwiera się w nowym oknie).
• How to Meet WCAG 3.3.6: Error Prevention (All) (otwiera się w nowym oknie).
• How to Meet WCAG 3.3.4: techniki wystarczające stosowane dla wszystkich formularzy w 3.3.6 (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).