brak oznaczeń ARIA w polach formularza

Brak oznaczeń ARIA w polach formularza to usterka dostępności utrudniająca korzystanie z formularza przez czytniki ekranu.

Na czym polega brak oznaczeń ARIA w formularzu

Brak oznaczeń ARIA w polach formularza oznacza, że elementy interfejsu nie przekazują czytnikowi ekranu wystarczających informacji o swojej funkcji, stanie albo powiązaniu z opisem. ARIA, czyli Accessible Rich Internet Applications, jest zestawem atrybutów używanych w dokumentach HTML do uzupełniania informacji dostępnościowych przekazywanych przez przeglądarkę do technologii asystujących. Problem może dotyczyć między innymi pól tekstowych, pól wyboru, przycisków, komunikatów walidacyjnych oraz dynamicznie pokazywanych podpowiedzi.

Nie każde pole formularza wymaga dodania atrybutu ARIA. Natywny element <input> z poprawnym typem, widocznym tekstem <label> oraz właściwą strukturą HTML może już przekazywać czytnikowi ekranu nazwę i podstawowe przeznaczenie. Oznaczenia ARIA są potrzebne przede wszystkim wtedy, gdy standardowe elementy HTML nie opisują wystarczająco niestandardowego komponentu albo gdy trzeba przekazać dodatkowy stan, relację lub komunikat.

Relacja między polem, etykietą i opisem

Najważniejszą informacją dla użytkownika czytnika ekranu jest dostępna nazwa pola. W typowym formularzu uzyskuje się ją przez połączenie elementu <label> z kontrolką za pomocą atrybutów for i id. Przykładowo etykieta „Adres e-mail” powinna wskazywać konkretne pole, a nie być jedynie tekstem umieszczonym obok niego. Sam placeholder nie zastępuje etykiety, ponieważ może zniknąć po rozpoczęciu wpisywania i nie zawsze jest traktowany jako stabilna nazwa kontrolki.

Dodatkowy opis można powiązać z polem przez aria-describedby. Jest to przydatne, gdy użytkownik powinien usłyszeć informację o formacie danych, wymaganym zakresie albo sposobie poprawienia wartości. Atrybut aria-label może nadać kontrolce nazwę bez widocznej etykiety, natomiast aria-labelledby pozwala wykorzystać tekst istniejącego elementu. W praktyce należy uważać, aby nie tworzyć dwóch konkurencyjnych nazw ani nie ukrywać przed wzrokiem etykiet, które powinny pozostać widoczne także dla osób korzystających z powiększenia lub nawigacji klawiaturą.

W grupach pól, takich jak zestaw przycisków radiowych, właściwą strukturę zapewniają między innymi <fieldset> i <legend>. Jeżeli komponent jest zbudowany niestandardowo, można zastosować relacje ARIA, lecz trzeba zachować zgodność między rolą elementu, jego nazwą i rzeczywistym zachowaniem. Dodanie samego atrybutu bez prawidłowej struktury nie naprawia problemu, gdy kontrolka nie może być obsługiwana klawiaturą albo nie reaguje zgodnie z oczekiwaną rolą.

Stany pól, błędy walidacji i treści dynamiczne

Formularz powinien przekazywać nie tylko nazwę pola, lecz także jego aktualny stan. Dla pola zawierającego błąd można użyć aria-invalid="true", ale atrybut ten powinien być ustawiany dopiero wtedy, gdy błąd rzeczywiście występuje. Komunikat wyjaśniający problem należy powiązać z kontrolką za pomocą aria-describedby albo innego prawidłowego mechanizmu relacji. Sam kolor obramowania, ikona lub tekst wyświetlony wizualnie nie gwarantują, że informacja zostanie odczytana przez czytnik ekranu.

Wymagalność pola można oznaczyć natywnym atrybutem required, a w przypadku odpowiednio uzasadnionej potrzeby także przez aria-required="true". Nie należy jednak używać ARIA do zastępowania funkcji dostępnych w HTML, jeśli natywny mechanizm działa poprawnie. Podobnie aria-expanded powinno odzwierciedlać rzeczywisty stan rozwinięcia kontrolowanego panelu, a aria-controls musi wskazywać istniejący element o określonym identyfikatorze. Nieaktualne wartości tych atrybutów wprowadzają użytkownika w błąd.

Walidacja wykonywana bez przeładowania strony wymaga dodatkowej kontroli kolejności komunikatów. Po wysłaniu formularza użytkownik powinien móc ustalić, które pole jest niepoprawne, usłyszeć przyczynę oraz przejść do miejsca wymagającego korekty. Komunikat ogólny o wyniku operacji może być przekazywany przez region oznaczony role="status" albo odpowiednio skonfigurowany aria-live, lecz nie powinien powodować wielokrotnego odczytywania całej strony. Każdy komunikat dynamiczny wymaga sprawdzenia, czy jest ogłaszany w odpowiednim momencie i tylko wtedy, gdy jego treść faktycznie się zmieniła.

Sprawdzenie poprawności oznaczeń w działającym formularzu

Diagnostyka zaczyna się od przejrzenia struktury HTML i ustalenia, czy każda kontrolka ma dostępną nazwę, prawidłowy typ oraz logiczne powiązanie z opisem. Następnie sprawdza się obsługę klawiaturą: kolejność fokusu, widoczność fokusu, możliwość wejścia do każdego pola oraz opuszczenia komponentu bez zablokowania użytkownika. W narzędziach deweloperskich można przeanalizować drzewo dostępności przeglądarki i porównać rolę, nazwę oraz stan elementu z tym, co jest widoczne na stronie.

Test z czytnikiem ekranu powinien objąć pusty formularz, formularz częściowo wypełniony, przypadki błędnej walidacji oraz pomyślne wysłanie danych. Weryfikacji wymagają także pola ujawniane warunkowo, niestandardowe listy wyboru, pola autouzupełniania i formularze osadzone w oknach modalnych. Automatyczne skanery mogą wykryć brak etykiety lub nieprawidłową relację, ale nie ocenią w pełni jakości komunikatu, kolejności odczytu ani zgodności zachowania niestandardowego komponentu z jego rolą.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i podzespołów, a w przypadku problemu z formularzem można zlecić sprawdzenie działania strony, przeglądarki oraz oprogramowania na używanym komputerze. Zakres diagnozy powinien obejmować odtworzenie problemu, rozróżnienie usterki kodu strony od problemu konfiguracji czytnika ekranu oraz wskazanie elementów wymagających korekty. Oznaczenia ARIA powinny być dodawane zgodnie z rzeczywistą semantyką kontrolki, ponieważ nieprawidłowe role i stany mogą pogorszyć dostępność zamiast ją poprawić.