Wróć do wszystkich kryteriów

3.3.3 Sugestie korekty błędów (ang.) Error Suggestion

Specjalizacje:

  • Designer
  • Deweloper

Elementy:

  • Formularze

Poziomy:

  • AA

Spis treści

    Istota i cel kryterium

    Głównym zadaniem tego kryterium sukcesu jest maksymalne uproszczenie procesu korygowania informacji, które użytkownik wprowadza do formularzy cyfrowych. Gdy system automatycznie zidentyfikuje nieprawidłowość i dysponuje wiedzą o potencjalnej poprawce, Twoim bezwzględnym obowiązkiem jest podsuniecie mu precyzyjnej wskazówki. Kryterium to stanowi bezpośrednie rozszerzenie wytycznej 3.3.1, która wymaga jedynie samego wskazania faktu wystąpienia błędu.

    Zapomnij o bezużytecznych, lakonicznych komunikatach tekstowych typu „Wystąpił błąd”. Taki szablonowy tekst odcina użytkownika od możliwości samodzielnego rozwiązania problemu, zmusza go do zgadywania i drastycznie zwiększa ryzyko całkowitego porzucenia formularza. Kryterium to wymaga dostarczenia jasnych, praktycznych i natychmiastowych sugestii, co drastycznie zmniejsza zmęczenie psychiczne i eliminuje frustrację towarzyszącą interakcji z aplikacją.

    Definicja w j. angielskim

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

    Definicja w j. polskim

    Definicja dostępna pod adresem (link otworzy się w nowej karcie):
    https://www.w3.org/Translations/WCAG21-pl/#sugestie-korekty-b-edow

    Słownik pojęć

    Błędnie wprowadzone dane (ang.) input error
    –

     to sytuacja, w której dane dostarczone przez użytkownika są odrzucane przez system ze względu na niespełnienie określonych reguł walidacji.

    Sugestia poprawki 
    –

     to czytelna instrukcja tekstowa lub gotowy wariant danych do wyboru, generowany przez autora strony lub programistycznie przez program użytkownika ((ang.) user agent), wskazujący prawidłowy sposób uzupełnienia pola.

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

    • Osoby niewidome oraz słabowidzące: Użytkownicy korzystający z czytników ekranu ((ang.) screen readers) są pozbawieni kontekstu wizualnego. Bez jednoznacznego, poprawnie oznaczonego semantycznie komunikatu zawierającego podpowiedź, ogólnikowe ostrzeżenie staje się dla nich zagadką niemożliwą do rozwiązania. Precyzyjna sugestia jest natychmiast przekazywana przez syntezator mowy bezpośrednio przy błędnym polu.
    • Osoby z zaburzeniami poznawczymi oraz dysleksją: Skomplikowane lub niejasne reguły formatowania danych, a także konieczność zapamiętywania sztywnych struktur, bywają dla nich barierą poznawczą nie do przebycia. Konkretne i proste instrukcje zamiast chaosu informacyjnego pozwalają im bezstresowo i sprawnie dokończyć zadanie.
    • Osoby starsze: Osoby te mogą słabiej orientować się we współczesnych, dynamicznych konwencjach interfejsów internetowych, dlatego potrzebują stabilnego, jasnego i intencyjnego wsparcia na każdym etapie walidacji.
    • Osoby z ograniczeniami ruchowymi: Przypadkowe kliknięcia, pomyłki podczas pisania na klawiaturze lub drżenie dłoni to dla nich codzienność. Jasne i konkretne wskazówki naprawy minimalizują liczbę wyczerpujących, ponownych prób ponownego uzupełniania pól formularza.
    • Każdy użytkownik systemu: Przemyślana komunikacja błędów skraca czas potrzebny na ukończenie formularza, podnosi poziom ogólnej satysfakcji i skutecznie buduje zaufanie do Twojej platformy.

    Zasady wdrażania i wymagania techniczne

    Spełnienie wymagań poziomu AA nakłada na Ciebie obowiązek technicznego i projektowego zaplanowania obsługi błędów w zależności od napotkanej sytuacji. Zastosuj się do poniższych wytycznych implementacyjnych:

    • Sytuacja A: Wymagany specyficzny format danych ((ang.) data format): Jeśli pole oczekuje określonej struktury danych (np. numeru telefonu, kodu pocztowego lub daty), zawsze wyświetl wzorzec poprawnego zapisu. Jako przykład podaj jasną instrukcję: „Proszę użyć formatu DD-MM-RRRR, np. 31-12-2000”.
    • Sytuacja B: Wymagana wartość z ograniczonego zestawu ((ang.) limited set of values): W sytuacji, gdy wprowadzona wartość musi należeć do zamkniętej puli (np. nazwa miesiąca), a użytkownik wpisze cyfrę „12”, wyświetl listę dopuszczalnych opcji tekstowych lub zapytaj wprost: „Czy chodziło o 'Grudzień’?”. Podaj użytkownikowi pełną listę prawidłowych wartości do wyboru, aby wykluczyć błędy słownikowe.
    • Jasno komunikuj brakujące dane: Gdy użytkownik pozostawi wymagane pole puste, wskaż jednoznacznie, które miejsce wymaga natychmiastowego uzupełnienia oraz jakich danych oczekujesz (np. „Pole 'Imię’ jest wymagane. Proszę podać swoje imię, aby kontynuować”).
    • Zapewnij pełną dostępność dla technologii wspomagających: Wykorzystaj atrybuty ARIA, takie jak aria-invalid="true" do technicznego oznaczenia błędnego pola. Zastosuj atrybut aria-describedby, aby trwale powiązać identyfikator komunikatu o błędzie z konkretnym polem formularza w strukturze dynamicznej drzewa DOM. Dzięki temu czytnik ekranu automatycznie odczyta podpowiedź po wejściu fokusu w dany obszar.
    • Zarządzaj fokusem klawiatury: Po nieudanej próbie wysłania formularza przenieś fokus za pomocą metody focus() na pierwsze błędnie uzupełnione pole lub na czytelne, globalne podsumowanie błędów z linkami wewnętrznymi prowadzącymi do poszczególnych pól.
    • Pozwól na kontrolę i unikaj automatycznych zmian bez autoryzacji: Nigdy nie wprowadzaj automatycznych modyfikacji w krytycznych danych bez wyraźnej zgody użytkownika. Jeśli system wykryje oczywistą pomyłkę w adresie e-mail (np. brak znaku „@” lub literówkę w domenie), zaproponuj właściwą pisownię, ale zawsze pozostaw użytkownikowi ostateczną decyzję o jej przyjęciu lub odrzuceniu.

    Wyjątki i sytuacje szczególne

    Zrezygnuj z podawania szczegółowych sugestii poprawki wyłącznie w momentach, kiedy wyświetlenie podpowiedzi bezpośrednio naruszyłoby bezpieczeństwo danych lub zniszczyło nadrzędny cel danej operacji ((ang.) purpose of the content).

    Doskonałym przykładem są formularze autoryzacyjne, procedury logowania (gdzie podanie informacji, czy błędne jest hasło, czy login, ułatwiłoby atak) lub pytania pomocnicze systemu bezpieczeństwa (np. „Podaj imię panieńskie matki”).

    Drugim kluczowym wyjątkiem są testy wiedzy, quizy online oraz egzaminy cyfrowe. Podanie sugestii poprawnej odpowiedzi w komunikacie o błędzie w trakcie trwania sprawdzianu całkowicie zniweczyłoby cel edukacyjny i uniemożliwiło rzetelną ocenę umiejętności kursanta. Pamiętaj jednak, by stosować te wyjątki wyłącznie w tych ściśle uzasadnionych przypadkach.

    Przykłady implementacji

    Najczęstsze błędy

    • Wyświetlanie ogólnych komunikatów bez konkretnych wytycznych: Serwowanie lakonicznych tekstów typu „Wystąpił błąd podczas przetwarzania formularza” lub „Niepoprawne dane” bez wskazania, które pole zawiodło i jak dokładnie należy je poprawić, to najpoważniejsze uchybienie.
    • Odizolowanie komunikatu od kontekstu i brak jasnej sugestii: Umieszczanie listy błędów wyłącznie na samej górze strony, daleko od modyfikowanych pól, bez precyzyjnych i jasnych instrukcji (np. suche stwierdzenie „Numer telefonu jest nieprawidłowy” zamiast wskazania poprawnego formatu). Skutkuje to całkowicie losową i chaotyczną nawigacją dla osób korzystających z klawiatury.
    • Modyfikowanie wpisanych danych bez autoryzacji: Samowolne, automatyczne zmienianie treści wpisanej przez człowieka w polach formularza bez możliwości weryfikacji, cofnięcia lub akceptacji sugerowanej poprawki przez użytkownika.

    Najlepsze praktyki

    • Wyrazistość bez kompromisów w warstwie wizualnej: Zastosuj jednoznaczną stylizację CSS – pogrubiony tekst komunikatów o minimalnym kontraście 4.5:1 oraz wyraźne, grubsze ramki wokół błędnych pól formularza (np. border: 2px solid #c00;), aby błąd był widoczny na pierwszy rzut oka i nie opierał się wyłącznie na barwie.
    • Semantyczne powiadomienia dynamiczne: Dla globalnych zestawień błędów lub komunikatów generowanych w czasie rzeczywistym stosuj atrybuty role="alert" lub aria-live="assertive". Gwarantuje to, że czytniki ekranu natychmiast poinformują użytkownika o problemach.
    • Kontekstualne podpowiedzi w czasie rzeczywistym: Projektuj walidację działającą na zdarzeniu onblur lub bezpośrednio podczas wpisywania danych za pomocą zdarzenia input, która podpowiada prawidłowy format w momencie opuszczania pola, zamiast zmuszać użytkownika do czekania na przeładowanie całej strony.

    Metody testowania

    • Narzędzie deweloperskie (ang.) Developer Tools: Przeanalizuj drzewo DOM aplikacji. Upewnij się, że w momencie wyzwalania walidacji do błędnych elementów formularza dynamicznie przypisywany jest atrybut aria-invalid="true" oraz właściwy identyfikator w aria-describedby, który precyzyjnie odpowiada wartości id kontenera zawierającego tekst tekstowej sugestii poprawki.
    • NVDA: Uruchom czytnik ekranu i przejdź za pomocą klawiatury przez formularz zawierający celowo wprowadzone błędy. Sprawdź, czy syntezator mowy natychmiast poprawnie odczytuje pełną treść podpowiedzi i sugestii naprawy błędu po wejściu fokusu klawiatury w dane pole edycyjne.
    • ANDI.JS: Wybierz moduł odpowiedzialny za kontrolę formularzy oraz elementów interaktywnych. Zweryfikuj, co dokładnie „widzi” technologia asystująca i czy tekst sugestii poprawki jest jednoznacznie prezentowany jako opis powiązany z testowanym polem tekstowym.

    Sprawdź swoją wiedzę

    W linku poniżej znajduje się 6 formularzy. Zostały one celowo zaprogramowane tak, aby po kliknięciu przycisku „Wyślij” wygenerować błąd walidacji. Twoim zadaniem jest sprawdzenie, czy błędy te są komunikowane w sposób dostępny.

    Jak to sprawdzić?

    1. Kliknij przycisk „Wyślij” w każdym przykładzie, aby wywołać błąd.
    2. Zbadaj pole wejściowe oraz komunikat o błędzie za pomocą narzędzi deweloperskich (Zbadaj element).
    3. Sprawdź, czy pole otrzymało atrybut aria-invalid="true".
    4. Sprawdź, czy komunikat jest powiązany z polem za pomocą aria-describedby.
    5. Sprawdź, czy treść komunikatu jest jasna i precyzyjna, a nie tylko ogólnikowa.

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

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

    #1 DOBRZE

    Dlaczego: Komunikat błędu jest bardzo precyzyjny. Nie tylko informuje o błędzie, ale podaje oczekiwany wzorzec (DD-MM-RRRR) oraz konkretny przykład (15-05-2026), co pozwala użytkownikowi natychmiast poprawić dane.

    #2 BŁĄD

    Problem: Komunikat „Niepoprawne dane” jest zbyt ogólnikowy.
    Dlaczego: Użytkownik wpisał datę słownie, a system prawdopodobnie oczekuje innego formatu. Brak sugestii zmusza do zgadywania.
    Naprawa: Podaj oczekiwany format, np. „Wprowadź datę w formacie DD-MM-RRRR”.

    #3 BŁĄD

    Problem: System automatycznie zmodyfikował wpisane dane (poprawił „gmial” na „gmail”) bez wyraźnej zgody użytkownika.
    Dlaczego: Modyfikowanie krytycznych danych (jak adres e-mail) bez autoryzacji jest niebezpieczne i łamie dobre praktyki.
    Naprawa: Zaproponuj właściwą pisownię w komunikacie błędu (np. „Czy chodziło Ci o [email protected]?”), ale pozostaw użytkownikowi decyzję o jej przyjęciu.

    #4 BŁĄD

    Problem: Pole jest puste, a komunikat mówi tylko „Błąd formularza”.
    Dlaczego: Należy jasno komunikować brakujące dane.
    Naprawa: Zmień komunikat na precyzyjny: „Pole 'Imię’ jest wymagane. Proszę podać swoje imię, aby kontynuować”.

    #5 DOBRZE

    Dlaczego: System wykrył, że wprowadzona wartość (12) nie należy do oczekiwanej ograniczonej puli (nazwy miesięcy). Zamiast odrzucać dane bez słowa, podał instrukcję i zasugerował konkretną poprawkę („Czy chodziło Ci o 'Grudzień’?”).

    #6 DOBRZE

    Dlaczego: Jest to formularz logowania. Zastosowano tu dozwolony wyjątek dotyczący bezpieczeństwa. Podanie szczegółowej sugestii (np. „Hasło jest błędne, ale login istnieje”) ułatwiłoby atakującym odgadywanie danych. Ogólnikowy komunikat „Nieprawidłowy login lub hasło” jest w tym specyficznym przypadku jedynym poprawnym rozwiązaniem.

    Źródła

    Dodatkowe linki

    Wróć do wszystkich kryteriów