Formularze

Formularz to miejsce, w którym produkt prosi ludzi o wysiłek. Każda z poniższych zasad istnieje po to, by ten wysiłek zmniejszyć: mniej decyzji, czytelniejsze błędy, żadnej utraconej pracy.

Układ#

• Jedna kolumna. Formularze wielokolumnowe zaburzają kolejność czytania i ukrywają pola. Wyjątkiem są krótkie, powiązane pary — imię i nazwisko, data ważności i kod CVC.
• Etykiety nad polami. Etykiety umieszczone nad polem najszybciej się przegląda, a dłuższe tłumaczenia i powiększenie ich nie psują. Jako etykiety używaj FieldLabel, nigdy placeholdera.
• Grupuj za pomocą FieldSet. Powiązane pola mają wspólny FieldLegend; odstęp między grupami jest większy niż między polami wewnątrz grupy.
• Dopasuj szerokość pola do odpowiedzi. Pole na kod pocztowy nie powinno być tak szerokie jak pole na adres.
• Poziome wiersze w ustawieniach. Na stronach ustawień etykieta i opis stoją po lewej, a kontrolka po prawej; Field orientation="responsive" sprawia, że na wąskich ekranach elementy układają się jeden pod drugim.

Pola wymagane i opcjonalne#

Oznaczaj mniejszość. Większość formularzy powinna prosić tylko o to, co niezbędne — wtedy nieliczne pola opcjonalne opisz dopiskiem „(opcjonalnie)”, a wymaganych nie oznaczaj wcale. Gdy większość pól jest opcjonalna, oznacz za to pola wymagane. Nigdy nie polegaj na samej gwiazdce: wielu osobom i czytnikom ekranu nic ona nie mówi.

Walidacja#

Kiedy walidować

1. Przy wysyłaniu sprawdź wszystko i przenieś fokus do podsumowania błędów na górze formularza.
2. Po pierwszym wysłaniu sprawdzaj pole ponownie, gdy ktoś je opuszcza (blur), żeby błędy znikały, gdy tylko zostaną poprawione.
3. Nigdy przy każdym naciśnięciu klawisza przed pierwszym wysłaniem — komunikat, że adres e-mail jest nieprawidłowy, już po wpisaniu jednej litery jest wręcz wrogi.

Jak pokazywać błędy

• Umieść komunikat bezpośrednio pod polem za pomocą FieldError, który wyświetla ikonę i tekst — nigdy sam kolor.
• Oznacz kontrolkę atrybutem aria-invalid, a pole — data-invalid.
• Napisz, co jest nie tak i jak to naprawić: Wpisz adres e-mail, np. ada@acme.co, a nie Nieprawidłowe dane.
• W formularzach dłuższych niż jeden ekran dodaj podsumowanie w Alert, które wymienia problemy i otrzymuje fokus.

<Field data-invalid>
  <FieldLabel htmlFor="email">Work email</FieldLabel>
  <Input id="email" aria-invalid />
  <FieldError>Enter an email address like ada@acme.co.</FieldError>
</Field>

Wysyłanie#

• Nie wyłączaj przycisku wysyłania. Wyłączony przycisk nie wyjaśni, czego brakuje; próba wysłania i pokazanie błędów — owszem.
• Pokazuj postęp na przycisku za pomocą loading. Przycisk zachowuje szerokość i fokus, a przy tym blokuje podwójne wysłanie.
• Potwierdzaj powodzenie powiadomieniem, jeśli ktoś zostaje na stronie, albo od razu przejdź do wyniku.
• Nigdy nie czyść formularza po błędzie. Błędy serwera pokazuj przy polach albo w podsumowaniu, a wszystkie wpisane wartości zachowaj.

Lista kontrolna dostępności#

• Każda kontrolka ma etykietę dostępną programowo (htmlFor + id albo aria-label w kontrolkach z samą ikoną).
• Tekst pomocniczy jest powiązany przez aria-describedby; błędy są odczytywane przez czytniki ekranu (FieldError używa role="alert").
• Pola z danymi osobowymi mają ustawione atrybuty autocomplete (name, email, new-password), żeby przeglądarki i menedżery haseł mogły pomóc w ich wypełnieniu.
• Formularz da się w pełni obsłużyć klawiaturą — w logicznej kolejności i z widocznym fokusem.