WCAG 3.3.7: Zbędne wprowadzanie danych

Co Oznacza Ta Zasada

WCAG 3.3.7 Redundant Entry (Powtórne wprowadzanie danych) to kryterium sukcesu na poziomie A wprowadzone w WCAG 2.2. Stanowi ono: „Informacje wcześniej wprowadzone przez użytkownika lub mu dostarczone, które muszą zostać ponownie wprowadzone w tym samym procesie, są albo automatycznie uzupełniane, albo dostępne do wyboru przez użytkownika.” Mówiąc prościej: jeśli użytkownik wpisał już swój adres e‑mail, adres dostawy, datę urodzenia lub jakąkolwiek inną informację w trakcie sesji, interfejs nie może zmuszać go do ponownego wpisywania tych samych danych w ramach tego samego procesu lub przepływu.

Kryterium ma szerokie zastosowanie do wszelkich wieloetapowych formularzy, procesów zakupowych (checkout), kreatorów rejestracji, przepływów rezerwacji wizyt oraz podobnych sekwencji, w których dane zebrane na jednym etapie mogą być potrzebne ponownie na późniejszym etapie. Dotyczy to zachowań takich jak pola tekstowe, listy rozwijane, pola wyboru (checkboxy), przyciski opcji (radio buttony) oraz inne kontrolki formularza zbierające dane od użytkownika. Gdy ta sama informacja jest wymagana ponownie, musi zostać albo automatycznie wstępnie uzupełniona na podstawie wcześniej podanej wartości, albo udostępniona jako opcja do wyboru, tak aby użytkownik mógł ją potwierdzić zamiast wpisywać ponownie.

Zaliczenie tego kryterium wygląda następująco: formularz adresu rozliczeniowego jest wstępnie uzupełniony adresem dostawy, który użytkownik podał na poprzednim ekranie, lub krok potwierdzenia wyświetla wcześniej wprowadzony adres e‑mail użytkownika w polu tylko do odczytu. Innym poprawnym wzorcem jest pole wyboru z etykietą „Mój adres rozliczeniowy jest taki sam jak adres dostawy”, które po zaznaczeniu automatycznie kopiuje wartości. Niezaliczenie wygląda tak: wieloetapowy proces rejestracji, który prosi o adres e‑mail w kroku 1 i ponownie w kroku 3, nie wypełniając wstępnie drugiego pola, lub formularz zgłoszenia roszczenia ubezpieczeniowego, który prosi o imię i nazwisko zgłaszającego oraz numer polisy na kilku oddzielnych ekranach bez żadnego automatycznego uzupełniania.

WCAG 3.3.7 definiuje dwa oficjalne wyjątki. Pierwszy wyjątek ma zastosowanie, gdy ponowne wprowadzenie informacji jest niezbędne dla procesu — na przykład pole „Potwierdź nowe hasło” celowo prosi użytkownika o dwukrotne wpisanie tego samego hasła jako zabezpieczenie przed literówkami i jest to uznawane za istotną kontrolę bezpieczeństwa. Drugi wyjątek ma zastosowanie, gdy wcześniej wprowadzone informacje są już nieaktualne — na przykład, jeśli sesja wygasła lub produkt został wyprzedany i użytkownik musi rozpocząć proces od nowa z aktualnymi danymi. Poza tymi wyjątkami powtórne wprowadzanie danych stanowi naruszenie zgodności.

Dlaczego To Ma Znaczenie

Powtórne wprowadzanie danych w nieproporcjonalny sposób obciąża użytkowników, dla których pisanie jest powolne, bolesne, podatne na błędy lub poznawczo obciążające. Zrozumienie, kogo to dotyczy, pomaga deweloperom i projektantom docenić, że to kryterium to coś więcej niż funkcja wygody — to realna bariera dla wielu osób.

Użytkownicy z niepełnosprawnościami ruchowymi, tacy jak osoby z drżeniem rąk, urazami rdzenia kręgowego lub schorzeniami takimi jak ALS czy stwardnienie rozsiane, mogą polegać na przełącznikach, ustnikach, oprogramowaniu śledzącym ruch gałek ocznych lub sterowaniu głosem do wprowadzania tekstu. Dla tych użytkowników wpisanie nawet krótkiego adresu może zająć kilka minut i wymagać znacznego wysiłku fizycznego. Wymóg powtórzenia tego wpisu nie jest jedynie irytujący — może powodować ból fizyczny lub sprawić, że zadanie będzie praktycznie niewykonalne w jednej sesji.

