Formularze – dlaczego poprawna implementacja jest taka ważna?
- Przejdź do artykułów z tagiem dostępność
- Przejdź do artykułów z tagiem dostępny formularz
- Przejdź do artykułów z tagiem forms
- Przejdź do artykułów z tagiem formularze
- Przejdź do artykułów z tagiem WCAG
Treść artykułu
Czym są formularze
Formularze służą do interakcji użytkownika z naszą aplikacją, stroną, systemem. W szczególności są wykorzystane podczas rejestracji, logowania, zakupu czy komentowania. Zgodnie z założeniami dostępności cyfrowej opisanej w standardzie WCAG 2.1 [polskie tłumaczenie WCAG 2.1] są elementem, na który trzeba zwrócić szczególną uwagę.
Najczęstsze błędy:
- Brak autouzupełniania (ang. autocomplete).
- Brak grupowania zestawu pól złożonych formularzy (fieldset oraz legend).
- Brak oznaczenia wizualnie i programistycznie pól wymaganych (required, aria-required).
- Brak etykiet pól i/lub powiązania etykiet z tymi polami (label).
- Brak powiązania komunikatów błędów z polami (aria-describedby).
Ad 1. Brak autouzupełniania (ang. autocomplete)
Wypełnianie formularzy zawsze tymi samymi danymi to strata czasu. Osoby z niepełnosprawnościami często mają trudności z obsługą bardziej złożonych formularzy. W szczególności z wpisywaniem dat. Z pomocą przychodzi atrybut autocomplete. Odpowiednio użyty pozwala znacząco przyspieszyć i ułatwić uzupełnienie pól tekstowych, danych wejściowych czy też odpowiednio ustawić listy wyboru.
Lista dostępnych wartości atrybutu jest dość długa i pozwala tak stworzyć formularz, że użytkownik uzyska wiele podpowiedzi. A w idealnym przypadku będzie musiał tylko zaakceptować wypełniony automatycznie formularz.
Aczkolwiek należy również pamiętać o zagrożeniach jakie niesie ze sobą niekontrolowane autouzupełnianie. Choćby loginem i hasłem podczas logowania. W tym wypadku to użytkownik powinien decydować czy pola mają być wypełnione za niego.
Jednakże ten temat jest wart szerszego omówienia w przyszłości 🙂
Ad 2. Brak grupowania zestawu pól
Przyzwyczajeni jesteśmy do opisywania zdjęć oraz tabel podpisami, które grupujemy z tymi zdjęciami i tabelami. Również w przypadku formularzy dobrą praktyką jest grupowanie pól w zestawy.
Spójrzmy na formularz, który wypełniamy podczas zakupów w sklepach internetowych. Zazwyczaj składa się z kilku sekcji. Mamy dane zamawiającego, adres dostawy, jest również miejsce na dane do faktury. Zamawiamy towar dla znajomego. Wyobraźmy sobie, że pola nie są w żaden sposób od siebie oddzielone. Łatwo będzie w takim wypadku pomylić się wpisując w miejscu na adres dostawy dane zamawiającego (nasze) i przesyłka dojdzie nie pod ten adres.
Do uporządkowania powiązanych ze sobą kontrolek formularzy najlepiej nadaje się zestaw znaczników fieldset oraz legend. Dzięki nim łatwo i przejrzyście pogrupujemy pola tekstowe. Możemy również stworzyć choćby zestaw checkboxów z opcjami dodatkowymi takimi jak powiadomienie sms, dostawa do godziny 12:00 czy też zapakowanie na prezent.
Ad 3. Brak oznaczenia pól wymaganych
Przy wypełnieniu formularza nie wszystkie pola są zawsze obligatoryjne, ale te które są konieczne do zapisania formularza muszą być oznaczone wizualnie i programistycznie.
Pierwszy aspekt zazwyczaj jest dobrze rozwiązany. Najczęściej w formie znaków specjalnych (*) lub dodatkowego tekstu w etykiecie pola (np. pole wymagane). Niestety programistyczne zdefiniowanie wymaganych pól często jest pomijane. Najlepiej nadaje się do tego atrybut required oraz aria-required. Szczególnie istotne jest to dla osób, które korzystają z czytników ekranu i mogą nie spostrzec wizualnie wyróżnionych etykiet.
Dodatkowo dobre oznaczenie pól wymaganych łączy się bezpośrednio z błędami, jakie mogą pojawić się po zakończeniu wypełniania formularza.
Ad 4. i 5. Brak etykiet oraz powiązania komunikatów błędów z polami
Po tym jak już wypełnimy cały formularz, chcemy go przesłać. W tym momencie może się okazać, że zapomnieliśmy uzupełnić wymagane pole. Popełniliśmy błąd i wpisaliśmy za długi numer telefonu. Nie wypełniliśmy formularza w ogóle. W takiej sytuacji powinniśmy zostać poinformowani, co należy poprawić. Dobrze by było, żebyśmy dostali również informację, czemu wprowadzona przez nas wartość jest nieprawidłowa.
W znakomitej większości przy formularzach pojawiają się komunikaty informujące nas o tym, że coś jest nie tak. Niestety bardzo rzadko są one powiązane z danym polem formularza, co utrudnia zadanie nawet osobom bez dysfunkcji. Niejednokrotnie treść przekazywanej informacji jest nieadekwatna do samego błędu, a czasem jest wręcz myląca. Poniżej zrzut ekranu, na którym widnieje jeden z przetestowanych przeze mnie formularzy.
Zasadniczym problemem w tym wypadku był brak powiązanych komunikatów, ale możemy zauważyć również wprowadzanie użytkownika w błąd (kod pocztowy nie zawiera liter).
Do opisywania niezgodności z polem dobrze jest wykorzystać atrybuty label for oraz aria-describedby. Pierwszy pozwala nam powiązać etykietę z polem formularza, drugi z komunikatem błędu. Poniżej przykład porządnej implementacji formularza logowania, w którym dodatkowo zadbano o przeniesienie fokusa na pierwsze pole, co ułatwia użytkownikowi szybsze zalogowanie do serwisu.
<div class="form-group m-form__group has-danger">
<label class="control-label m-label" for="m_login_signin_username">Adres e-mail</label>
<input class="form-control m-input" type="text" aria-required="true" placeholder="Adres e-mail" name="email" id="m_login_signin_username" autofocus="autofocus" data-valid="email" value="" aria-describedby="m_login_signin_username-error">
<div id="m_login_signin_username-error" class="form-control-feedback" data-error-source="m_login_signin_username">Nieprawidłowy adres e-mail</div>
</div>
Podsumowanie
Dzięki formularzom możemy zgromadzić potrzebne dane do realizacji zamówienia, otrzymać opinie od klienta, wystawić komentarz czy też zapisać się do newslettera. Są one nierozłącznym elementem każdej strony internetowej czy też innego serwisu, w którym użytkownik prowadzi interakcję. Poprawna implementacja pomoże utrzymać uwagę, przyspieszyć proces zakupu, nie zniechęci użytkownika do porzucenia zamówienia i przejścia do konkurencji.
Radosław Stachurski
Accessibility Specialist & WCAG 2.1 Auditor & Quality Assurance
Polecane artykuły
-
14.02.2023Akademia WCAG
WCAG 2.1. – kryterium 1.2.5 – Audiodeskrypcja (nagranie) (poziom AA)
Dzisiaj kryterium 1.2.5, które jest powiązane z kryterium 1.2.3. Jeżeli zaadresowaliśmy audiodeskrypcję w 1.2.3 to kryterium 1.2.5 jest z automatu…
-
02.08.2024Akademia WCAG
WCAG 2.1 – Kryterium 3.3.5 – Pomoc (poziom AAA)
WCAG i pomoc… łączy się? Zdecydowanie! Właściwie wszystkie kryteria WCAG służą temu, by ułatwiać nam poruszanie się w Internecie. Jest…
-
24.10.2024Co słychać u niedosłyszącej
Co słychać u niedosłyszącej: Umawianie wizyt na badania słuchu przez telefon?
Witajcie w nowym cyklu felietonów: co słychać u niedosłyszącej? Będę tu opisywać moje doświadczenia z wadą słuchu, którą mam od…