Poziom
A
Od wersji
WCAG 2.2
/ Kryterium WCAG

3.3.7 Nadmiarowe wprowadzanie danych

Informacji, które człowiek już wpisał albo otrzymał w tym samym procesie, nie wolno kazać mu wpisywać ponownie: mają być uzupełnione automatycznie albo dostępne do wybrania, z kilkoma wyjątkami.

/ Czego wymaga

Dwukrotne wpisywanie tego samego adresu w jednym zamówieniu albo ponowne podawanie adresu e-mail w czwartym kroku, choć padł już w pierwszym, kosztuje czas każdego. Dla osób z niepełnosprawnością poznawczą, zaburzeniami pamięci lub ograniczoną sprawnością ruchową może oznaczać koniec zadania. Kryterium mówi, że informacje wcześniej wpisane przez użytkownika albo mu przekazane, które w tym samym procesie są wymagane ponownie, muszą być albo uzupełnione automatycznie, albo dostępne do wybrania. Proces to seria czynności użytkownika, z których każda jest potrzebna do wykonania zadania, i może przebiegać przez różne domeny, więc krok płatności u zewnętrznego operatora w ramach zamówienia mieści się w zakresie.

W3C nie narzuca sposobu: dostępne do wybrania może być pole wyboru „Adres rozliczeniowy taki sam jak adres dostawy” albo lista wcześniejszych wpisów, i musi to być na tej samej stronie. Autouzupełnianie przeglądarki nie jest uznawane za wystarczające, bo to serwis ma udostępnić wcześniejszy wpis. Obowiązują trzy wyjątki: ponowne wpisanie jest istotne, jak w grze pamięciowej; informacja jest potrzebna dla bezpieczeństwa treści, jak potwierdzenie nowego, niewyświetlanego hasła; albo wcześniej wpisana informacja przestała być aktualna. Niczego nie trzeba przechowywać między sesjami.

To kryterium jest nowe w WCAG 2.2 i nie należy do WCAG 2.0 ani 2.1.

/ Jak strony go nie spełniają

  • Kasa po adresie dostawy pyta o adres rozliczeniowy i nie daje możliwości jego skopiowania.
  • Trzeci krok wniosku ponownie pyta o adres e-mail wpisany w kroku pierwszym.
  • Po błędzie płatności formularz ładuje się pusty i dane dostawy, które już podano, trzeba wpisać jeszcze raz.
  • Wieloetapowa wycena ubezpieczenia pyta o datę urodzenia na pierwszym ekranie i ponownie, w pustym polu, na ekranie podsumowania.
  • Rezerwacja przekazuje użytkownika operatorowi płatności w innej domenie, który znowu pyta o imię i e-mail, a nic nie zostaje przekazane.

/ Jak sprawdzić samodzielnie

  1. Przejdź każdy wieloetapowy proces w serwisie, taki jak zamówienie, rejestracja, wniosek, rezerwacja albo zgłoszenie do wsparcia, i zanotuj każde wypełniane pole.
  2. W każdym kroku sprawdź, czy serwis pyta o coś, co już wpisano, albo o coś, co sam już podał, jak numer zamówienia.
  3. Tam, gdzie pyta ponownie, sprawdź, czy wartość jest już wypełniona albo da się ją wybrać na tej samej stronie, na przykład polem wyboru „taki sam jak adres dostawy” albo listą wcześniejszych wpisów.
  4. Wyłącz autouzupełnianie w przeglądarce albo użyj okna prywatnego, żeby przeglądarka nie zamaskowała brakującego rozwiązania.
  5. Przy każdym pozostałym powtórzeniu oceń, czy obowiązuje wyjątek: ponowne wpisanie jest istotne, potrzebne dla bezpieczeństwa albo wcześniejsza wartość jest już nieaktualna.

/ Jak to naprawić

  • Dodaj pole wyboru „Adres rozliczeniowy taki sam jak adres dostawy”, które po zaznaczeniu kopiuje wartości albo pomija drugi blok.
  • Przechowuj wpisane wartości w stanie formularza wieloetapowego i wstawiaj je jako wartości pól, gdy użytkownik wraca do kroku.
  • Po błędzie walidacji po stronie serwera odsyłaj formularz z wypełnionymi wszystkimi przyjętymi wartościami i czyść tylko pola, które trzeba wyczyścić ze względów bezpieczeństwa.
  • Przekazuj znane dane do następnego kroku albo operatorowi płatności jako wstępnie wypełnione pola jego strony, jeśli operator to obsługuje.
  • Tam, gdzie wartości nie da się wstawić, zaproponuj ją do wyboru: listę adresów użytych wcześniej w procesie albo przycisk wstawiający poprzednią wartość.

/ Co sprawdza nasz skaner

Nasz skan nie ma automatycznego testu nadmiarowego wprowadzania danych. Czyta stronę w chwili załadowania i nigdy nie wypełnia ani nie przechodzi procesu wieloetapowego, więc nie może wiedzieć, o co pytano wcześniej. Reguła autocomplete-missing, przypisana do kryterium 1.3.5, zauważa pola danych osobowych bez atrybutu autocomplete, ale autouzupełnianie przeglądarki i tak nie spełnia tego kryterium. Człowiek przechodzi formularze krok po kroku w audycie ręcznym.

/ Kto je łamie, według naszych pomiarów

Cotygodniowy indeks nie ma danych dla tego kryterium, bo żaden test uruchamiany przez skan witryny go nie sprawdza. Ocenia je człowiek i do tego służy audyt ręczny.

Jedna strona na podmiot, mierzona automatycznie w tygodniowym cyklu. Jeśli podmiot coś naprawił od ostatniego pomiaru, zmiana będzie widoczna przy następnym, a każdy podmiot może odpowiedzieć na swojej stronie.

/ Pytania o to kryterium

Czy autouzupełnianie przeglądarki spełnia kryterium nadmiarowego wprowadzania danych?

Nie. W3C pisze, że funkcja autouzupełniania przeglądarek nie jest uznawana za wystarczającą, bo to serwis ma udostępnić wcześniejszy wpis. Atrybuty autocomplete nadal pomagają i służą kryterium 1.3.5 Określenie pożądanej wartości, ale formularz sam musi wstawić wartość albo zaproponować ją do wyboru.

Czy dwukrotne pytanie o hasło narusza 3.3.7?

Nie. Bezpieczeństwo to jeden z trzech wyjątków. Gdy użytkownik tworzy hasło, które nie jest wyświetlane, W3C pozwala poprosić o wpisanie go drugi raz w celu potwierdzenia. Pozostałe wyjątki to ponowne wpisanie, które jest istotne, jak w grze pamięciowej, oraz wcześniej podana informacja, która przestała być aktualna.

Jaki poziom ma 3.3.7 i czy obowiązuje między wizytami?

Poziom A, nowość w WCAG 2.2. Kryterium obowiązuje w obrębie jednego procesu i nie dodaje wymogu przechowywania informacji między sesjami. Osobę, która wraca po zamknięciu sesji albo po opuszczeniu strony, można zapytać o te same dane ponownie.