WCAG 3.2.2: Po wprowadzeniu

Co oznacza ta reguła

WCAG 3.2.2 On Input jest częścią zasady Zrozumiałość i podlega wytycznej 3.2 Przewidywalność. Stanowi, że zmiana ustawienia jakiegokolwiek komponentu interfejsu użytkownika nie może automatycznie powodować zmiany kontekstu, chyba że użytkownik został wcześniej poinformowany, że takie zachowanie nastąpi.

Zmiana kontekstu to istotna zmiana treści strony internetowej, która może zdezorien­tować użytkowników, którzy nie widzą całej strony naraz. Zgodnie ze specyfikacją WCAG, zmiany kontekstu obejmują: zmianę agenta użytkownika (przeglądarki), zmianę obszaru wyświetlania (viewport), zmianę fokusu oraz zmianę treści, która znacząco zmienia znaczenie strony. Wysłanie formularza, otwarcie nowego okna lub przejście na inną stronę to przykłady zmian kontekstu. Samo ujawnienie dodatkowej treści, takiej jak rozwijany akordeon, nie jest zmianą kontekstu.

Kryterium dotyczy konkretnie zmiany ustawienia komponentu interfejsu — na przykład zaznaczenia przycisku radiowego, zaznaczenia pola wyboru lub wybrania opcji w rozwijanym polu <select> — w odróżnieniu od aktywowania kontrolki (jak kliknięcie przycisku). Jeśli działanie wymaga wyraźnego kroku aktywacji (naciśnięcie Enter, kliknięcie Wyślij), zazwyczaj nie podlega temu kryterium. Problemem jest wzorzec, w którym samo wybranie wartości natychmiast wywołuje nawigację lub znaczące przeładowanie strony bez jakiegokolwiek ostrzeżenia.

Co jest uznawane za spełnienie: Formularz, który używa przycisku wysyłania do przetworzenia wyborów użytkownika, nawet jeśli wybory te obejmują listy rozwijane lub pola wyboru, spełnia to kryterium. Lista rozwijana, która filtruje wyniki na tej samej stronie bez przeładowania lub istotnego przeniesienia fokusu, spełnia kryterium. Strona, która z wyprzedzeniem informuje użytkowników — na przykład widoczną notatką „Wybranie języka spowoduje przeładowanie strony” — że dane pole wejściowe wywoła zmianę kontekstu, również spełnia kryterium.

Co jest uznawane za niespełnienie: Selektor kraju lub języka, który automatycznie przekierowuje użytkownika na nowy adres URL w momencie wybrania opcji, nie spełnia kryterium. Formularz, który automatycznie się wysyła i przechodzi dalej, gdy zaznaczony zostanie przycisk radiowy, bez jakiegokolwiek przycisku wysyłania, nie spełnia kryterium. Widżet autouzupełniania, który po wyborze przenosi fokus klawiatury do nowego obszaru strony bez ostrzeżenia, również nie spełnia kryterium.

Oficjalne wyjątki: Specyfikacja WCAG wskazuje, że jeśli użytkownik zostanie poinformowany o zachowaniu przed użyciem komponentu, automatyczna zmiana kontekstu jest dopuszczalna. Informacja ta musi być dostępna przed wystąpieniem interakcji, a nie po niej.

Dlaczego to ma znaczenie

Nieoczekiwane zmiany kontekstu należą do najbardziej dezorientujących doświadczeń w sieci, a ich wpływ jest dramatycznie spotęgowany w przypadku użytkowników z niepełnosprawnościami. Gdy strona nagle nawiguję, przeładowuje się lub przenosi fokus bez ostrzeżenia, użytkownicy, którzy nie widzą pełnego układu strony, całkowicie tracą orientację.

Użytkownicy czytników ekranu są szczególnie narażeni. Gdy niewidomy użytkownik korzystający z NVDA lub JAWS wybiera opcję z listy rozwijanej, a strona natychmiast się przeładowuje lub nawiguję, czytnik ekranu ogłasza nowy kontekst strony od początku. Użytkownik traci orientację, gdzie był, co robił i musi ponownie przejść przez całą stronę, aby się odnaleźć. Nie jest to drobna niedogodność — może to sprawić, że zadanie stanie się całkowicie niemożliwe do samodzielnego wykonania.

