WCAG 1.3.5: Identyfikacja celu pola wejściowego

Co Oznacza Ta Zasada

WCAG 1.3.5 — Identify Input Purpose (Identyfikacja celu danych wejściowych) to kryterium poziomu AA wprowadzone w WCAG 2.1 i przeniesione do WCAG 2.2. Wymaga ono, aby każdy element <input>, <select> lub <textarea>, który zbiera informacje o użytkowniku, miał swój cel zakomunikowany programowo, tak aby przeglądarki i technologie asystujące mogły ten cel rozpoznać i automatycznie na niego reagować.

Mechanizmem spełnienia tego kryterium jest atrybut autocomplete, połączony z właściwą wartością tokena z oficjalnej listy zdefiniowanej w specyfikacji HTML. Gdy pole zbiera imię i nazwisko użytkownika, adres e‑mail, numer telefonu, adres pocztowy, numer karty kredytowej lub podobne dane osobowe, atrybut autocomplete musi mieć wartość, która dokładnie opisuje cel tego pola — na przykład autocomplete="given-name" dla pola imienia lub autocomplete="email" dla pola adresu e‑mail.

Kryterium dotyczy konkretnie pól, które zbierają informacje o samym użytkowniku. Nie dotyczy pól, w których użytkownik wprowadza dane o kimś innym (na przykład formularz rezerwacji podróży, który prosi o imię i nazwisko pasażera, gdy użytkownik rezerwuje w imieniu innej osoby), ani pól, w których autouzupełnianie stwarzałoby ryzyko bezpieczeństwa — takich jak jednorazowe hasła lub zadania w stylu CAPTCHA, które mogą w uzasadniony sposób używać autocomplete="off" lub autocomplete="one-time-code".

Spełnienie kryterium wymaga, aby: (1) każde pole wejściowe w zakresie kryterium miało atrybut autocomplete; oraz (2) wartość tego atrybutu była prawidłowym, rozpoznawanym tokenem ze specyfikacji HTML autofill — nie dowolnym ciągiem znaków, nie pustą wartością tam, gdzie wymagana jest znacząca, i nie błędnie zapisanym tokenem. Niespełnienie kryterium ma miejsce, gdy pole w zakresie nie ma atrybutu autocomplete, ma autocomplete="off" bez uzasadnienia lub ma nieprawidłowy token, taki jak autocomplete="firstname" (prawidłowy token to given-name) czy autocomplete="phone" (prawidłowy token to tel).

Pełna lista prawidłowych tokenów autocomplete jest utrzymywana w WHATWG HTML Living Standard i obejmuje wartości dla imion i nazwisk (given-name, family-name, additional-name), adresów (street-address, address-line1, postal-code, country-name), danych kontaktowych (email, tel, tel-national), danych uwierzytelniających (username, current-password, new-password), danych płatniczych (cc-name, cc-number, cc-exp, cc-csc) i innych. Tokeny mogą być także poprzedzone identyfikatorami sekcji (np. section-billing) oraz słowami kluczowymi shipping lub billing, aby obsłużyć wiele grup adresowych na jednej stronie.

Dlaczego To Ma Znaczenie

To kryterium istnieje przede wszystkim z myślą o użytkownikach z niepełnosprawnościami poznawczymi, w tym osobach z dysleksją, zaburzeniami pamięci, zaburzeniami uwagi oraz trudnościami w uczeniu się. Dla tych użytkowników poprawne wypełnienie złożonego formularza zakupowego — z oddzielnymi polami na imię, nazwisko, ulicę, miasto, kod pocztowy, telefon i dane płatnicze — może stanowić istotne obciążenie poznawcze. Gdy tokeny autocomplete są poprawne, przeglądarki mogą jednym działaniem wstępnie wypełnić pola na podstawie zapisanego profilu użytkownika, znacząco zmniejszając tarcie i ryzyko błędów.