Użytkownicy z niepełnosprawnościami poznawczymi, w tym z dysleksją, zaburzeniami uwagi, po urazach mózgu oraz z chorobami związanymi z demencją, mogą mieć trudności z przypomnieniem sobie, co wpisali trzy kroki wcześniej. Wielokrotne przepisywanie informacji z pamięci lub z dokumentu papierowego znacząco zwiększa liczbę błędów i porzuceń procesu. Według Światowej Organizacji Zdrowia ponad 1 miliard ludzi na świecie żyje z jakąś formą niepełnosprawności, a niepełnosprawności poznawcze stanowią jeden z największych i najbardziej zaniedbanych segmentów w planowaniu dostępności.

Użytkownicy z różnicami w obrębie kończyn górnych, w tym osoby urodzone z różnicami w budowie kończyn lub które nabyły je w wyniku urazu, piszą znacznie wolniej i mogą korzystać z alternatywnych urządzeń wejściowych. Każde dodatkowe wymagane naciśnięcie klawisza zwielokrotnia obciążenie tych użytkowników.

Rozważ scenariusz z życia wzięty: użytkownik z reumatoidalnym zapaleniem stawów rezerwuje wizytę lekarską przez internetowy portal szpitala. Na ekranie 1 wpisuje swój numer identyfikacyjny, imię i nazwisko, datę urodzenia oraz numer telefonu kontaktowego. Na ekranie 3 portal ponownie prosi o imię i nazwisko oraz datę urodzenia w celu potwierdzenia rekordu pacjenta. Użytkownik musi mozolnie przepisać informacje, które podał zaledwie dwa ekrany wcześniej, ryzykując literówki mogące spowodować niedopasowanie rekordów i doświadczając niepotrzebnego obciążenia fizycznego. Proste wstępne uzupełnienie lub automatyczne wypełnienie tych pól całkowicie usunęłoby tę barierę.

Poza dostępnością, eliminacja powtórnego wprowadzania danych poprawia współczynniki konwersji, zmniejsza liczbę porzuconych formularzy i redukuje zgłoszenia do działu wsparcia spowodowane błędami przy wprowadzaniu danych — dostarczając wymierną wartość biznesową obok projektowania inkluzywnego.

Powiązane Reguły Axe-core

WCAG 3.3.7 to kryterium wymagające testów manualnych. Obecnie nie istnieje żadna zautomatyzowana reguła axe-core, która mogłaby niezawodnie wykrywać naruszenia związane z powtórnym wprowadzaniem danych, ponieważ narzędzia automatyczne nie są w stanie zrozumieć semantycznej relacji między danymi wprowadzanymi na wielu krokach lub stronach w dynamicznym procesie. Nie mają świadomości, jakie informacje zostały zebrane na poprzednim etapie, jakie informacje są żądane na bieżącym etapie ani czy te dwie informacje są logicznie identyczne. Tylko tester‑człowiek, który przejdzie przez cały przepływ, może zaobserwować i ocenić, czy te same dane są żądane dwukrotnie bez wstępnego uzupełnienia.

• Wymagane testy manualne (nowe w WCAG 2.2): axe-core i inne zautomatyzowane skanery dostępności analizują DOM pojedynczego stanu strony naraz. Nie mogą śledzić wartości wprowadzanych przez użytkownika pomiędzy kolejnymi wczytaniami stron lub krokami formularza, nie mogą porównywać etykiet pól między krokami, aby zidentyfikować semantyczne duplikaty, i nie mogą ocenić, czy mechanizm wstępnego uzupełniania działa poprawnie. Testerzy muszą ręcznie przejść przez wieloetapowe procesy, zapisać, jakie dane wprowadzają na każdym etapie, i na każdym kolejnym etapie sprawdzić, czy wcześniej podane dane są albo automatycznie uzupełnione, albo dostępne do wyboru. Każde narzędzie twierdzące, że automatycznie wykrywa naruszenia 3.3.7, generowałoby ekstremalnie wysoki odsetek fałszywie negatywnych wyników i nie powinno być traktowane jako jedyna metoda testowania.

Jak Testować

