Formularz to element, który umożliwia użytkownikowi wprowadzanie danych w polu lub grupie pól. Formularze mogą być proste, np. zawierać tylko jedno pole, lub złożone, np. składać się z wielu kroków i elementów formularza z wieloma polami na stronie, walidacją danych wejściowych, a czasem też z zabezpieczenia CAPTCHA.
Formularze są uważane za jedne z najtrudniejszych elementów do prawidłowego zaprojektowania pod kątem dostępności, ponieważ wymagają znajomości wszystkich elementów, które już omówiliśmy, a także dodatkowych reguł dotyczących tylko formularzy. Jeśli poświęcisz trochę czasu na zrozumienie tych reguł, możesz utworzyć dostępny formularz, który będzie odpowiedni dla Ciebie i Twoich użytkowników.
Moduł Formularze jest ostatnim modułem w tym kursie, który dotyczy konkretnego komponentu. Skupimy się w nim na wytycznych dotyczących formularzy, ale wszystkie inne wytyczne, które poznałeś(-aś) w poprzednich modułach, takie jak struktura treści, fokus klawiaturyi kontrast kolorów, mają zastosowanie również do elementów formularza.
Pola
Podstawą formularzy są pola. Pola to małe interaktywne wzorce, takie jak pole tekstowe lub przycisk opcji, które umożliwiają użytkownikom wprowadzanie treści lub dokonywanie wyboru. Do wyboru jest wiele różnych pól formularza.
Domyślnie zalecamy używanie ustalonych wzorców HTML zamiast tworzenia niestandardowych elementów za pomocą ARIA, ponieważ niektóre funkcje, takie jak stany, właściwości i wartości pól, są wbudowane w elementy HTML. W przypadku pól niestandardowych musisz ręcznie dodać ARIA.
Niezalecane – niestandardowy kod HTML z ARIA
<div role="form" id="sundae-order-form">
<!-- form content -->
</div>
Zalecane – standardowy kod HTML
<form id="sundae-order-form">
<!-- form content -->
</form>
Oprócz wybrania najbardziej dostępnych wzorców pól formularza, w stosownych przypadkach należy też dodać atrybuty autouzupełniania HTML do pól. Dodanie atrybutów autouzupełniania umożliwia dokładniejsze określenie lub zidentyfikowanie celu dla agentów użytkownika i technologii wspomagających.
Atrybuty autouzupełniania umożliwiają użytkownikom personalizowanie prezentacji wizualnych, np. wyświetlanie ikony tortu urodzinowego w polu z przypisanym atrybutem autouzupełniania urodzin (bday). Ogólnie rzecz biorąc, atrybuty autouzupełniania ułatwiają i przyspieszają wypełnianie formularzy. Jest to szczególnie przydatne dla osób z zaburzeniami poznawczymi i trudnościami w czytaniu oraz dla osób korzystających z technologii wspomagających, takich jak czytniki ekranu.
<form id="sundae-order-form">
<p>Name: <input type="name" autocomplete="name"></p>
<p>Telephone: <input type="tel" autocomplete="tel"></p>
<p>Email address: <input type="email" autocomplete="email"></p>
</form>
Na koniec, pola formularza nie powinny powodować zmian kontekstowych, gdy uzyskują fokus lub gdy użytkownik wprowadza dane wejściowe, chyba że użytkownik został ostrzeżony o takim zachowaniu przed użyciem komponentu. Na przykład formularz nie powinien być automatycznie przesyłany, gdy pole uzyska fokus lub gdy użytkownik doda do niego treść.
Etykiety
Etykiety informują użytkownika o przeznaczeniu pola, o tym, czy pole jest wymagane, a także mogą zawierać informacje o wymaganiach dotyczących pola, np. o formacie danych wejściowych. Etykiety muszą być zawsze widoczne i dokładnie opisywać pole formularza.
Jedną z podstawowych zasad dotyczących dostępnych formularzy jest ustanowienie jasnego i dokładnego połączenia między polem a jego etykietą. Dotyczy to zarówno aspektów wizualnych, jak i programowych. Bez tego kontekstu użytkownik może nie wiedzieć, jak wypełnić pola w formularzu.
<form id="sundae-order-form">
<p><label>Name (required): <input type="name" autocomplete="name" required></label></p>
<p><label>Telephone (required): <input type="tel" autocomplete="tel" required></label></p>
<p><label>Email address: <input type="email" autocomplete="email"></label></p>
</form>
Dodatkowo powiązane pola formularza, takie jak adres pocztowy, muszą być zgrupowane programowo i wizualnie. Jedną z metod jest użycie wzorca fieldset i legend do grupowania podobnych elementów.
Teksty reklamy
Teksty reklamy są podobne do etykiet, ponieważ służą do przekazywania dodatkowych informacji o polu i wymaganiach. Opisy pól nie są wymagane pod kątem ułatwień dostępu, jeśli etykiety lub instrukcje formularza są wystarczająco opisowe.
Są jednak sytuacje, w których dodanie dodatkowych informacji jest przydatne, aby uniknąć błędów w formularzu, np. przekazanie informacji o minimalnej długości danych wejściowych w polu hasła lub poinformowanie użytkownika, jakiego formatu kalendarza ma użyć (np. MM-DD-RRRR).
Istnieje wiele różnych metod dodawania tekstów reklamy do formularzy. Jedną z najlepszych metod jest dodanie do elementu formularza atrybutu
aria-describedby
oraz elementu <label>. Czytnik ekranu odczyta zarówno opis, jak i etykietę.
Jeśli do elementu dodasz atrybut
aria-labelledby, wartość atrybutu zastąpi tekst w elemencie
<label>. Jak zawsze, pamiętaj, aby przetestować gotowy kod za pomocą wszystkich technologii wspomagających, które chcesz obsługiwać.
Błędy
Podczas tworzenia dostępnych formularzy możesz zrobić wiele, aby zapobiec popełnianiu przez użytkowników błędów w formularzu. Wcześniej w tym module omówiliśmy wyraźne oznaczanie pól, tworzenie etykiet identyfikujących i dodawanie szczegółowych opisów, gdy tylko jest to możliwe. Ale bez względu na to, jak przejrzysty wydaje Ci się formularz, w końcu użytkownik popełni błąd.
Gdy użytkownik napotka błąd w formularzu, pierwszym krokiem jest poinformowanie go o tym. Należy wyraźnie wskazać pole, w którym wystąpił błąd, a sam błąd należy opisać użytkownikowi w tekście.
Istnieją różne metody wyświetlania komunikatów o błędach, np.:
- okno modalne, wstawione w wierszu w pobliżu miejsca, w którym wystąpił błąd;
- zbiór błędów zgrupowanych w jednym większym komunikacie u góry strony.
Podczas ogłaszania błędów zwróć uwagę na fokus klawiatury i opcje aktywnego regionu ARIA.
Jeśli to możliwe, zaproponuj użytkownikowi szczegółową sugestię dotyczącą sposobu naprawienia błędu. Do powiadamiania użytkowników o błędach służą 2 atrybuty.
- Możesz użyć atrybutu HTML required. Przeglądarka wyświetli ogólny komunikat o błędzie na podstawie parametrów walidacji pola.
- Możesz też użyć atrybutu aria-required, aby udostępnić technologiom wspomagającym niestandardowy komunikat o błędzie. Komunikat otrzymają tylko technologie wspomagające, chyba że dodasz dodatkowy kod, aby komunikat był widoczny dla wszystkich użytkowników.
Gdy użytkownik uzna, że wszystkie błędy zostały rozwiązane, pozwól mu ponownie przesłać formularz i przekazać opinię o wynikach przesłania. Komunikat o błędzie informuje użytkownika, że musi wprowadzić więcej zmian, a komunikat o powodzeniu potwierdza, że rozwiązał wszystkie błędy i przesłał formularz.
Dodatkowe kryteria sukcesu
W WCAG 2.2 wprowadzono te kryteria sukcesu, które koncentrują się na bardziej dostępnych formularzach: