Formularze

Formularz to element, który umożliwia użytkownikowi wprowadzenie danych do pola lub grupy pól. Formularz może być tak prosty jak pojedyncze pole lub tak skomplikowany jak element formularza wieloetapowego z wieloma polami na stronie, walidacją danych i czasem testem CAPTCHA.

Formularze są uważane za jeden z najtrudniejszych elementów do prawidłowego stworzenia z perspektywy ułatwień dostępu, ponieważ wymagają znajomości wszystkich elementów, które już omówiliśmy, a także dodatkowych reguł dotyczących tylko formularzy. Przy odrobinie zrozumienia i czasu możesz stworzyć formularz dostępny dla Ciebie i użytkowników.

Formularze to ostatni moduł dotyczący konkretnego komponentu w tym kursie. W tym module skupimy się na wytycznych dotyczących formularzy, ale wszystkie inne wytyczne, o których mówiliśmy w poprzednich modułach, np. dotyczące struktury treści, skupienia na klawiaturze i kontrastu kolorów, dotyczą też elementów formularzy.

Pola

Podstawą formularzy są pola. Pola to małe interaktywne wzorce, takie jak pole tekstowe lub pole wyboru, które umożliwiają użytkownikom wpisywanie treści lub dokonywanie wyboru. Do wyboru jest wiele różnych pól formularza.

Domyślnie zalecamy używanie ustalonych wzorów HTML zamiast tworzenia niestandardowych rozwiązań za pomocą ARIA, ponieważ niektóre funkcje i cechy, takie jak stany pól, właściwości i wartości, są nieodłącznie związane z elementami HTML. Pola niestandardowe wymagają ręcznego dodania informacji ARIA.

Niezalecane – niestandardowy kod HTML z atrybutami ARIA.

<div role="form" id="sundae-order-form">
  <!-- form content -->
</div>

Zalecany – standardowy kod HTML

<form id="sundae-order-form">
  <!-- form content -->
</form>

Oprócz wybrania najbardziej dostępnych wzorów pól formularza, w stosownych przypadkach dodaj do pól atrybuty autouzupełniania HTML. Dodanie atrybutów autouzupełniania umożliwia bardziej szczegółowe określanie lub identyfikowanie celu w przypadku user agentów i technologii wspomagających (AT).

Atrybuty autouzupełniania umożliwiają użytkownikom personalizowanie wizualnych elementów, na przykład 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 czytania oraz dla osób korzystających z urządzeń 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>

Pole formularza nie powinno wprowadzać zmian kontekstowych po otrzymaniu fokusa lub danych wejściowych od użytkownika, 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 zostanie skoncentrowane lub gdy użytkownik doda do niego zawartość.

Etykiety

Etykiety informują użytkownika o celu pola (jeśli jest ono wymagane) i mogą też zawierać informacje o wymaganiach dotyczących pola, np. o formatie danych wejściowych. Etykiety muszą być zawsze widoczne i dokładnie opisywać pole formularza.

Jednym z podstawowych założeń dotyczących formularzy dostępnych jest tworzenie wyraźnego i dokładnego powiązania między polem a jego etykietą. Dotyczy to zarówno wizualizacji, jak i programowania. Bez tego kontekstu użytkownik może nie rozumieć, 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ć grupowane programowo i wizualnie. Jedną z metod jest użycie pola formularza i wzorca legendy do grupowania podobnych elementów.

Teksty reklamy

Opis pola ma podobne przeznaczenie do etykiet, ponieważ służy do przedstawienia kontekstu pola i wymagań. Opisy pól nie są wymagane ze względów ułatwiania dostępu, jeśli etykiety lub instrukcje dotyczące formularza są wystarczająco szczegółowe.

Są jednak sytuacje, w których dodanie dodatkowych informacji jest przydatne, aby uniknąć błędów w formularzu. Może to być na przykład podanie informacji o minimalnej długości danych w polu z hasłem lub wskazanie użytkownikowi, którego formatu kalendarza należy użyć (np. DD-MM-RRRR).