Użytkownicy korzystający wyłącznie z klawiatury, w tym osoby z niepełnosprawnościami ruchowymi, które nie mogą używać myszy, napotykają podobny problem. Mogą nawigować po formularzu za pomocą klawisza Tab i strzałek i przypadkowo wywołać zmianę kontekstu, której nie zamierzali. Bez precyzyjnej kontroli ruchowej odzyskanie kontroli po niezamierzonej nawigacji może wymagać znacznego wysiłku.

Niepełnosprawności poznawcze dodatkowo potęgują problem. Użytkownicy z zaburzeniami uwagi, trudnościami w uczeniu się lub zaburzeniami pamięci polegają na przewidywalnych, stabilnych interfejsach, aby zrozumieć, co się dzieje. Nagłe zmiany kontekstu burzą model mentalny, który zbudowali w trakcie sesji, często zmuszając ich do rozpoczęcia od nowa lub porzucenia zadania.

Użytkownicy z zaburzeniami błędnika mogą doświadczać fizycznego dyskomfortu lub dezorientacji, gdy strony zmieniają się niespodziewanie, szczególnie jeśli zmiana obejmuje animację lub przesunięcia pozycji przewijania.

Konkretny scenariusz z życia: rozważ stronę finalizacji zakupu w Turcji, na której użytkownik wybiera swoją prowincję z listy rozwijanej. Jeśli ten wybór natychmiast przeładowuje stronę, aby zaktualizować opcje dostawy, użytkownik czytnika ekranu może nagle znaleźć się na górze strony bez żadnej informacji, co się stało. Musiałby ponownie przejść przez wszystkie pola formularza, aby znaleźć miejsce, w którym był, nie wiedząc, czy jego wcześniejsze dane zostały zachowane. Tego rodzaju tarcie może skłonić użytkowników do całkowitego porzucenia zakupu.

Z perspektywy użyteczności i SEO strony zachowujące się przewidywalnie mają niższe współczynniki odrzuceń. Użytkownicy rzadziej odchodzą sfrustrowani, a roboty wyszukiwarek mogą bardziej niezawodnie indeksować treści bez nieoczekiwanych przekierowań zakłócających ścieżki indeksowania.

Powiązane reguły Axe-core

WCAG 3.2.2 On Input wymaga testów manualnych. Narzędzia automatyczne, takie jak axe-core, nie mogą wiarygodnie wykrywać naruszeń tego kryterium, ponieważ problematyczne zachowanie jest kontekstowe i zależy od intencji stojącej za interakcją, a nie tylko od obecności lub braku konkretnego atrybutu HTML lub struktury. Narzędzie może wykryć, że element <select> ma obsługę zdarzenia onchange, ale nie może ustalić, czy ten handler wywołuje zmianę kontekstu, czy użytkownik został o tym ostrzeżony ani czy wynikające z tego zachowanie jest w praktyce dezorientujące.

• Wymagane testy manualne — wzorce nawigacji oparte na onchange: Skanery automatyczne mogą oznaczyć elementy <select>, <input type='radio'> i <input type='checkbox'> posiadające obsługę zdarzeń JavaScript (szczególnie onchange), ale nie są w stanie ustalić, czy te handlery powodują zmianę kontekstu. Tester musi ręcznie wejść w interakcję z każdą taką kontrolką i zaobserwować, czy strona nawiguję, przeładowuje się, przenosi fokus do zupełnie innego obszaru lub otwiera nowe okno bez wyraźnego kroku aktywacji ze strony użytkownika.
• Wymagane testy manualne — obecność i adekwatność wcześniejszego ostrzeżenia: Nawet jeśli zmiana kontekstu zostanie wykryta, narzędzie automatyczne nie może ustalić, czy użytkownik został o niej odpowiednio uprzedzony przed interakcją z kontrolką. Człowiek musi zweryfikować, że wszelkie wcześniejsze ostrzeżenie jest widoczne przed napotkaniem komponentu, jasno sformułowane i faktycznie opisuje zachowanie, które nastąpi.
• Wymagane testy manualne — zarządzanie fokusem po wprowadzeniu danych: Niektóre naruszenia przejawiają się jako przeniesienie fokusu w nieoczekiwane miejsce po zmianie wartości, a nie jako jawna nawigacja. Narzędzia automatyczne nie są w stanie wiarygodnie śledzić docelowych miejsc fokusu wywołanych przez zdarzenia onchange i potwierdzić, czy wynikowe umiejscowienie fokusu stanowi dezorientującą zmianę kontekstu.