Użytkownicy z niepełnosprawnościami ruchowymi — w tym osoby z ograniczoną sprawnością rąk, korzystające z przełączników, oprogramowania śledzącego ruch gałek ocznych lub urządzeń typu sip-and-puff — odnoszą równie duże korzyści. Pisanie jest dla nich powolne, wymagające wysiłku, a czasem bolesne. Autouzupełnianie, które działa niezawodnie, może zamienić dziesięciominutową udrękę w zadanie wykonywane niemal natychmiast. Według Światowej Organizacji Zdrowia około 1,3 miliarda osób na świecie żyje z jakąś formą znaczącej niepełnosprawności, a zaburzenia motoryczne wpływające na precyzyjną kontrolę dłoni należą do najczęstszych.

Poza autouzupełnianiem, poprawne tokeny autocomplete pozwalają przeglądarkom i technologiom asystującym prezentować niestandardowe ikony, etykiety lub rozszerzone interfejsy wejściowe — na przykład automatycznie wyświetlać klawiaturę telefoniczną dla pola tel na urządzeniu mobilnym lub pokazywać grafikę karty kredytowej dla pola cc-number. Menedżery haseł, które są kluczowymi narzędziami dostępności dla użytkowników z zaburzeniami pamięci, również polegają na tych tokenach, aby prawidłowo identyfikować i wypełniać pola z danymi uwierzytelniającymi.

Rozważmy scenariusz z życia wzięty: użytkownik z porażeniem mózgowym wypełnia wniosek o świadczenia rządowe. Formularz zawiera dwanaście pól obejmujących imię i nazwisko, adres, numer identyfikacji narodowej i dane kontaktowe. Bez poprawnych wartości autocomplete każde pole musi zostać wpisane ręcznie. Jeden błędnie zapisany token — na przykład autocomplete="surname" zamiast autocomplete="family-name" — wystarczy, aby przeglądarka nie rozpoznała pola, zmuszając użytkownika do wpisania nazwiska znak po znaku. Przy poprawnych tokenach cały formularz może zostać automatycznie wypełniony w kilka sekund, zmniejszając zarówno wysiłek, jak i liczbę błędów.

Istnieją także korzyści w zakresie użyteczności i współczynnika konwersji dla organizacji: badania konsekwentnie pokazują, że formularze zgodne z autouzupełnianiem mają niższe wskaźniki porzucania i wyższe wskaźniki ukończenia, co oznacza, że naprawa tokenów autocomplete jest nie tylko poprawą dostępności, ale także bezpośrednią poprawą biznesową.

Powiązane Reguły Axe-core

• autocomplete-valid — To podstawowa reguła axe-core dla WCAG 1.3.5. Sprawdza każdy element <input>, <select> i <textarea>, który ma atrybut autocomplete, i weryfikuje, czy wartość tego atrybutu jest rozpoznanym, prawidłowym tokenem ze specyfikacji HTML autofill. Reguła oznacza elementy, w których token jest błędnie zapisany (np. given name z odstępem zamiast łącznika), w których użyto niestandardowej, zastrzeżonej wartości (np. autocomplete="first-name") lub w których kolejność tokenów w wartości wielotokenowej jest nieprawidłowa (np. umieszczenie nazwy pola przed wymaganym prefiksem sekcji). Reguła nie oznacza pól, którym całkowicie brakuje atrybutu autocomplete — taka sytuacja wymaga ręcznego przeglądu — ponieważ axe-core nie może programowo ustalić, czy dane pole jest w zakresie kryterium (tzn. czy zbiera informacje o użytkowniku).
• Dlaczego wymagane jest także testowanie ręczne — Narzędzia automatyczne, takie jak axe-core, mogą jedynie sprawdzić, czy istniejąca wartość autocomplete jest składniowo poprawna; nie są w stanie ustalić, czy wybrany token dokładnie opisuje cel pola. Na przykład pole telefonu do rozliczeń z autocomplete="email" przeszłoby automatyczną regułę (ponieważ email jest prawidłowym tokenem), ale nie spełniałoby kryterium, ponieważ token nie odpowiada rzeczywistemu celowi pola. Podobnie narzędzia automatyczne nie mogą zidentyfikować pól, którym brakuje atrybutu autocomplete, ale powinny go mieć, ponieważ ustalenie, czy pole zbiera dane osobowe użytkownika, wymaga ludzkiej oceny kontekstu. Ręczny przegląd każdego pola formularza, które zbiera dane specyficzne dla użytkownika, jest zatem niezbędny dla pełnej zgodności z 1.3.5.