1. Skan automatyczny jako punkt wyjścia: Uruchom axe DevTools, Lighthouse lub audytor Accsible na każdym indywidualnym kroku wieloetapowego procesu. Choć te narzędzia nie oznaczą bezpośrednio naruszeń 3.3.7, ujawnią powiązane problemy, takie jak brakujące atrybuty autocomplete, nieopisane pola formularza i inne naruszenia kryteriów z grupy 3.3.x, które często współwystępują. Zanotuj każde pole formularza znalezione na każdym kroku.
2. Mapowanie wymagań dotyczących danych między krokami: Przed testami manualnymi utwórz prostą tabelę lub arkusz kalkulacyjny, w którym wypiszesz każdy krok procesu i wszystkie pola danych, które zbiera. Następnie zidentyfikuj każdą etykietę pola lub typ danych, który pojawia się na więcej niż jednym etapie. To ćwiczenie mapowania ujawnia potencjalne naruszenia, zanim jeszcze otworzysz przeglądarkę.
3. Ręczne przejście — desktop: Używając standardowej myszy i klawiatury, przejdź przez cały wieloetapowy proces (np. checkout, rejestracja, złożenie roszczenia). Wprowadź realistyczne wartości we wszystkie pola. Gdy dotrzesz do kroku, który w twojej mapie figuruje jako pole zduplikowane, sprawdź, czy pole jest wstępnie uzupełnione wcześniejszym wpisem lub czy dostępna jest opcja wyboru prezentująca wcześniejszy wpis. Jeśli żaden z tych warunków nie jest spełniony, zanotuj niepowodzenie. Powtórz ten test z czytnikiem ekranu (NVDA z Firefoxem, JAWS z Chrome, VoiceOver z Safari), aby potwierdzić, że wstępnie uzupełnione wartości są poprawnie odczytywane i że kontrolki wyboru wcześniej wprowadzonych wartości są dostępne z klawiatury.
4. Ręczne przejście — mobile: Przejdź przez ten sam przepływ na iOS (VoiceOver + Safari) i Androidzie (TalkBack + Chrome). Zwróć uwagę, czy natywne funkcje autouzupełniania lub autofill nie są blokowane przez aplikację, co mogłoby niezamierzenie tworzyć bariery powtórnego wprowadzania danych, nawet jeśli deweloper zakładał, że autouzupełnianie ma pomagać.
5. Testowanie wyjątków: Zidentyfikuj pola, które celowo proszą o zduplikowane dane (np. potwierdzenie hasła, ponowne wprowadzenie adresu e‑mail). Zweryfikuj, czy kwalifikują się one jako istotne kontrole bezpieczeństwa lub walidacji w ramach wyjątku WCAG, a nie są po prostu zbędnymi polami, które powinny zostać usunięte lub wstępnie uzupełnione.
6. Testowanie z wyłączonym autouzupełnianiem: Niektórzy użytkownicy wyłączają autouzupełnianie przeglądarki ze względów prywatności. Sprawdź, czy własny mechanizm wstępnego uzupełniania aplikacji (po stronie serwera lub oparty na JavaScript) nadal działa poprawnie, gdy autouzupełnianie przeglądarki jest wyłączone, tak aby kryterium było spełnione niezależnie od zachowania przeglądarki.

Jak Naprawić

Wieloetapowy checkout — ten sam adres wymagany na dwóch ekranach — Niepoprawne

<!-- Step 1: Shipping Address -->
<form id='shipping-form'>
  <label for='ship-name'>Full Name</label>
  <input type='text' id='ship-name' name='shipping_name'>

  <label for='ship-street'>Street Address</label>
  <input type='text' id='ship-street' name='shipping_street'>

  <label for='ship-city'>City</label>
  <input type='text' id='ship-city' name='shipping_city'>
</form>

<!-- Step 2: Billing Address — user must type everything again -->
<form id='billing-form'>
  <label for='bill-name'>Full Name</label>
  <input type='text' id='bill-name' name='billing_name'>

  <label for='bill-street'>Street Address</label>
  <input type='text' id='bill-street' name='billing_street'>

  <label for='bill-city'>City</label>
  <input type='text' id='bill-city' name='billing_city'>
</form>

Wieloetapowy checkout — ten sam adres wymagany na dwóch ekranach — Poprawne