Jak testować

1. Automatyczny skan bazowy: Uruchom axe DevTools lub Lighthouse na stronie, aby zidentyfikować wszelkie oznaczone problemy w ramach WCAG 3.2. Choć samo 3.2.2 wymaga testów manualnych, axe może ujawnić powiązane problemy (takie jak brakujące etykiety lub problemy z zarządzaniem fokusem), które stanowią punkt wyjścia. Zanotuj wszystkie kontrolki formularza — szczególnie listy rozwijane <select>, grupy przycisków radiowych i pola wyboru — do ręcznego sprawdzenia.
2. Zidentyfikuj wszystkie kontrolki wejściowe z handlerami zmiany: W narzędziach deweloperskich przeglądarki przeanalizuj JavaScript strony lub użyj panelu Event Listeners, aby zidentyfikować wszelkie elementy <select>, <input type='radio'>, <input type='checkbox'> lub niestandardowe widżety, które mają podłączone zdarzenia onchange, oninput lub równoważne listenery.
3. Manualny test interakcji klawiaturą: Używając wyłącznie klawiatury (Tab do nawigacji, klawisze strzałek do opcji radio/select), wejdź w interakcję z każdą zidentyfikowaną kontrolką. Obserwuj, czy wybranie opcji powoduje nawigację strony, przeładowanie, otwarcie nowego okna lub przeniesienie fokusu do znacznie innej części strony. Jeśli tak, sprawdź, czy przed napotkaniem kontrolki wyświetlone było widoczne ostrzeżenie.
4. Test NVDA + Firefox: Uruchom Firefox z aktywnym NVDA. Nawiguj do każdej kontrolki formularza za pomocą wirtualnego kursora NVDA (klawisze strzałek), a następnie wchodź w interakcję w trybie formularzy (Enter lub Spacja). Wybieraj opcje w listach rozwijanych i grupach radiowych i nasłuchuj wszelkich nieoczekiwanych komunikatów wskazujących na załadowanie strony, nawigację lub dużą zmianę kontekstu. Zwróć uwagę, czy NVDA odczytuje nowy tytuł strony lub zupełnie inny obszar.
5. Test VoiceOver + Safari (macOS/iOS): Włącz VoiceOver i nawiguj do każdej kontrolki za pomocą VO+strzałka w prawo. Wchodź w interakcję z listami rozwijanymi i polami wyboru. Jeśli nastąpi zmiana kontekstu, VoiceOver zazwyczaj ogłosi nową stronę lub przeniesienie fokusu. Ustal, czy użytkownik został o tym uprzedzony.
6. Test JAWS + Chrome: Użyj JAWS w trybie wirtualnego kursora, aby nawigować po stronie. Wchodź w interakcję z kontrolkami formularza i monitoruj, czy JAWS ogłasza zmianę kontekstu (zmiana tytułu strony, nowy adres URL, przesunięta pozycja odczytu) natychmiast po wprowadzeniu danych — bez aktywacji przycisku wysyłania.
7. Test obserwacji wizualnej: Dla użytkowników widzących, bez technologii asystujących, wybieraj opcje w każdej liście rozwijanej i grupie radiowej i obserwuj, czy strona nawiguję lub przeładowuje się niespodziewanie. Jeśli tak, sprawdź, czy jakikolwiek tekst instruktażowy widoczny przed kontrolką ostrzegał o takim zachowaniu.