Jak Testować

1. Uruchom automatyczne skanowanie za pomocą axe DevTools lub Lighthouse. Otwórz stronę zawierającą formularz w Chrome lub Firefox. W axe DevTools kliknij „Analyze” i przefiltruj wyniki według identyfikatora reguły autocomplete-valid. W Lighthouse uruchom audyt dostępności i wyszukaj naruszenia odnoszące się do autocomplete. Zanotuj każdy oznaczony element i zapisz zgłoszone nieprawidłowe wartości tokenów. Napraw każdy oznaczony element i ponownie wykonaj skan, aby potwierdzić poprawkę.
2. Ręcznie zidentyfikuj wszystkie pola wejściowe w zakresie. Przejrzyj formularz i wypisz każde pole, które zbiera informacje o aktualnym użytkowniku — pola imienia i nazwiska, adresu, e‑mail, telefonu, danych płatniczych, danych uwierzytelniających. Dla każdego pola sprawdź, czy obecny jest atrybut autocomplete i czy jego token odpowiada rzeczywistemu celowi pola zgodnie z listą tokenów HTML autofill. Pola zbierające informacje o innych osobach są poza zakresem i można je pominąć.
3. Przetestuj zachowanie autouzupełniania w przeglądarce. W Chrome lub Firefox upewnij się, że przeglądarka ma zapisany profil (Ustawienia > Autouzupełnianie). Przejdź do strony formularza i kliknij pierwsze pole z danymi osobowymi. Potwierdź, że przeglądarka prezentuje propozycję autouzupełniania i że jej wybranie wypełnia poprawne pola właściwymi wartościami. Powtórz dla pól adresowych, płatniczych i pól z danymi uwierzytelniającymi. Jeśli autouzupełnianie nie proponuje wartości lub wypełnia niewłaściwe pola, tokeny autocomplete są prawdopodobnie niepoprawne.
4. Przetestuj w kombinacji czytnika ekranu i przeglądarki. Z NVDA i Firefox przechodź do kolejnych pól formularza za pomocą klawisza Tab. NVDA powinien ogłaszać etykietę pola i jego cel; niektóre kombinacje czytnika ekranu i przeglądarki ogłaszają także cel autocomplete. Z VoiceOver w macOS (Safari) przechodź po polach klawiszem Tab i nasłuchuj, czy VoiceOver ogłasza dostępność autouzupełniania. Z JAWS i Chrome w podobny sposób przechodź po polach i potwierdź, że JAWS ogłasza oczekiwany kontekst pola. Choć czytniki ekranu nie zawsze wprost ogłaszają tokeny autocomplete, potwierdzenie, że autouzupełnianie działa poprawnie w połączeniu z nawigacją klawiaturą, potwierdza, że cel programowy jest ujawniony.
5. Sprawdź atrybuty autocomplete w narzędziach deweloperskich przeglądarki. Kliknij prawym przyciskiem każde pole formularza i wybierz „Inspect”. W panelu Elements potwierdź, że atrybut autocomplete jest obecny i że jego wartość dokładnie odpowiada prawidłowemu tokenowi. Zwróć szczególną uwagę na wartości wielotokenowe — na przykład autocomplete="shipping street-address" — i potwierdź, że kolejność tokenów jest zgodna ze specyfikacją (nazwa sekcji, następnie „shipping” lub „billing”, a potem nazwa pola).

Jak Naprawić

Pola imienia i nazwiska — Niepoprawne

<!-- Invalid: uses non-standard token 'firstname' instead of 'given-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='firstname'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='surname'>

Pola imienia i nazwiska — Poprawne

<!-- Valid: uses the exact WHATWG-specified tokens 'given-name' and 'family-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='given-name'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='family-name'>

Formularz adresowy z sekcjami rozliczeniową i wysyłkową — Niepoprawne

<!-- Invalid: missing autocomplete attributes entirely on address fields -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' placeholder='Street Address'>
  <input type='text' name='bill_city' placeholder='City'>
  <input type='text' name='bill_postal' placeholder='Postal Code'>
</fieldset>

Formularz adresowy z sekcjami rozliczeniową i wysyłkową — Poprawne