<!-- Step 2: Billing Address — pre-fill option provided -->
<form id='billing-form'>
  <!-- Checkbox allows user to confirm same address rather than re-type it -->
  <input type='checkbox' id='same-as-shipping' name='same_as_shipping'>
  <label for='same-as-shipping'>My billing address is the same as my shipping address</label>

  <div id='billing-fields'>
    <!-- Fields are pre-populated server-side with shipping values;
         JavaScript can also copy values when checkbox is unchecked -->
    <label for='bill-name'>Full Name</label>
    <input type='text' id='bill-name' name='billing_name' value='Jane Doe' autocomplete='billing name'>

    <label for='bill-street'>Street Address</label>
    <input type='text' id='bill-street' name='billing_street' value='123 Elm Street' autocomplete='billing street-address'>

    <label for='bill-city'>City</label>
    <input type='text' id='bill-city' name='billing_city' value='Ankara' autocomplete='billing address-level2'>
  </div>
</form>

Kreator rejestracji proszący o e‑mail dwa razy bez uzasadnienia — Niepoprawne

<!-- Step 1 collected email. Step 3 asks again with no pre-fill. -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <input type='email' id='confirm-email' name='confirm_email'>
  <!-- No value pre-populated; user must type the same email entered on step 1 -->
</fieldset>

Kreator rejestracji — e‑mail wstępnie uzupełniony z danych sesji — Poprawne

<!-- Server renders the previously collected email into the value attribute -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <!-- value is injected from server-side session; user can correct if needed -->
  <input type='email' id='confirm-email' name='confirm_email'
         value='[email protected]' autocomplete='email'>
</fieldset>

Rezerwacja wizyty — dane pacjenta ponownie wymagane w kroku podsumowania — Niepoprawne

<!-- Summary step re-asks for date of birth already entered in patient info step -->
<label for='dob-confirm'>Date of Birth</label>
<input type='date' id='dob-confirm' name='dob_confirm'>
<!-- Empty field requires user to re-enter DOB from memory or paper -->

Rezerwacja wizyty — data urodzenia pokazana jako potwierdzenie tylko do odczytu — Poprawne

<!-- Previously entered DOB displayed in a read-only field for review;
     a hidden input carries the value for form submission -->
<label for='dob-confirm'>Date of Birth (from your patient record)</label>
<input type='date' id='dob-confirm' name='dob_confirm'
       value='1985-04-12' readonly aria-describedby='dob-hint'>
<span id='dob-hint'>This value was entered earlier. Contact support if it is incorrect.</span>

Typowe Błędy

• Budowanie wieloetapowych formularzy jako niezależnych stron bez współdzielonego stanu sesji, przez co nie ma mechanizmu przenoszenia wartości wprowadzonych na wcześniejszych etapach — najbardziej fundamentalny błąd architektoniczny prowadzący do naruszeń 3.3.7.
• Udostępnienie pola wyboru „taki sam jak adres dostawy”, ale bez faktycznego uzupełniania pól adresu rozliczeniowego po jego zaznaczeniu, co zmusza użytkowników do ręcznego wpisywania danych adresowych, nawet po wskazaniu, że powinny być takie same.
• Wstępne uzupełnianie pól przy ładowaniu strony, a następnie czyszczenie ich przy błędzie walidacji, przez co użytkownik, który popełni błąd na późniejszym etapie, musi ponownie wprowadzić wszystkie wcześniej podane dane po powrocie do poprawki.
• Niebezpieczne przechowywanie danych sesji i decyzja o wyłączeniu tego mechanizmu zamiast naprawienia problemu bezpieczeństwa, co skutkuje zepsutym doświadczeniem wstępnego uzupełniania i technicznie stanowi naruszenie 3.3.7.
• Wykorzystywanie wyjątku dotyczącego potwierdzenia hasła jako uzasadnienia dla zmuszania użytkowników do ponownego wpisywania adresu e‑mail, podczas gdy potwierdzenie e‑maila nie jest istotną kontrolą bezpieczeństwa i nie kwalifikuje się w ramach wyjątku WCAG.
• Nieprzekazywanie przenoszonych wartości przez ukryte pola w formularzach renderowanych po stronie serwera, co powoduje utratę wstępnie uzupełnionych wartości, gdy użytkownik porusza się wstecz i naprzód między krokami, używając przycisków historii przeglądarki.
• Poleganie wyłącznie na autofill przeglądarki w celu spełnienia tego kryterium, bez wdrożenia mechanizmu wstępnego uzupełniania na poziomie aplikacji — użytkownicy, którzy wyłączają autofill ze względów prywatności, nie mają wtedy zgodnej ścieżki przejścia przez proces.
• Wstępne uzupełnianie pola, ale ustawianie go jako disabled zamiast readonly, co powoduje, że wartość nie jest wysyłana wraz z formularzem w większości przeglądarek, psując proces i potencjalnie wymuszając ponowne wprowadzanie danych.
• Brak testowania kompletnego przepływu end‑to‑end z użytkownikami korzystającymi z oprogramowania do wprowadzania głosowego, takiego jak Dragon NaturallySpeaking, gdzie zduplikowane pola mogą wymagać wielokrotnego powtarzania tej samej komendy dyktowania, co stanowi istotne obciążenie łatwe do przeoczenia w testach deweloperskich.
• Traktowanie tego kryterium jako dotyczącego wyłącznie pól adresowych, podczas gdy w równym stopniu odnosi się ono do wszelkich powtarzających się danych, w tym imion i nazwisk, numerów telefonów, numerów identyfikacyjnych, numerów polis, dat oraz innych informacji podawanych przez użytkownika, o które prosi się więcej niż raz w tym samym procesie.