Jak naprawić

Automatycznie wysyłająca lista rozwijana select — niepoprawne

<!-- BAD: Selecting a country immediately redirects the page -->
<label for='country'>Select Country</label>
<select id='country' name='country' onchange='window.location.href="/region/" + this.value'>
  <option value='tr'>Turkey</option>
  <option value='de'>Germany</option>
  <option value='us'>United States</option>
</select>

Automatycznie wysyłająca lista rozwijana select — poprawne

<!-- GOOD: Selection is confirmed via a submit button; no automatic navigation -->
<form action='/region/' method='get'>
  <label for='country'>Select Country</label>
  <select id='country' name='country'>
    <option value='tr'>Turkey</option>
    <option value='de'>Germany</option>
    <option value='us'>United States</option>
  </select>
  <!-- Explicit submit button gives the user control over when navigation occurs -->
  <button type='submit'>Go</button>
</form>

Wzorzec automatycznego wysyłania przycisku radiowego — niepoprawne

<!-- BAD: Selecting a payment method immediately submits the form -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='this.form.submit()'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='this.form.submit()'>
    Bank Transfer
  </label>
</fieldset>

Wzorzec automatycznego wysyłania przycisku radiowego — poprawne

<!-- GOOD: onchange can update UI state without navigating; submit requires user action -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='showPaymentDetails(this.value)'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='showPaymentDetails(this.value)'>
    Bank Transfer
  </label>
</fieldset>
<!-- showPaymentDetails() reveals additional fields inline — no context change -->
<div id='payment-details' aria-live='polite'></div>
<button type='submit'>Confirm Payment</button>

Przełącznik języka z wcześniejszym ostrzeżeniem — poprawne

<!-- ACCEPTABLE: User is warned before interacting that selecting will reload the page -->
<p id='lang-notice'>Selecting a language will immediately reload the page.</p>
<label for='lang-select'>Language</label>
<select
  id='lang-select'
  name='lang'
  aria-describedby='lang-notice'
  onchange='window.location.href="/" + this.value + "/"'
>
  <option value='en'>English</option>
  <option value='tr'>Türkçe</option>
  <option value='de'>Deutsch</option>
</select>
<!-- The aria-describedby links the warning to the control for screen reader users -->

Typowe błędy

• Bezpośrednie przypisywanie window.location.href do atrybutu onchange elementu <select> bez przycisku wysyłania, co powoduje natychmiastową nawigację strony w momencie wybrania opcji.
• Używanie this.form.submit() wewnątrz handlera onchange przycisku radiowego, co wysyła cały formularz i przechodzi dalej natychmiast po wybraniu opcji radiowej — zanim użytkownik będzie mógł przejrzeć swoje wybory.
• Umieszczanie wcześniejszego ostrzeżenia po kontrolce w DOM, przez co użytkownicy czytników ekranu i nawigujący klawiaturą napotykają kontrolkę, zanim usłyszą lub przeczytają ostrzeżenie o zachowaniu, które wywołuje.
• Wyświetlanie wcześniejszego ostrzeżenia wyłącznie jako podpowiedzi (tooltip) lub tekstu zastępczego (placeholder), które nie są wiarygodnie eksponowane technologiom asystującym, pozostawiając użytkowników czytników ekranu bez informacji, że po ich wejściu nastąpi zmiana kontekstu.
• Budowanie niestandardowych widżetów list rozwijanych z użyciem elementów <div> i <ul>, które wywołują nawigację przy wyborze za pomocą JavaScript, ale nie mają semantycznej struktury pozwalającej testerom lub nakładkom dostępności zidentyfikować je jako kontrolki interaktywne wymagające weryfikacji pod kątem 3.2.2.
• Wywoływanie automatycznego wysłania formularza w ostatnim polu formularza (na przykład w polu PIN lub OTP) w momencie osiągnięcia wymaganej liczby znaków, bez poinformowania użytkownika, że tak się stanie.
• Otwieranie okna modalnego lub nowego okna przeglądarki w odpowiedzi na zaznaczenie pola wyboru, bez wcześniejszego ostrzeżenia — stanowi to zmianę kontekstu, ponieważ znacząco zmienia obszar wyświetlania i fokus użytkownika.
• Mylenie przewidywalnych aktualizacji treści na stronie ze zmianami kontekstu i dodawanie niepotrzebnych przycisków wysyłania wokół interakcji, które są już akceptowalne (jak filtr wyszukiwania na żywo), co może zaśmiecać interfejs — zespoły powinny rozumieć, że liniowe, niedezorientujące aktualizacje nie wymagają kroku wysyłania.
• Poleganie wyłącznie na automatycznych skanach dostępności i oznaczanie 3.2.2 jako spełnionego, ponieważ żadne automatyczne reguły go nie zgłosiły, bez przeprowadzenia obowiązkowych manualnych testów klawiaturą i czytnikami ekranu, których to kryterium wymaga.
• Stosowanie handlera onchange powodującego zmianę kontekstu w elemencie <select> używanym do sortowania lub filtrowania na liście wyników, co powoduje pełne przeładowanie strony zamiast aktualizacji AJAX i brak ostrzeżenia użytkowników, że przeładowanie nastąpi po wyborze.