<!-- Valid: autocomplete tokens include 'billing' prefix and correct field names -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' autocomplete='billing street-address' placeholder='Street Address'>
  <input type='text' name='bill_city' autocomplete='billing address-level2' placeholder='City'>
  <input type='text' name='bill_postal' autocomplete='billing postal-code' placeholder='Postal Code'>
</fieldset>

Pole telefonu — Niepoprawne

<!-- Invalid: uses 'phone' which is not a recognized autocomplete token -->
<label for='tel'>Phone Number</label>
<input type='text' id='tel' name='telephone' autocomplete='phone'>

Pole telefonu — Poprawne

<!-- Valid: 'tel' is the correct autocomplete token for a full phone number -->
<label for='tel'>Phone Number</label>
<input type='tel' id='tel' name='telephone' autocomplete='tel'>

Dane logowania — Niepoprawne

<!-- Invalid: autocomplete='off' prevents password managers and autofill from working -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='off'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='off'>

Dane logowania — Poprawne

<!-- Valid: 'username' and 'current-password' allow password managers to function correctly -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='username'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='current-password'>

Typowe Błędy

• Używanie autocomplete="firstname" lub autocomplete="first-name" zamiast poprawnego tokena given-name". Te niestandardowe wartości nie są rozpoznawane przez przeglądarki ani technologie asystujące, mimo że wydają się logiczne. Zawsze używaj dokładnych tokenów ze specyfikacji HTML autofill.
• Używanie autocomplete="phone" zamiast autocomplete="tel". Słowo „phone” nie jest prawidłowym tokenem. Specyfikacja używa tel dla pełnego numeru telefonu oraz tel-national, tel-area-code, tel-local dla części składowych numeru telefonu.
• Ustawianie autocomplete="off" na polach z danymi uwierzytelniającymi jako błędnie rozumiany środek bezpieczeństwa. Nowoczesne przeglądarki i specyfikacja WCAG uznają, że blokowanie autouzupełniania w formularzach logowania tworzy realne bariery dla użytkowników z niepełnosprawnościami i nie poprawia w istotny sposób bezpieczeństwa. Zamiast tego używaj autocomplete="username" i autocomplete="current-password".
• Całkowite pomijanie atrybutu autocomplete w polach z danymi osobowymi, przy założeniu, że przeglądarka wywnioskuje cel z nazwy pola lub etykiety. Przeglądarki używają heurystyk do zgadywania celu pola, ale są one zawodne i niespójne między przeglądarkami. Jawne tokeny są wymagane dla gwarantowanego, dostępnego doświadczenia.
• Używanie autocomplete="address" zamiast konkretnych podtokenów adresu. W specyfikacji nie ma tokena address. Należy używać osobno street-address, address-line1, address-line2, address-level1 (stan/województwo), address-level2 (miasto) oraz postal-code.
• Umieszczanie słów kluczowych shipping lub billing w niewłaściwej kolejności w wartościach wielotokenowych. Prawidłowa kolejność to: opcjonalny prefiks sekcji (np. section-billing), następnie opcjonalne słowo kluczowe shipping/billing, a potem token nazwy pola. Zapis autocomplete="street-address billing" jest nieprawidłowy; poprawna forma to autocomplete="billing street-address".
• Stosowanie autocomplete tylko do pól widocznych i ignorowanie pól ukrytych lub dynamicznie ujawnianych. Pola, które początkowo są ukryte, ale ujawniane w wyniku interakcji użytkownika (takie jak dodatkowe linie adresu lub pola opcjonalne), również muszą mieć poprawne tokeny autocomplete, gdy stają się aktywne.
• Używanie JavaScriptu do dynamicznego usuwania lub nadpisywania atrybutu autocomplete po załadowaniu strony. Niektóre biblioteki formularzy lub frameworki UI resetują atrybuty pól wejściowych podczas montowania komponentów lub ponownego renderowania, nieumyślnie usuwając tokeny autocomplete. Zawsze weryfikuj, że atrybut utrzymuje się w żywym DOM po wykonaniu całego JavaScriptu.
• Zakładanie, że type="email" lub type="tel" na polu wejściowym wystarcza do zakomunikowania celu bez autocomplete. Choć type dostarcza pewnych informacji, atrybut autocomplete jest osobnym, jawnym sygnałem wymaganym przez WCAG 1.3.5 i używanym w inny sposób przez przeglądarki i technologie asystujące.
• Używanie tego samego tokena autocomplete w dwóch różnych polach, które zbierają różne dane. Na przykład oznaczenie zarówno pola służbowego adresu e‑mail, jak i pola prywatnego adresu e‑mail tokenem autocomplete="email" wprowadza zamieszanie w przeglądarkach i może skutkować nieprawidłowym autouzupełnianiem. Używaj prefiksów sekcji (np. section-work email vs. section-personal email), aby rozróżnić pola.

