blog na temat dostępności stron internetowych

Przejdź do głównej treści

Dostępne formularze – część 2: komunikaty o błędach

W pierwszej części artykułu o formularzach (“Dostępne formularze – część 1: etykiety i pola“) opisane zostały zasady poprawnego oznaczania pól formularzowych i etykiet tak, aby ich cel był zrozumiały dla wszystkich użytkowników. W drugiej części chciałabym omówić metody prawidłowego zamieszczania komunikatów o błędach.

W większości formularzy internetowych wprowadzone przez użytkownika dane nie są wysyłane od razu, gdy naciśnięty zostaje przycisk zatwierdzający; najpierw dane te podlegają tzw. walidacji. Walidacja polega na sprawdzeniu, czy wymagane pola nie są puste, oraz czy wprowadzone dane są zgodne z oczekiwanym formatem, czy też w dopuszczalnym przedziale wartości. Jeśli tak nie jest, formularz nie zostaje zatwierdzony i wyświetlone zostają komunikaty o błędach. Aby użytkownicy byli w stanie je poprawić, muszą oni po pierwsze być świadomi tego, że w formularzu zostały wykryte jakieś błędy, po drugie wiedzieć, w których polach zostały one znalezione, a po trzecie rozumieć na czym one polegają. Można to osiągnąć na kilka sposobów.

Wyświetlenie listy wszystkich błędów

Metoda 1 – okienko alert

Jednym ze sposobów na prawidłowe poinformowanie użytkowników o wykrytych błędach jest wyświetlenie komunikatu za pomocą okienka “alert” przy użyciu JavaScript. Ma to tę zaletę, że przeoczenie tego okienka jest praktycznie niemożliwe – ilekroć wyświetlone jest ono na stronie, reszta strony zostaje tymczasowo dezaktywowana, dopóki użytkownik nie zatwierdzi zawartej w nim treści. Okienko to jest także łatwe do zauważenia dla osób posługujących się czytnikami ekranu, gdyż w momencie, gdy okienko alert pojawia się na stronie, fokus klawiatury zostaje do niego przeniesiony, a jego treść zostaje automatycznie odczytana.

fragment formularza z wyświetlonym okienkiem alert, w którym zawarta jest lista błędów znalezionych w formularzu

Metoda 2 – treść komunikatu dodana do drzewa DOM

Innym sposobem jest wyświetlenie listy wszystkich wykrytych błędów przed formularzem, poprzez wstawienie nowej sekcji do drzewa DOM. Lista błędów powinna stosować elementy <a> do wyświetlania poszczególnych błędów w taki sposób, by każdy z nich przenosił fokus klawiatury do odpowiadającego mu pola formularzowego:

fragment formularza przed którym zamieszczona jest sekcja opisująca wykryte błędy

Tego rodzaju komunikat o błędach jest mniej zauważalny niż okienko alert, szczególnie dla osób niewidomych. Jeśli użytkownik czytnika ekranu naciśnie przycisk zatwierdzający formularz i w wyniku wykrytych błędów przed formularzem zostanie wyświetlony odpowiedni komunikat, osoba ta nie będzie świadoma, że nastąpiły jakieś zmiany na stronie. Z punktu widzenia tych użytkowników przycisk zatwierdzający po prostu nie zadziałał; nie otworzyła się nowa strona z informacją o pomyślnie wysłanym formularzu, nie został odczytany żaden komunikat o błędzie, a fokus klawiatury pozostał na przycisku. Dlatego też istotne jest, by w przypadku stosowania tej metody pamiętać o tym, że w momencie gdy lista błędów zostaje wyświetlona na stronie, fokus klawiatury powininen zostać przeniesiony do elementu zawierającego listę błędów, bądź też do pierwszego z problematycznych pól.

Innym sposobem na to, by upewnić się, że wyświetlona w ten sposób informacja o błędach będzie łatwa do zauważenia dla osób niewidomych, jest zastosowanie ARIA role="alert" lub aria-live.
role=alert pełni taką samą funkcję jak aria-live="assertive": jeśli zawartość elementu posiadającego jeden z tych atrybutów zmieni się (na przykład zostanie do niego dodana nowa treść), czytnik ekranu natychmiast powiadomi o tym użytkownika. Należy też pamiętać o dodaniu atrybutu aria-atomic="true", gdyż bez niego czytnik ekranu Voiceover na urządzeniach iOS nie odczyta zawartości komunikatu, gdy wystąpiła więcej niż jedna nieudana próba zatwierdzenia formularza.

<div class="ostrzezenia" role="alert" aria-atomic="true">
  <h2>W formularzu wykryto błędy</h2>
  <p>Przed ponownym zatwierdzeniem formularza należy poprawić następujące błędy:<p>
  <ul>
    <li>
      <a href="#imie">pole "Imię" nie zostało wypełnione</a>
    </li>
    <li>
      <a href="#email">nieprawidłowy format adresu emailowego</a>
    </li>
  </ul>
</div>
<form>
  <label for="imie">Imię: </label>
  <input id="imie" [...] >
  <label for="email">Email: </label>
  <input id="email" [...] >
</form>

Jedyną (niewielką) wadą tego rozwiązania jest to, że element posiadający role="alert" musi być obecny w DOM zanim użytkownik zatwierdzi formularz. W przeciwnym wypadku treść zawarta w elemencie z role="alert" nie zostanie odczytana przez niektóre czytniki ekranu. Choć oznacza to posiadanie na stronie pustego elementu HTML w strukturze DOM (co nie jest idealne z punktu widzenia czystości kodu), nie powoduje to żadnych problemów:

