WCAG 1.3.5 Określenie pożądanej wartości

Kryterium sukcesu 1.3.5 ułatwia korzystanie z formularzy osobom z niepełnosprawnościami poznawczymi, z zaburzeniami pamięci lub ruchowymi. Gdy pole mówi w kodzie, do czego służy — „to jest e-mail”, „to jest kod pocztowy” — przeglądarki mogą je wypełnić, a narzędzia wspomagające mogą wyświetlić znajome ikony lub etykiety. Kryterium dodano w WCAG 2.1; to poziom AA, więc należy do wymagań, na których opierają się norma EN 301 549 i Europejski akt o dostępności (punkt 9.1.3.5).

Czego wymaga kryterium

Cel każdego pola formularza zbierającego informacje o użytkowniku musi być możliwy do programowego określenia, gdy:

• pole służy jednemu z celów z listy WCAG Input Purposes for User Interface Components (sekcja 7 WCAG 2.1 i 2.2) — np. name, given-name, family-name, email, tel, street-address, address-line1, postal-code, country, organization, bday, cc-name, cc-number, cc-exp, username, new-password, current-password; oraz
• technologia to obsługuje. HTML to umożliwia za pomocą atrybutu autocomplete.

Dotyczy to tylko danych o użytkowniku. Pole na kod rabatowy, wyszukiwarka produktów czy dane innej osoby nie są objęte kryterium.

Typowe błędy w sklepie internetowym

• pola imienia i nazwiska, e-maila, telefonu i adresu w procesie zamówienia bez autocomplete;
• autocomplete="off" ustawione na całym formularzu zamówienia „dla bezpieczeństwa”;
• nieprawidłowe lub błędne wartości, np. autocomplete="zip" albo autocomplete="name" w polu e-mail;
• osobne adresy rozliczeniowy i dostawy bez tokenów billing i shipping, przez co przeglądarka wypełnia niewłaściwy;
• pola rejestracji i logowania bez username, new-password lub current-password.

Jak to sprawdzić

Automatycznie: nasz skaner oznacza wartości autocomplete, które są nieprawidłowe lub nieodpowiednie dla pola (reguła autocomplete valid). Nie rozpozna, czy pole bez autocomplete prosi o dane samego użytkownika, więc brakujące atrybuty wymagają kontroli ręcznej.

Ręcznie: należy spisać wszystkie formularze: rejestracji, logowania, konta, zamówienia, newslettera, kontaktowy. Przy każdym polu proszącym o dane osobowe użytkownika sprawdzić w kodzie wartość autocomplete i porównać ją z listą WCAG. Przetestować, czy autouzupełnianie przeglądarki wypełnia właściwe pola.

Jak to naprawić

• Dodać do każdego pola właściwy token, np. <input type="email" autocomplete="email">.
• Przy adresach używać tokenów sekcji: autocomplete="shipping postal-code" i autocomplete="billing postal-code".
• Usunąć autocomplete="off" z pól z danymi osobowymi.
• W Shopify, WooCommerce i na innych platformach sprawdzić, czy motyw lub wtyczki nie nadpisują formularzy zamówienia i konta; domyślne ustawienia platformy mogą już zawierać te atrybuty.

Powiązane kryteria

• 1.3.1 Informacje i relacje — etykiety połączone z polami.
• Lista kontrolna WCAG 2.2 — w tym 3.3.7 Zbędne ponowne wprowadzanie danych i 3.3.8 Dostępne uwierzytelnianie (minimum).
• Reguły sprawdzane przez nasz skaner — wszystkie reguły automatyczne.

Najczęstsze pytania

Które pola potrzebują atrybutu autocomplete?

Pola, które zbierają informacje o samym użytkowniku i odpowiadają jednemu z celów wymienionych w WCAG, np. name, email, tel, street-address, postal-code, country, cc-number lub new-password.

Czy 1.3.5 dotyczy adresu odbiorcy prezentu?

Kryterium obejmuje informacje o użytkowniku. Pola dotyczące innej osoby nie muszą udostępniać swojego celu, choć dodanie tokenów shipping nadal może pomóc.

Czy autocomplete="off" jest błędem?

W polu, które zbiera wymienione w WCAG dane samego użytkownika — tak: cel musi być możliwy do programowego określenia, a wartość „off” go nie określa.

Co znajduje automatyczne sprawdzenie?

Nasz skaner oznacza wartości autocomplete, które są nieprawidłowe lub nie pasują do pola. Nie wie, czy pole bez autocomplete prosi o dane samego użytkownika, więc brakujące atrybuty wymagają ręcznego sprawdzenia.