Istnieje wiele różnych metod dodawania do formularzy opisów pól. Najlepszym sposobem jest dodanie do elementu formularza atrybutu aria-describedby oprócz elementu <label>. Czytnik ekranu odczyta zarówno opis, jak i etykietę.

Jeśli dodasz atrybut aria-labelledby do elementu, jego wartość zastąpi tekst w elemencie <label>. Jak zawsze, przetestuj ostateczny kod ze wszystkimi AT, które chcesz obsługiwać.

Błędy

Podczas tworzenia dostępnych formularzy możesz zrobić wiele, aby zapobiec błędom popełnianym przez użytkowników. Wcześniej w tym module omawialiśmy wyraźne oznaczenie pól, tworzenie etykiet identyfikujących i dodawanie szczegółowych opisów, gdy tylko jest to możliwe. Jednak bez względu na to, jak czytelny jest Twój formularz, użytkownik może w końcu popełnić błąd.

Gdy użytkownik napotka błąd w formularzu, pierwszym krokiem jest poinformowanie o nim. Pole, w którym wystąpił błąd, musi być wyraźnie oznaczone, a sam błąd musi być opisany w tekście.

Istnieją różne metody wyświetlania komunikatów o błędach, np.:

Modalny, w pobliżu miejsca wystąpienia błędu
zbiór błędów zgrupowanych w jeden większy komunikat u góry strony;

Podczas ogłaszania błędów należy zwrócić uwagę na fokus klawiatury i opcje regionu na żywo ARIA.

W miarę możliwości podaj użytkownikowi szczegółowe sugestie dotyczące rozwiązania błędu. Dostępne są 2 atrybuty, które umożliwiają powiadamianie użytkowników o błędach.

Możesz użyć atrybutu HTML required (wymagany). Przeglądarka wyświetli ogólny komunikat o błędzie na podstawie przesłanych parametrów weryfikacji.
Możesz też użyć atrybutu aria-required, aby udostępnić niestandardową wiadomość o błędzie usługom AT. Wiadomość otrzymają tylko boty, chyba że dodasz dodatkowy kod, aby była ona widoczna dla wszystkich użytkowników.

Gdy użytkownik uzna, że wszystkie błędy zostały naprawione, pozwól mu ponownie przesłać formularz i przekazać opinię na temat wyników przesłania. Komunikat o błędzie informuje użytkownika, że musi wprowadzić więcej zmian, a komunikat o udanym zakończeniu – że naprawił wszystkie błędy i pomyślnie przesłał formularz.

Dodatkowe kryteria sukcesu

W standardzie WCAG 2.2 wprowadzono następujące kryteria powodzenia, które koncentrują się na zwiększeniu dostępności platform:

Sprawdź swoją wiedzę

Sprawdź swoją wiedzę o dostępnych formularzach

Które z tych pól formularza jest najłatwiej dostępne?

Email address: <input type="email" required>

Nie ma etykiety, która łączy „Adres e-mail” z danymi wejściowymi.

<label>Email address: <input type="email" required></label>

Brakuje atrybutu autouzupełniania, który definiuje lub identyfikuje cel dla klientów użytkownika i technologii wspomagających (AT).

<label>Email address: <input type="email" required autocomplete="email"></label>

To jest etykieta pola z dostępnością, ale nie jest to najbardziej dostępna etykieta na tej liście.

<label>Email address (required): <input type="email" required aria-describedby="email-validation"> <span id="email-validation" class="validation-message">Please provide a valid email address using the format name@place.com</span></label>

Atrybut aria-describedby dodaje kontekst do błędu, który może się pojawić, jeśli pole jest nieprawidłowo wypełnione. Ten atrybut nie jest wymagany, ale może być przydatny dla użytkowników AT.