Wróć do wszystkich kryteriów

3.3.1 Identyfikacja błędu (ang.) Error Identification

Specjalizacje:

  • Designer
  • Deweloper

Elementy:

  • Formularze

Poziomy:

  • A

Spis treści

    Istota i cel kryterium

    Kryterium to absolutny fundament dostępności formularzy i wszelkich interaktywnych elementów na stronie internetowej. Wymaga ono, aby każdy automatycznie wykryty błąd w formularzu został natychmiast powiązany z konkretnym komponentem i precyzyjnie wyjaśniony w formie tekstowej. Zadbaj o to, aby mechanizm automatycznie zidentyfikował błąd i dostarczył precyzyjne wskazówki umożliwiające jego natychmiastową naprawę.

    Wdrażając te zasady, zdejmujesz z użytkowników ogromne obciążenie poznawcze i budujesz cyfrowe zaufanie do swojego systemu.

    Pamiętaj: Czysto wizualne sygnały są ulotne i zawodne. Musisz zapewnić jednoznaczny, tekstowy komunikat, który bez przeszkód odczytają również technologie wspomagające.

    Definicja w j. angielskim

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

    Definicja w j. polskim

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

    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.

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

    • Wszyscy użytkownicy: Czytelne instrukcje drastycznie zmniejszają zmęczenie psychiczne, podnoszą efektywność interakcji i poprawiają ogólne doświadczenie użytkownika niezależnie od stopnia jego sprawności.
    • Osoby z niepełnosprawnościami poznawczymi: Słabo opisany błąd sprawia, że nie są one w stanie zrozumieć, co dokładnie poszło nie tak. Jasne i konkretne komunikaty wskazują im bezpośrednią drogę do znalezienia rozwiązania.
    • Osoby niewidome lub niedowidzące: Osoby korzystające z czytników ekranu potrzebują jednoznacznego, programowego zakodowania błędu, aby ich oprogramowanie mogło go bezbłędnie odczytać. Pamiętaj, że czysto wizualne wyróżnienia, takie jak czerwone ramki, są dla nich całkowicie niewidoczne i bezużyteczne.
    • Osoby z niepełnosprawnością ruchową: Trudności z precyzyjną obsługą klawiatury lub wpisywaniem zwiększają ryzyko pomyłek. Klarowne komunikaty pozwalają im szybko skorygować błąd bez konieczności mozolnego powtarzania całej operacji od początku.

    Zasady wdrażania i wymagania techniczne

    Aby bezkompromisowo zrealizować to kryterium, Twój system musi spełnić trzy fundamentalne wymagania techniczne:

    1. Automatyczna detekcja pomyłki: System musi samodzielnie zidentyfikować nieprawidłowe dane, takie jak błędny format adresu e-mail, puste wymagane pole czy hasło niezgodne z polityką bezpieczeństwa.
    2. Jednoznaczna identyfikacja elementu: Precyzyjnie wskaż, który konkretnie komponent formularza zawiera błąd. Zapomnij o ogólnikowych komunikatach – powiąż informację z polem wizualnie oraz programowo za pomocą struktur ARIA.
    3. Tekstowa forma opisu: Komunikat wyjaśniający problem umieść w strukturze tekstu, który zasila drzewo DOM i pozostaje w pełni dostępny dla technologii wspomagających.

    Podczas kodowania bezwzględnie stosuj poniższe mechanizmy techniczne:

    • Zastosuj atrybut aria-invalid="true" na elemencie polu wprowadzania danych, w którym wykryto błąd, aby natychmiast przekazać czytniku ekranu informację o nieprawidłowym stanie pola i zmienić jego status dostępności.
    • Wykorzystaj atrybut aria-describedby, przypisując mu jako wartość identyfikator (id) kontenera zawierającego tekst błędu. Dzięki temu czytnik automatycznie ogłosi etykietę pola, a zaraz po niej treść komunikatu, gdy użytkownik przeniesie tam fokus.
    • W przypadku dynamicznej walidacji po stronie klienta za pomocą języka JavaScript, dodawaj i usuwaj te atrybuty oraz zawartość tekstową w czasie rzeczywistym. Wykorzystaj do tego zdarzenie blur (opuszczenie pola) lub moment zatwierdzenia formularza.
    • Użyj elementu <span> oznaczonego atrybutem role="alert" lub kontenera z aria-live="polite" do wyświetlania komunikatu. Atrybut role="alert" wymusi na technologii wspomagającej natychmiastowe ogłoszenie błędu w momencie jego dynamicznego wstrzyknięcia do kodu.
    • Wizualne wyróżnienie elementów formularza (np. czerwona ramka, jasnoczerwone tło czy zmiana koloru tekstu) traktuj wyłącznie jako uzupełnienie – nigdy nie wolno Ci polegać tylko na kolorze.

    Wyjątki i sytuacje szczególne

    Kryterium 3.3.1 nie przewiduje żadnych formalnych wyjątków ani łagodzenia reguł na poziomie A.

    Pamiętaj jednak o logicznej granicy jego stosowania: wymagania te dotyczą wyłącznie sytuacji, w których błąd wejściowy jest automatycznie wykrywany przez system.

    Jeżeli mechanizm systemowy nie posiada zaimplementowanej walidacji dla danego pola i przepuści niepoprawne dane bez ich wykrycia, reguła ta technicznie nie ma zastosowania.

    Dobrą praktyką jest jednak dążenie do automatyzacji detekcji wszędzie tam, gdzie format danych jest mierzalny.

    Przykłady implementacji

    Najczęstsze błędy

    • Zbyt szybkie usuwanie komunikatów: Likwidowanie ostrzeżeń z ekranu przed upływem czasu potrzebnego na ich spokojne przeczytanie i zrozumienie przez użytkownika.
    • Ignorowanie powiązania programowego: Ograniczanie się do czysto wizualnych modyfikacji (np. czerwona ramka) przy jednoczesnym zignorowaniu atrybutów aria-invalid oraz aria-describedby. To najpoważniejsze uchybienie skazuje użytkowników czytników ekranu na błądzenie po formularzu.
    • Ukrywanie komunikatów w dymkach ((ang.) tooltips): Osadzanie błędów wyłącznie pod najechaniem myszką lub aktywacją pola, co odcina od nawigacji użytkowników mobilnych oraz osoby korzystające wyłącznie z klawiatury.
    • Serwowanie bezużytecznych ogólników: Wdrażanie lakonicznych komunikatów typu „Wystąpił błąd” lub „Niepoprawne dane”, które w żaden sposób nie pomagają w naprawie pomyłki.
    • Frustrująca walidacja w czasie rzeczywistym: Agresywne uruchamianie skryptów weryfikacyjnych w trakcie wpisywania danych, co wywołuje dezorientację – zamiast tego waliduj po opuszczeniu pola (blur) lub przy próbie wysyłki.
    • Ignorowanie pominiętych pól wymaganych: Brak wygenerowania konkretnego komunikatu o błędzie informującego, że puste pole było w rzeczywistości obowiązkowe.

    Najlepsze praktyki

    • Zapewnij precyzyjny kontekst i format: Kiedy oczekujesz konkretnej struktury (np. przy dacie), wprost podaj wymagany wzorzec: „Wprowadź datę w formacie DD-MM-RRRR”.
    • Zarządzaj skupieniem uwagi ((ang.) focus management): Natychmiast po nieudanej próbie wysłania formularza przenieś fokus klawiatury na zbiorcze podsumowanie błędów lub na pierwszy element zawierający pomyłkę.
    • Stosuj walidację hybrydową: Zawsze wykonuj ostateczną walidację po stronie serwera jako nienaruszalne zabezpieczenie, dbając o to, by komunikaty z serwera były programowo dostępne po przeładowaniu strony.
    • Wzmacniaj przekaz ikonami: Oprócz koloru, wykorzystuj czytelne symbole ostrzegawcze (np. wykrzykniki), traktując je jako cenne uzupełnienie tekstu.
    • Buduj zbiorcze podsumowania: W rozbudowanych formularzach umieszczaj na samej górze strony sekcję podsumowującą wszystkie pomyłki wraz z linkami kotwiczącymi do konkretnych pól.
    • Dbaj o bliskość przestrzenną: Tekstowe komunikaty o błędach plasuj zawsze w bezpośrednim sąsiedztwie pola, którego dotyczą, ułatwiając lokalizację wizualną i programową.
    • Buduj zaufanie użytkowników: Pamiętaj, że przejrzysta identyfikacja błędów drastycznie zmniejsza frustrację i pozwala na płynną realizację celów wszystkim odbiorcom.

    Metody testowania

    • Narzędzie deweloperskie (ang.) Developer Tools: Przeanalizuj strukturę drzewa DOM i drobiazgowo zweryfikuj, czy wadliwe pole wejściowe dynamicznie otrzymuje atrybut aria-invalid="true" oraz czy jego aria-describedby bezbłędnie odpowiada identyfikatorowi kontenera z tekstem błędu.
    • NVDA: Uruchom czytnik ekranu i zweryfikuj, czy po przejściu klawiaturą do zidentyfikowanego pola otrzymujesz pełny komunikat o błędzie bez patrzenia na monitor oraz czy funkcja role="alert" wymusza natychmiastowe ogłoszenie pomyłki.
    • ANDI.JS: Aktywuj ten moduł testowy, aby precyzyjnie sprawdzić, co „widzi” technologia asystująca – narzędzie podświetli elementy formularza i wyświetli tekst zastępczy oraz przypisane opisy błędów, ułatwiając weryfikację kontekstu.

    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-1/

    #1 DOBRZE

    Dlaczego: Jest to wzorcowa implementacja. Po wystąpieniu błędu pole otrzymuje aria-invalid="true" oraz aria-describedby="tc1-error". Sam komunikat ma role="alert" (co wymusza jego natychmiastowe odczytanie), a tekst jasno wyjaśnia, na czym polega problem (wymagane 11 cyfr).

    #2 DOBRZE

    Dlaczego: Komunikat błędu jest niezwykle precyzyjny. Nie tylko informuje o błędzie, ale podaje oczekiwany wzorzec (DD-MM-RRRR) oraz konkretny przykład (15-05-2026). Pole jest poprawnie powiązane atrybutami ARIA.

    #3 BŁĄD

    Problem: Po kliknięciu „Wyślij” pole otrzymuje jedynie czerwoną ramkę (klasę CSS). Brak komunikatu tekstowego oraz atrybutu aria-invalid.
    Dlaczego: Zmiany czysto wizualne są niewidoczne dla czytników ekranu. Użytkownik niewidomy nie dowie się, że wystąpił błąd, ani jak go naprawić.
    Naprawa: Dodaj tekstowy opis błędu, powiąż go z polem za pomocą aria-describedby i ustaw aria-invalid="true".

    #4 BŁĄD

    Problem: Komunikat tekstowy się pojawia, ale pole wejściowe nie posiada atrybutu aria-describedby wskazującego na ID tego komunikatu, ani aria-invalid="true".
    Dlaczego: Czytnik ekranu odczyta pole jako zwykły, poprawny input. Komunikat błędu jest w DOM, ale nie jest programowo powiązany z polem, więc użytkownik musiałby go samodzielnie szukać.
    Naprawa: Dodaj do inputa: aria-invalid="true" aria-describedby="tc4-error".

    #5 BŁĄD

    Problem: Mimo zastosowania poprawnych atrybutów ARIA, treść komunikatu to lakoniczne „Błąd.”.
    Dlaczego: Kryterium 3.3.1 wymaga, aby błąd został precyzyjnie wyjaśniony. Komunikat „Błąd” nie dostarcza użytkownikowi żadnej wskazówki, jak ma poprawić wprowadzone dane (np. jakiego formatu daty oczekuje system).
    Naprawa: Zmień treść na jasną instrukcję, np. „Wprowadź datę w formacie DD-MM-RRRR”.

    #6 BŁĄD

    Problem: Komunikat o błędzie pojawia się po kliknięciu, ale znika automatycznie po 3 sekundach.
    Dlaczego: Zbyt szybkie usuwanie komunikatów z ekranu to częsty błąd. Użytkownik może nie zdążyć go przeczytać lub zrozumieć. Komunikat o błędzie walidacji powinien pozostać widoczny tak długo, aż użytkownik nie poprawi danych w polu.
    Naprawa: Usuń skrypt automatycznie ukrywający błąd po czasie.

    Źródła

    Dodatkowe linki

    Wróć do wszystkich kryteriów