Związek z Przepisami Dotyczącymi Dostępności w Turcji

Prezydencki Okólnik Turcji 2025/10, opublikowany w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., nakłada obowiązek zgodności z wymaganiami dostępności stron internetowych na szeroką grupę podmiotów publicznych i prywatnych działających w Turcji. WCAG 3.3.7 Redundant Entry to kryterium poziomu A w ramach WCAG 2.2, a zgodność na poziomie A jest obowiązkową podstawą wynikającą z tego okólnika. Oznacza to, że każdy objęty podmiot prowadzący stronę internetową, aplikację webową lub usługę cyfrową nie może wymagać od użytkowników ponownego wprowadzania informacji, które już podali w ramach tego samego procesu — bez wyjątku — pod rygorem niezgodności.

Okólnik ustanawia stopniowy harmonogram wdrożenia: instytucje publiczne muszą osiągnąć zgodność w ciągu jednego roku od publikacji okólnika, podczas gdy podmioty sektora prywatnego w objętych kategoriach mają na dostosowanie się dwa lata.

Zakres podmiotów objętych okólnikiem jest szeroki i obejmuje platformy e‑commerce i marketplace’y, wszystkie instytucje publiczne i agencje rządowe, banki i dostawców usług finansowych, szpitale i portale ochrony zdrowia (zarówno publiczne, jak i prywatne), firmy telekomunikacyjne z 200,000 lub większą liczbą abonentów, licencjonowane biura podróży, prywatne firmy transportowe oraz szkoły niepubliczne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE). Dla wszystkich tych podmiotów wieloetapowe procesy cyfrowe — przepływy checkout na stronach e‑commerce, rejestracja pacjentów na portalach szpitalnych, otwieranie kont na platformach bankowych, formularze rekrutacyjne na stronach szkół — muszą zostać poddane audytowi i poprawione w celu wyeliminowania wszelkich przypadków powtórnego wprowadzania danych.

W praktyce regulacja ta umieszcza zgodność z WCAG 3.3.7 w centrum zainteresowania zespołów zakupowych, produktowych i prawnych w całej cyfrowej gospodarce Turcji. Na przykład turecka platforma e‑commerce prowadząca wieloetapowy checkout, który prosi o adres dostawy na jednym ekranie, a o adres rozliczeniowy na kolejnym, nie oferując opcji wstępnego uzupełnienia lub skopiowania danych, pozostaje w bezpośredniej sprzeczności zarówno z WCAG 2.2 poziomu A, jak i z Prezydenckim Okólnikiem. Podobnie portal rezerwacji wizyt w szpitalu państwowym, który prosi pacjentów o ponowne wprowadzanie numeru identyfikacyjnego lub daty urodzenia na wielu ekranach, jest niezgodny. Organizacje objęte okólnikiem powinny priorytetowo potraktować kompleksowy audyt wszystkich wieloetapowych procesów jako część planu osiągnięcia zgodności, traktując eliminację powtórnego wprowadzania danych jako wymagane zadanie inżynieryjne, a nie opcjonalne ulepszenie.