brak etykiet dla pól (dostępność WCAG)

Brak etykiet dla pól, wynikający z niedopatrzenia w zakresie dostępności WCAG, utrudnia korzystanie z formularza osobom korzystającym z czytników ekranu.

Brak etykiet dla pól formularza to błąd dostępności, w którym element przeznaczony do wpisania danych nie ma prawidłowo powiązanego opisu tekstowego. Etykieta wyjaśnia, czego oczekuje się od osoby wypełniającej formularz, na przykład adresu e-mail, numeru telefonu, hasła albo treści wiadomości. Sam tekst umieszczony wewnątrz pola jako placeholder nie powinien być traktowany jako pełnoprawna etykieta, ponieważ może zniknąć po rozpoczęciu wpisywania, mieć zbyt niski kontrast albo nie zostać właściwie odczytany przez technologie wspomagające.

Znaczenie etykiet w dostępnych formularzach

W poprawnie przygotowanym formularzu etykieta jest programowo powiązana z konkretnym polem. Dzięki temu czytnik ekranu może przekazać użytkownikowi zarówno nazwę kontrolki, jak i jej aktualny stan. Osoba korzystająca z klawiatury lub technologii asystujących wie wtedy, czy należy wpisać imię, wybrać województwo, podać numer zamówienia czy uzupełnić pole wymagane. Etykieta powinna być jednoznaczna, widoczna albo dostępna dla czytnika ekranu w sposób zgodny z przeznaczeniem interfejsu.

W praktyce poprawne rozwiązanie może opierać się na elemencie <label> powiązanym z identyfikatorem pola, na odpowiedniej strukturze grupy formularza albo na właściwościach ARIA stosowanych tylko wtedy, gdy standardowe elementy HTML nie wystarczają. Należy również zadbać o komunikaty błędów, instrukcje dotyczące formatu danych oraz informację o obowiązkowości pola. Sama deklaracja aria-label nie naprawia każdego problemu, zwłaszcza gdy widoczny tekst, opis i nazwa dostępna przekazują różne informacje.

Porównanie z innymi problemami dostępności

Brak etykiety różni się od nieczytelnego kontrastu, zbyt małego obszaru kliknięcia czy nieprawidłowej kolejności przechodzenia klawiszem Tab. Wszystkie te usterki mogą występować jednocześnie, ale wymagają odrębnej oceny. Formularz może mieć wyraźne obramowania i poprawny kontrast, a mimo to pozostawać trudny w użyciu, jeżeli po przejściu do pola nie da się ustalić, jakie dane powinny zostać wpisane.

Ważne jest także odróżnienie etykiety od tekstu pomocniczego. Etykieta identyfikuje pole, natomiast opis dodatkowy może objaśniać wymagania, na przykład dopuszczalny format daty lub sposób zapisania numeru. Jeżeli kilka pól tworzy jedną logiczną kategorię, taką jak dane kontaktowe albo adres, przydatne może być zastosowanie grupowania z odpowiednim nagłówkiem. W przypadku pól wyboru, przycisków opcji i list rozwijanych należy sprawdzić, czy nazwa każdej kontrolki jest zrozumiała bez polegania wyłącznie na położeniu lub wyglądzie.

Typowe przyczyny i skutki błędu

Problem pojawia się często podczas projektowania formularza wyłącznie na podstawie wyglądu wizualnego. Tekst może zostać umieszczony obok pola w taki sposób, że dla osoby widzącej wydaje się oczywistym opisem, lecz w kodzie nie ma żadnego powiązania z kontrolką. Podobna sytuacja występuje po zmianie biblioteki interfejsu, skopiowaniu komponentu bez jego identyfikatorów albo dynamicznym generowaniu pól bez zachowania unikatowych atrybutów.

Skutkiem jest odczytywanie przez czytnik ekranu jedynie informacji typu „pole edycji” bez wskazania jego przeznaczenia. Utrudnia to wypełnianie formularzy, zwiększa ryzyko wpisania danych w niewłaściwe miejsce i może uniemożliwić przejście całego procesu, gdy po wysłaniu pojawią się niejasne komunikaty. Niedostępność może dotyczyć również osób z ograniczeniami poznawczymi, użytkowników powiększających ekran oraz osób korzystających z formularza przy nietypowych ustawieniach lub na urządzeniu mobilnym.

W jakich sytuacjach warto poprosić o ocenę stanu sprzętu - brak etykiet dla pól (dostępność WCAG)

Zgłoszenie do serwisu jest uzasadnione, gdy formularze działają wizualnie, lecz użytkownicy zgłaszają problemy z ich odczytywaniem, nawigacją klawiaturą albo rozpoznaniem wymaganych danych. Warto przeanalizować nie tylko pojedyncze pole, ale też cały przebieg: przejście między kontrolkami, odczyt instrukcji, reakcję na błędne dane, komunikat po wysłaniu oraz zachowanie formularza po powiększeniu strony. Przydatne jest połączenie inspekcji kodu z testem za pomocą klawiatury i czytnika ekranu.

W Warszawie takie sprawdzenie strony lub komputera może zostać zlecone firmie Warszawskie Pogotowie Komputerowe 24/7, gdzie diagnoza laptopa jest wykonywana bez opłat. W ramach analizy można ustalić, czy przyczyną są brakujące elementy <label>, niespójne identyfikatory, błędne użycie ARIA, niewłaściwe komunikaty walidacyjne albo problem wynikający z konkretnego skryptu formularza. Po rozpoznaniu źródła usterki łatwiej zaplanować poprawki tak, aby nazwy pól, instrukcje i komunikaty były zrozumiałe dla różnych sposobów korzystania ze strony.