<!-- pusty element, gotowy na dodanie do niego komunikatów w wypadku, gdy zostaną wykryte błędy -->
<div class="ostrzezenia" role="alert" aria-atomic="true">
</div>
<form>
[...]
</form>

Wyświetlenie indywidualnych komunikatów o błędach przy każdym z pól

Innym sposobem powiadomienia użytkowników o błędach wykrytych w formularzu jest zapewnienie indywidualnych komunikatów o błędach dla każdego z pól podlegających walidacji.
Wizualnie najczęściej jest to wykonane przez zaznaczenie problematycznych pól na czerwono bądź też przy użyciu ikonki reprezentującej błąd oraz wyświetlenie obok pola informacji o błędzie. Należy tu pamiętać o kilku prostych zasadach:

  • treść każdego komunikatu powinna jednoznacznie identyfikować pole, do którego się odnosi, przy pomocy jego nazwy wyświetlonej w etykiecie, np. “Pole email jest wymagane”
  • każdy komunikat powinien jasno wyjaśniać, jakiego rodzaju błąd został wykryty. Wiadomość typu “Nowe hasło jest nieprawidłowe” nie będzie specjalnie pomocna dla użytkowników. Jeśli wiadomo więcej o naturze tego błędu, należy dodać tę informację do komunikatu o błędzie, np. “Nowe hasło musi się składać przynajmniej z 7 liter i jednej cyfry” (nawiasem mówiąc, wymagany format pola powininen być podany zanim użytkownik przystąpi do wprowadzania danych do tego pola, najlepiej jako część etykiety)
  • każdy komunikat powinien być odpowiednio powiązany w kodzie strony z odpowiadającym mu polem. Jak wspomniałam już w pierwszej części artykułu o formularzach, czytniki ekranu ignorują statyczną treść, gdy przechodzą w tryb formularzowy (aplikacji). Dlatego też osoby niewidome najprawdopodobniej przeoczą wiadomość wyświetloną przy pomocy zwykłego paragrafu (<p>). Aby stworzyć programistyczny związek pomiędzy tym komunikatem a polem, którego dotyczy, należy albo zamieścić tę informację w etykiecie (która jest automatycznie odczytywana przez czytniki ekranu, gdy użytkownik przeniesie fokus do pola:

    <label class="blad" for="email">Email: * - to pole jest wymagane</label>
    <input id="email" type="text" placeholder="np. jan.kowalski@poczta.pl" aria-required="true" >
    

    … bądź też powiązać komunikat o błędzie z odpowiadającym mu polem poprzez zastosowanie atrybutu "aria-describedby":

    <label for="email">Email: </label>
    <p class="blad" id="email-blad">Pole email jest wymagane</p>
    <input id="email" type="text" placeholder="np. jan.kowalski@poczta.pl" aria-required="true" aria-describedby="email-blad">
    

    Podobnie jak w przypadku umieszczenia komunikatu o błędzie w etykiecie, współczesne czytniki ekranu automatycznie odczytają treść tej wiadomości, gdy opisywane przez nią pole uzyska fokus klawiatury.

To tyle jeśli chodzi o komunikaty o błędach wyświetlone w formie tekstowej. A co z oznaczeniem samych pól? Najczęściej pola, w których znaleziono błędy, wyróżniane są przy pomocy czerwonej obwódki bądź też czerwonego tła. Pamiętajmy jednak, że nie wszystkie osoby będą w stanie dostrzec ten kolor lub też odróżnić go od koloru pozostałych pól (osoby z zaburzeniami widzenia barw mogą nie odróżniać jasnoczerwonego tła od jasnoszarego). Dlatego też obok każdego z pól, w których wystąpiły błędy, można dodatkowo wyświetlić ikonkę symbolizującą błąd, np. wykrzyknik.

fragment formularza z opisami błędów zawartymi w etykietach pól (np. '! Pole imię jest obowiązkowe'). Same pola zaznaczone są grubą czerwoną obwódką

A jak możemy zaznaczyć te pola z myślą o osobach niewidomych? Poprzez dodanie atrybutu aria-invalid="true":

<label for="email">Email: </label>
<p class="blad" id="email-blad">Pole email jest wymagane</p>
<input id="email" type="text" placeholder="np. jan.kowalski@poczta.pl" aria-required="true" aria-describedby="email-blad" aria-invalid="true">

Narzędzia

Czy istnieją gotowe skrypty, które ułatwiają walidację formularzy i pozwalają na dokonanie tego zgodnie z zasadami dostępności? Na szczęście tak. Ja osobiście często stosuję jQuery form validation plugin dostępny na Github.

Którą z powyższych metod zastosować?

Aby formularz był zgodny z wytycznymi WCAG 2.0 można posłużyć się albo jedną, albo drugą z nich. Najważniejsze jest upewnienie się, że użytkownicy będą świadomi, iż w formularzu zostały wykryte błędy, że tekstowe komunikaty o błędach jednoznacznie identyfikują problematyczne pola, oraz że komunikaty te są wystarczająco opisowe. W przypadku dłuższych formularzy najlepiej jednak połączyć obydwie te metody, tj. wyświetlić listę wykrytych błędów oraz indywidualne komunikaty przy każdym z pól.

Dodaj komentarz

Należy wypełnić wszystkie pola oznaczone asteryskiem (*).
Zanim komentarz zostanie opublikowany będzie musiał zostać zatwierdzony przez moderatora.

Możesz wykorzystać następujące elementy HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>