Wróć do wszystkich kryteriów

3.3.4 Zapobieganie błędom (prawne, finansowe, dane) (ang.) Error Prevention (Legal, Financial, Data)

Specjalizacje:

  • Designer
  • Deweloper

Elementy:

  • Formularze

Poziomy:

  • AA

Spis treści

    Istota i cel kryterium

    To kryterium sukcesu stawia nieprzekraczalną barierę dla krytycznych pomyłek użytkownika, które mogą skutkować nieodwracalnymi i dotkliwymi stratami.

    Wytyczna ta wymusza bezwzględną ochronę internautów w kluczowych momentach interakcji, takich jak zawieranie umów online, realizowanie operacji finansowych, modyfikowanie bądź usuwanie danych w bazach oraz wysyłanie arkuszy egzaminacyjnych.

    Zapewnienie pełnej kontroli nad procesem wysyłki buduje zaufanie do systemu i bezkompromisowo eliminuje ryzyko kosztownych błędów.

    Definicja w j. angielskim

    Definicja dostępna pod adresem (link otworzy się w nowej karcie):
    https://www.w3.org/WAI/WCAG22/quickref/#error-prevention-legal-financial-data

    Definicja w j. polskim

    Definicja dostępna pod adresem (link otworzy się w nowej karcie):
    https://www.w3.org/Translations/WCAG21-pl/#zapobieganie-b-edom-prawnym-finansowym-w-danych

    Słownik pojęć

    Odwracalne (ang.) reversible
    –

    wdrożenie mechanizmu cofania zatwierdzonej już akcji, co umożliwia np. anulowanie transakcji w określonym oknie czasowym po jej wykonaniu.

    Sprawdzone (ang.) checked
    –

    automatyczna weryfikacja danych pod kątem poprawności przed ich finalnym przetworzeniem, połączona z precyzyjnym wskazaniem pól wymagających poprawy.

    Potwierdzone (ang.) confirmed
    –

    udostępnienie dedykowanej przestrzeni podsumowującej, która pozwala na bezproblemowy przegląd i edycję danych przed ich ostatecznym zatwierdzeniem.

    Wpływ na dostępność (Kogo wspierasz?)

    • Osoby z niepełnosprawnościami ruchowymi: Drastycznie zmniejszasz ich zmęczenie psychiczne i eliminujesz frustrację wywołaną przypadkowymi kliknięciami. Łatwy proces korekty, bez konieczności ponownego wprowadzania kompletu informacji, jest dla nich kluczowy.
    • Osoby doświadczające stresu lub presji czasu: Blokujesz możliwość podjęcia pochopnych decyzji pod wpływem emocji. Dajesz im bezpieczną przestrzeń na ponowne przemyślenie działania.
    • Osoby z niepełnosprawnościami poznawczymi i trudnościami w uczeniu się: Odciążasz ich pamięć krótkotrwałą, ułatwiając identyfikację błędów w skomplikowanych formularzach.
    • Osoby starsze: Zyskują niezbędny czas na spokojny przegląd treści oraz czytelne, intuicyjne narzędzia do wprowadzania zmian.
    • Osoby słabowidzące lub korzystające z czytników ekranu: Wyraźnie oznaczona sekcja podsumowania chroni ich przed przeoczeniem drobnych literówek, eliminując błądzenie po kodzie.

    Zasady wdrażania i wymagania techniczne

    Każda aplikacja webowa przetwarzająca procesy o wysokim priorytecie musi posiadać cyfrowy bezpiecznik. Standard WCAG bezwzględnie wymaga wdrożenia mechanizmów zapobiegania pomyłkom na stronach internetowych, które wywołują określone skutki prawne, transakcje finansowe, służą do przesyłania odpowiedzi testowych lub pozwalają użytkownikowi modyfikować i usuwać dane w systemach przechowywania, którymi zarządza.

    Podczas projektowania/tworzenia/sprawdzania tych ścieżek krytycznych, aplikacja musi spełniać co najmniej jeden z trzech alternatywnych warunków technicznych:

    • Odwracalne – mechanizm odwracalności akcji ((ang.) reversible): Zadbaj o to, aby wprowadzenie danych lub wykonanie dyspozycji było w pełni odwracalne. Użytkownik musi mieć techniczną możliwość bezproblemowego wycofania lub skasowania przesłanego wniosku po jego zatwierdzeniu.
    • Sprawdzone – autokorekta i sprawdzanie ((ang.) checked): Uruchom skrypty walidacyjne, które drobiazgowo weryfikują wprowadzone przez użytkownika informacje pod kątem błędów syntaktycznych i logicznych. System musi zagwarantować użytkownikowi jasną informację zwrotną oraz pełną dostępność interfejsu do wprowadzenia poprawek.
    • Potwierdzone – ekran podglądu i potwierdzenia ((ang.) confirmed): Zaimplementuj inteligentne systemy walidacji, które drobiazgowo przeanalizują wprowadzane dane pod kątem pomyłek i anomalii technicznych przed ich ostatecznym przetworzeniem. Jeśli aplikacja wykryje błąd, precyzyjnie wskaż miejsce potknięcia i daj użytkownikowi pełną autonomię oraz wygodne narzędzia do błyskawicznego wprowadzenia korekty.

    Najczęściej stosowaną drogą osiągnięcia Kryterium WCAG 3.3.4 jest dopuszcza profilaktyczna strategia potwierdzenia. Gwarantuje ona maksymalne bezpieczeństwo danych, eliminując ryzyko potknięcia jeszcze przed wysłaniem formularza.

    Wyjątki i sytuacje szczególne

    Wymagania tego kryterium skupiają się wyłącznie na zapobieganiu masowej utracie danych, takiej jak bezpowrotne skasowanie całego pliku lub rekordu w bazie.

    • Brak konieczności potwierdzania pojedynczych zapisów: Kryterium bezwzględnie NIE wymaga wyświetlania komunikatów ostrzegawczych ani wymuszania kroków potwierdzających przy każdym standardowym wywołaniu komendy zapisu lub przy zwykłym tworzeniu i edycji dokumentów tekstowych oraz pojedynczych rekordów.
    • Dane poza kontrolą użytkownika: Wytyczna nie obejmuje procesów, na które użytkownik nie ma bezpośredniego wpływu i których nie może samodzielnie przeglądać – mowa tu o logach systemowych oraz danych monitorujących wyszukiwarki.
    • Bezzwrotność biznesowa: W sytuacjach, gdzie opcja odwracalności transakcji jest całkowicie zablokowana przez przepisy prawa lub specyfikę rynku, musisz bezkompromisowo przenieść cały ciężar techniczny na krok weryfikacji i jawnego potwierdzenia danych przed ich wysłaniem.

    Przykłady implementacji

    Najczęstsze błędy

    • Niejasne lub lakoniczne komunikaty: Serwowanie generycznych alertów typu „Błąd”, które wywołują całkowicie losową i chaotyczną nawigację użytkownika, zamiast podania precyzyjnej instrukcji naprawy pola.
    • Brak ekranu podsumowania: Całkowite pominięcie kroku weryfikacji w formularzach o wysokim ryzyku prawnym lub finansowym.
    • Zmuszanie do ponownego wprowadzania danych: Brak zachowania dotychczas wpisanych informacji przy powrocie z podsumowania do edycji, co zmusza do ponownego wypełniania całego formularza i drastycznie potęguje frustrację.
    • Trudności w edycji danych: Wyświetlanie zebranych danych na ekranie podsumowania bez udostępnienia prostych, intuicyjnych odnośników do modyfikacji konkretnych sekcji.
    • Ignorowanie błędów serwera: Opieranie walidacji wyłącznie na skryptach klienckich i błąd strukturalny polegający na braku obsługi błędów zwracanych przez bazę danych, co odcina użytkowników technologii wspomagających od kluczowych komunikatów.
    • Automatyczne przetwarzanie operacji: Wysyłanie i realizowanie krytycznych dyspozycji natychmiast po wyświetleniu podsumowania, bez wymogu kliknięcia przycisku zatwierdzającego przez użytkownika.

    Najlepsze praktyki

    • Wykorzystaj walidację po stronie klienta: Zaimplementuj skrypty sprawdzające poprawność danych w czasie rzeczywistym i generuj natychmiastowe alerty przed wysyłką formularza.
    • Zapewnij stałość danych interfejsu: Dbaj o to, by powrót użytkownika w celu poprawienia informacji nie czyścił poprawnie wypełnionych pól, eliminując konieczność ponownego pisania.
    • Stosuj komunikaty potwierdzające sukces: Wyświetlaj czytelne, jednoznaczne powiadomienie zwrotne natychmiast po udanym przetworzeniu krytycznych danych.
    • Zadbaj o dostępność klawiatury: Zweryfikuj, czy mechanizmy powrotu i linki modyfikujące są w pełni obsługiwane bez użycia myszki. Stosuj wyraziste opisy (np. „Popraw adres wysyłki” zamiast samego „Edytuj”).
    • Projektuj wizualne grupowanie bloków: Grupuj powiązane ze sobą informacje na ekranie podsumowania w logiczne pakiety danych – to wyrazistość bez kompromisów, ułatwiająca błyskawiczną weryfikację.
    • Unikaj nieczytelnych struktur: Zrezygnuj z chaotycznego rozmieszczenia pól podsumowania, które mogłoby zmylić użytkownika przed ostatecznym zatwierdzeniem.

    Metody testowania

    • Narzędzie deweloperskie (ang.) Developer Tools: Przeanalizuj kod i strukturę drzewa DOM na stronie weryfikacji. Zweryfikuj, czy dane ukryte w polach typu input są tożsame z informacjami zaprezentowanymi wizualnie użytkownikowi oraz czy powrót do edycji zachowuje nienaruszone wartości.
    • NVDA: Uruchom czytnik ekranu i wykonaj pełne przejście przez proces weryfikacji oraz poprawiania danych całkowicie bez patrzenia na monitor. Upewnij się, że opisy przycisków i linków edycyjnych jednoznacznie informują o swoim kontekście i celu.
    • Testowanie manualne: Wyodrębnij formularze podwyższonego ryzyka, które pasują do kryteriów wytycznej (formularze finansowe, prawne, testy edukacyjne lub widoki usuwania danych). Przejdź samodzielnie cały proces i zweryfikuj, czy kod interfejsu bezwzględnie zapewnia co najmniej jeden z trzech alternatywnych warunków technicznych: odwracalność akcji po wysłaniu ((ang.) reversible), automatyczne sprawdzanie poprawności danych ((ang.) checked) lub dedykowany krok podsumowania i potwierdzenia ((ang.) confirmed).

    Sprawdź swoją wiedzę

    W linku poniżej znajduje się 6 przykładów operacji. Twoim zadaniem jest ocenić, czy system odpowiednio chroni użytkownika przed popełnieniem nieodwracalnego błędu o skutkach prawnych, finansowych lub związanych z utratą danych.

    Jak to sprawdzić?

    1. Wykonaj akcję w każdym formularzu (np. kliknij „Wyślij”, „Usuń”, „Kup”).
    2. Sprawdź, czy system od razu realizuje operację, czy daje szansę na weryfikację.
    3. Oceń, czy zaimplementowano jeden z wymaganych mechanizmów: Odwracalne (możliwość cofnięcia), Sprawdzone (ostrzeżenie o anomaliach) lub Potwierdzone (ekran podsumowania).

    Notatka: Zanim zajrzysz do rozwiązania, przetestuj i zapisz swoje wnioski na kartce.
    Proponowane narzędzia: Klawiatura (Tab, Shift + Tab, Spacja, Enter ), Myszka

    Link: https://pdc.ambiscale.com/training/wcag-3-3-4/

    #1 BŁĄD

    Problem: System natychmiastowo i bezpowrotnie usuwa konto po kliknięciu przycisku.
    Dlaczego: Operacja usunięcia danych jest krytyczna. Zgodnie z kryterium 3.3.4, system musi zapewniać mechanizm odwracalności, sprawdzenia lub potwierdzenia przed wykonaniem takiej akcji.
    Naprawa: Dodaj krok potwierdzenia (np. modal z pytaniem „Czy na pewno chcesz usunąć konto?”) lub mechanizm odwracalności (np. konto jest dezaktywowane na 30 dni z możliwością przywrócenia).

    #2 DOBRZE

    Dlaczego: Zastosowano mechanizm „Potwierdzone”. Przed finalizacją transakcji finansowej użytkownik widzi ekran podsumowania, na którym może zweryfikować wprowadzone dane (numer konta, kwotę) i w razie potrzeby wrócić do edycji.

    #3 DOBRZE

    Dlaczego: Zastosowano mechanizm „Odwracalne”. Użytkownik ma okno czasowe na anulowanie wysłania wniosku, co chroni przed skutkami przypadkowego kliknięcia.
    Uwaga (demo): 5-sekundowe okno to skrót na potrzeby ćwiczenia. W realnym systemie przedział anulowania powinien być znacznie dłuższy (WCAG dopuszcza „określony przedział czasu”, ale 5 s byłoby zbyt krótkie m.in. dla osób z ograniczeniami motorycznymi).

    #4 DOBRZE

    Dlaczego: Zapisanie zwykłej notatki nie niesie za sobą skutków prawnych, transakcji finansowych ani nie modyfikuje krytycznych danych systemowych. Zgodnie z wyjątkami kryterium 3.3.4, takie operacje nie wymagają dodatkowych kroków potwierdzających.

    #5 BŁĄD

    Problem: System pozwala na zakończenie i wysłanie testu egzaminacyjnego z pominiętym pytaniem, bez żadnego ostrzeżenia.
    Dlaczego: Przesyłanie odpowiedzi testowych to operacja krytyczna objęta kryterium 3.3.4. System powinien sprawdzić kompletność danych i ostrzec użytkownika przed finalizacją.
    Naprawa: Zastosuj mechanizm „Sprawdzone” – przed wysłaniem wyświetl komunikat: „Pominąłeś pytanie 2. Czy na pewno chcesz zakończyć egzamin?”.

    #6 DOBRZE

    Dlaczego: Zastosowano mechanizm „Sprawdzone”. System sprawdza wpisaną liczbę akcji — przy wartości powyżej 10 000 wykrywa anomalię, wstawia bieżącą liczbę do komunikatu i prosi o jawne potwierdzenie. Przy niższej wartości transakcja przechodzi od razu (bez fałszywego ostrzeżenia).

    Źródła

    Dodatkowe linki

    Wróć do wszystkich kryteriów