Związek z tureckimi regulacjami dotyczącymi dostępności

Turecka Okrężnica Prezydencka 2025/10, opublikowana w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia obowiązkowe wymagania dostępności stron internetowych oparte na WCAG 2.2. WCAG 3.2.2 On Input jest kryterium poziomu A, które stanowi minimalną podstawę zgodności w ramach okrężnicy — co oznacza, że przestrzeganie nie jest opcjonalne, lecz prawnie wymagane dla wszystkich objętych podmiotów.

Okrężnica definiuje dwuetapowy harmonogram wdrożenia. Instytucje publiczne — w tym ministerstwa, gminy, uniwersytety państwowe i agencje rządowe — muszą osiągnąć pełną zgodność z poziomem A w ciągu jednego roku od publikacji okrężnicy. Podmioty sektora prywatnego objęte regulacją mają dwuletnie okno na dostosowanie się.

Następujące typy podmiotów są wyraźnie objęte okrężnicą i muszą zapewnić, że ich usługi cyfrowe są zgodne z WCAG 3.2.2: platformy e-commerce, instytucje publiczne na wszystkich poziomach administracji, banki i instytucje finansowe, szpitale i świadczeniodawcy opieki zdrowotnej, firmy telekomunikacyjne z 200,000 lub większą liczbą abonentów, licencjonowane biura podróży, prywatne firmy transportowe oraz szkoły prywatne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE).

Dla tych podmiotów naruszenie WCAG 3.2.2 — takie jak selektor języka w portalu bankowym, który automatycznie przekierowuje po wyborze, lub formularz rejestracji wizyty w szpitalu, który automatycznie wysyła się po wybraniu przycisku radiowego z nazwą oddziału — stanowi bezpośrednią niezgodność regulacyjną. Biorąc pod uwagę, że Turcja ma znaczną populację użytkowników z niepełnosprawnościami oraz że cyfrowe usługi rządowe stają się coraz częściej głównym kanałem dostępu obywateli do usług publicznych, praktyczne konsekwencje ignorowania tego kryterium są istotne.

Organizacje objęte okrężnicą powinny traktować testowanie WCAG 3.2.2 jako obowiązkowy krok audytowy w trakcie QA. Ponieważ narzędzia automatyczne nie są w stanie wykryć naruszeń tego kryterium, testy manualne prowadzone przez przeszkolonych specjalistów ds. dostępności — obejmujące interakcję klawiaturą, zachowanie czytników ekranu NVDA i JAWS oraz szczegółowy przegląd wszystkich interakcji opartych na onchange — muszą być wbudowane w proces zapewniania zgodności. Dokumentowanie wyników testów i wszelkich zaakceptowanych wyjątków (z wdrożonymi wcześniejszymi ostrzeżeniami) jest zalecane w celu wykazania należytej staranności przed organami regulacyjnymi.