Wróć do wszystkich kryteriów

3.2.2 Przy wprowadzaniu danych (ang.) On Input

Specjalizacje:

  • Designer
  • Deweloper

Elementy:

  • Formularze

Poziomy:

  • A

Spis treści

    Istota i cel kryterium

    Kryterium sukcesu 3.2.2 nakłada na twórców bezwzględny obowiązek projektowania komponentów interfejsu w taki sposób, aby modyfikacja stanu lub wartości dowolnego elementu nie powodowała automatycznej, niesygnalizowanej zmiany kontekstu przed wejściem w interakcję.

    Głównym celem tej wytycznej jest zagwarantowanie absolutnej przewidywalności środowiska cyfrowego oraz ochrona użytkownika przed dezorientacją i nagłą utratą punktu odniesienia. Niespodziewane przeładowania stron, wymuszone przekierowania czy otwieranie nowych okien drastycznie zwiększają obciążenie poznawcze, wywołując stres i budując krytyczne bariery dostępności.

    Wdrożenie tego standardu oznacza, że system rezygnuje z agresywnej automatyzacji na rzecz pełnej podmiotowości użytkownika. Wszelkie kluczowe operacje o charakterze zwrotnym – takie jak wysłanie danych czy modyfikacja widoku – muszą być inicjowane wyłącznie przez celowe, świadome działanie człowieka za pomocą dedykowanych przycisków akcji.

    Definicja w j. angielskim

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

    Definicja w j. polskim

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

    Słownik pojęć

    Zmiana kontekstu (ang.) change of context
    –

    to istotna i głęboka modyfikacja zawartości bądź działania strony, która gwałtownie przekształca środowisko użytkownika. Do tej kategorii zaliczasz przejście do nowej podstrony, przeniesienie punktu uwagi na inny komponent, automatyczne przeładowanie danych, nieoczekiwane otwarcie wyskakującego okna czy zmianę celu albo funkcji samego komponentu.

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

    • Użytkownicy czytników ekranu: Te technologie wspomagające przetwarzają kod sekwencyjnie. Nagłe przeładowanie lub przekierowanie bez ostrzeżenia sprawia, że czytnik gubi aktualną pozycję, pozostawiając człowieka w stanie całkowitej dezorientacji.
    • Osoby z niepełnosprawnościami poznawczymi: Dla tej grupy stabilne i przewidywalne środowisko to absolutny fundament. Chaotyczne reakcje interfejsu drastycznie zwiększają obciążenie poznawcze i uniemożliwiają sprawne ukończenie zadania.
    • Użytkownicy nawigujący wyłącznie klawiaturą: Każda automatyczna zmiana grozi natychmiastową utratą fokusu. Zmuszasz ich wtedy do ponownego, niezwykle uciążliwego przeszukiwania całej strony od początku.
    • Osoby słabowidzące: Korzystając z dużego powiększenia ekranu, widzą one jedynie mały wycinek interfejsu. Gdy strona samoczynnie zmieni kontekst, śledzenie dynamicznych modyfikacji staje się dla nich fizycznie niemożliwe.
    • Osoby z ograniczeniami motorycznymi: Przypadkowe kliknięcie lub dotknięcie elementu nie może skutkować natychmiastowym wysłaniem formularza, ponieważ prowadzi to do bezpowrotnej utraty wprowadzonych danych i postępów.

    Zasady wdrażania i wymagania techniczne

    • Wdrażaj jawne przyciski akcji: Zrezygnuj z automatyzacji na rzecz kontroli i zawsze stosuj tradycyjne przyciski typu „Wyślij”, „Zapisz” lub „Kontynuuj”. Użytkownik musi podjąć w pełni świadomą decyzję o przekazaniu danych.
    • Porzuć agresywne zdarzenia JavaScript: Bezwzględnie unikaj stosowania atrybutów onchange lub onclick do wywoływania natychmiastowego przeładowania strony, automatycznego przesyłania formularza czy wymuszania nawigacji po samej modyfikacji wartości pola.
    • Zabezpiecz dynamiczne filtrowanie i sortowanie: Jeśli projektujesz mechanizm filtrów aktualizujący listę wyników w czasie rzeczywistym, wykonaj to bez przeładowania całej strony. Wykorzystaj regiony dynamiczne ARIA – dopisz do kontenera wynikowego atrybut aria-live="polite", dzięki czemu czytniki ekranu płynnie zasygnalizują aktualizację danych bez wyrywania użytkownika z bieżącego kontekstu.
    • Stosuj bezpieczną walidację: Wyświetlanie komunikatów o błędach bezpośrednio przy polach formularza jest w pełni zgodne z wytycznymi. Taka walidacja jedynie wzbogaca bieżący widok o niezbędne informacje i nie stanowi niedozwolonej zmiany kontekstu.
    • Uprzedzaj o nietypowych automatycznych zachowaniach: Jeżeli specyfika systemu bezwzględnie wymusza automatyczną akcję, umieść jasną i czytelną informację tekstową tuż obok elementu sterującego, zanim użytkownik rozpocznie interakcję.

    Wyjątki i sytuacje szczególne

    Reguła ta traci swój restrykcyjny charakter wyłącznie w ściśle określonych przypadkach:

    • Wcześniejsze uprzedzenie o skutkach akcji: Interfejs spełni kryteria, jeśli przed interakcją wyświetlisz jednoznaczny komunikat, na przykład: „Wybór opcji z tej listy spowoduje automatyczne przejście do następnego kroku zamówienia”.
    • Modyfikacje oczekiwane i nieorientujące: Dopuszczalne są drobne, intuicyjne zmiany na stronie, które nie wywracają do góry nogami struktury widoku. Przykładem jest natychmiastowe przeliczenie sumy końcowej w koszyku zakupowym po edycji liczby sztuk produktu – użytkownik spodziewa się tej reakcji i nie redefiniuje ona jego pozycji w serwisie.

    Przykłady implementacji

    Najczęstsze błędy

    • F36: Automatyczne przesyłanie formularza i prezentowanie nowej zawartości bez wcześniejszego ostrzeżenia w momencie, gdy ostatnie pole w formularzu otrzyma wartość (np. automatyczny submit po wpisaniu ostatniej cyfry numeru telefonu).
    • F37: Otwieranie nowego okna przeglądarki lub nowej karty bez uprzedniego ostrzeżenia w wyniku samej zmiany stanu przycisku radiowego (<input type="radio">), pola wyboru (checkbox) lub elementu listy rozwijanej (select).

    Najlepsze praktyki

    • Wdróż zasadę progresywnego ulepszania: Zaprojektuj funkcjonalność tak, aby jej rdzeń działał w 100% poprawnie w oparciu o czysty kod HTML i tradicionalny mechanizm przesyłania danych. Dopiero na tę stabilną bazę nakładaj warstwy JavaScriptu podnoszące dynamikę interfejsu.
    • Zapewnij bezkompromisową kontrolę użytkownika: Pozostaw pełną decyzyjność człowiekowi, dbając o to, aby każda kluczowa, nieodwracalna operacja w systemie bezwzględnie wymagała wyraźnego i jednoznacznego kliknięcia przycisku zatwierdzającego.
    • Pielęgnuj absolutną przewidywalność: Projektuj interfejsy tak, aby ich zachowanie było maksymalnie spójne i jednolite w obrębie całego serwisu. Użytkownik już przed interakcją powinien intuicyjnie rozumieć, jak zareaguje system.
    • Komunikuj czysto i klarownie: Jeśli zmuszony jesteś wdrożyć niestandardowe zachowanie komponentu, poinformuj o tym użytkownika prostym, widocznym tekstem przed rozpoczęciem pracy z elementem sterującym.
    • Testuj z technologiami wspomagającymi: Regularnie weryfikuj formularze i elementy interaktywne, angażując rzeczywistych użytkowników oraz samodzielnie sprawdzając kod za pomocą wyłącznie klawiatury oraz czytników ekranu.

    Metody testowania

    • Narzędzie deweloperskie (ang.) Developer Tools: Otwórz drzewo strukturalne podglądu kodu i drobiazgowo przeanalizuj zdarzenia przypisane do elementów interaktywnych. Upewnij się, że nie zaimplementowano tam skryptów reagujących na zdarzenie onfocus, które wymuszają przeładowanie zawartości, usuwanie punktu uwagi lub automatyczną wysyłkę formularza.
    • NVDA: Uruchom czytnik ekranu i wykonaj pełne przejście po wszystkich aktywnych komponentach witryny za pomocą klawisza Tab. Sprawdź, czy syntezator mowy nie zaczyna nagle odczytywać nieoczekiwanych komunikatów z innych części serwisu i czy nie dochodzi do wymuszonych przeskoków bez Twojej wiedzy.

    Sprawdź swoją wiedzę

    W linku poniżej znajduje się 6 różnych formularzy i kontrolek interfejsu. Twoim zadaniem jest sprawdzenie, jak system reaguje na wprowadzenie danych lub zmianę wyboru przez użytkownika.

    Jak to sprawdzić?

    1. Wejdź w interakcję z każdym elementem: wpisz tekst, wybierz opcję z listy rozwijanej lub zaznacz pole wyboru.
    2. Zwróć uwagę, czy sama zmiana wartości (bez kliknięcia przycisku zatwierdzającego) powoduje automatyczną zmianę kontekstu (np. przeładowanie strony, wysłanie formularza, otwarcie nowego okna).
    3. Sprawdź, czy przed ewentualną automatyczną akcją wyświetlane jest jasne ostrzeżenie.
    4. Pamiętaj, że wyświetlenie komunikatu o błędzie walidacji lub przeliczenie sumy (bez przeładowania) to dozwolone zachowania.

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

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

    #1 BŁĄD

    Problem: Po wpisaniu czwartej cyfry formularz wysyła się automatycznie (symulacja przekierowania).
    Dlaczego: Jest to błąd opisany w technice W3C F36. Automatyczne przesyłanie formularza i prezentowanie nowej zawartości bez wcześniejszego ostrzeżenia po wypełnieniu ostatniego pola to niedozwolona zmiana kontekstu. Użytkownik nie ma szansy sprawdzić wprowadzonych danych.
    Naprawa: Należy dodać wyraźny przycisk „Zweryfikuj” lub „Wyślij”, aby użytkownik sam zainicjował akcję.

    #2 BŁĄD

    Problem: Wybranie opcji z listy rozwijanej (zdarzenie onchange) powoduje natychmiastowe przeładowanie strony (symulacja).
    Dlaczego: Użytkownicy klawiatury przeglądający listę za pomocą strzałek góra/dół wywołują zmianę wartości po każdym naciśnięciu klawisza. Automatyczne przeładowanie uniemożliwia im dotarcie do opcji znajdujących się niżej na liście.
    Naprawa: Należy dodać przycisk „Zmień język” obok listy rozwijanej.

    #3 DOBRZE

    Dlaczego: Zmiana wartości na liście rozwijanej nie wywołuje żadnej akcji. Użytkownik ma pełną kontrolę – dopiero świadome kliknięcie przycisku „Zastosuj” powoduje zmianę motywu. Jest to wzorcowe podejście, gwarantujące przewidywalność interfejsu.

    #4 DOBRZE

    Dlaczego: Po wpisaniu błędnego adresu e-mail i opuszczeniu pola (zdarzenie blur) pojawia się komunikat o błędzie. Wyświetlanie komunikatów walidacji nie jest zmianą kontekstu – to jedynie aktualizacja bieżącego widoku, która pomaga użytkownikowi. Jest to w pełni zgodne z wytycznymi.

    #5 DOBRZE

    Dlaczego: Chociaż zmiana wartości na liście powoduje automatyczne przejście do innego działu (zmianę kontekstu), interfejs spełnia kryteria, ponieważ przed interakcją wyświetlono jednoznaczny komunikat ostrzegający o skutkach akcji. Użytkownik jest świadomy, co się wydarzy.

    #6 BŁĄD

    Problem: Zaznaczenie pola wyboru (checkbox) powoduje automatyczne otwarcie nowej karty w przeglądarce (symulacja).
    Dlaczego: Jest to błąd opisany w technice W3C F37. Otwieranie nowego okna lub karty bez uprzedniego ostrzeżenia w wyniku zmiany stanu kontrolki to drastyczna zmiana kontekstu, która całkowicie dezorientuje użytkowników (szczególnie korzystających z czytników ekranu).
    Naprawa: Checkbox powinien jedynie zmieniać swój stan (zaznaczony/odznaczony). Link do regulaminu powinien być osobnym, standardowym odnośnikiem <a>.

    Źródła

    Dodatkowe linki

    Wróć do wszystkich kryteriów