Związek z Tureckimi Regulacjami Dotyczącymi Dostępności

Turecka Prezydencka Okrężnica 2025/10, opublikowana w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia wiążące wymagania dotyczące dostępności dla szerokiego zakresu organizacji działających w Turcji. Okrężnica nakazuje zgodność z WCAG 2.2 na poziomie AA jako podstawowym standardem dla usług cyfrowych, co bezpośrednio obejmuje WCAG 1.3.5 — Identify Input Purpose.

Typy podmiotów objętych Okrężnicą są bardzo szerokie. Instytucje publiczne i agencje rządowe są zobowiązane do spełnienia tych standardów dla wszystkich usług cyfrowych skierowanych do obywateli. Do objętych organizacji sektora prywatnego należą platformy e‑commerce, banki i dostawcy usług finansowych, szpitale i świadczeniodawcy opieki zdrowotnej, operatorzy telekomunikacyjni z 200 000 lub większą liczbą abonentów, licencjonowane biura podróży, prywatne firmy przewozu pasażerskiego oraz prywatne instytucje edukacyjne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE). W praktyce oznacza to, że niemal każdy główny cyfrowy produkt konsumencki w Turcji — od aplikacji bankowych po internetowe kasy sklepów detalicznych i portale rezerwacji wizyt medycznych — musi mieć poprawnie zaimplementowane tokeny autocomplete we wszystkich polach wprowadzania danych osobowych.

W odniesieniu konkretnie do WCAG 1.3.5 oznacza to, że każdy turecki formularz kasy e‑commerce, formularz otwarcia rachunku bankowego, formularz rejestracji pacjenta w szpitalu czy formularz subskrypcji usług telekomunikacyjnych, który zbiera informacje o użytkowniku, takie jak imię i nazwisko, adres, numer telefonu czy dane płatnicze, musi zawierać prawidłowe wartości atrybutu autocomplete we wszystkich odpowiednich polach. Brak ich stanowi niezgodność na poziomie AA i może uniemożliwić organizacji uzyskanie lub utrzymanie Logotypu Dostępności (Erişilebilirlik Logosu), oficjalnego znaku wydawanego przez Ministerstwo Rodziny i Usług Społecznych, potwierdzającego, że usługi cyfrowe organizacji spełniają standardy dostępności.

Logotyp Dostępności ma znaczenie wizerunkowe i regulacyjne, a organizacje działające na konkurencyjnych rynkach konsumenckich — takich jak e‑commerce i bankowość — mają silne motywacje, aby go uzyskać i utrzymać. Ponieważ WCAG 1.3.5 jest proste do wdrożenia (dodanie lub poprawienie wartości atrybutu autocomplete nie wymaga zmian architektury), a jednocześnie przynosi znaczące korzyści użytkownikom z niepełnosprawnościami poznawczymi i ruchowymi, stanowi jedno z najbardziej wartościowych, a zarazem najmniej pracochłonnych usprawnień dostępności, jakie organizacja może wprowadzić w dążeniu do pełnej zgodności z poziomem AA na mocy Okrężnicy 2025/10.

Organizacje powinny przeprowadzić audyt wszystkich formularzy we wszystkich swoich zasobach cyfrowych — w tym interfejsów mobilnych i układów responsywnych — oraz ustanowić politykę deweloperską, która wymaga poprawnych tokenów autocomplete jako standardowego elementu każdej implementacji formularza. Powinno to być egzekwowane poprzez automatyczne testy w potokach CI/CD z użyciem narzędzi takich jak axe-core, tak aby regresje były wychwytywane, zanim trafią na produkcję.