Formularze są jednym z najczęściej używanych elementów w aplikacjach web i mobilnych. Od logowania, przez checkouty, po zapytania ofertowe – każdy z nas wypełnia je codziennie.
Dla użytkowników korzystających z czytników ekranu lub technologii wspomagających, kluczową informacją jest to, które pola są wymagane.
Problem zaczyna się wtedy, gdy ta informacja jest tylko wizualna, np. w postaci gwiazdki (*) czy dopisku „wymagane”, a nie jest dostępna programowo. W efekcie osoba korzystająca z czytnika ekranu może nie wiedzieć, że dane pole musi zostać wypełnione, dopóki nie spróbuje przesłać formularza i otrzyma komunikatu o błędzie.
Aby temu zapobiec, w ARIA istnieje atrybut aria-required, który informuje technologie asystujące, że dany element musi być wypełniony przed wysłaniem formularza.
Co robi aria-required
aria-required="true"- przekazuje do technologii asystujących (np. czytników ekranu), że pole jest obowiązkowe,
- nie zmienia zachowania pola ani walidacji przeglądarki – to nadal musi obsłużyć kod lub HTML,
- nie zastępuje wizualnych oznaczeń, ale działa obok nich, sprawiając, że informacja jest dostępna także programowo.
Czyli tylko połączenie wizualnej informacji i programowego oznaczenia daje pełne pokrycie wymagań dostępności: użytkownik widzący widzi gwiazdkę, użytkownik z czytnikiem słyszy, że pole jest wymagane.
Specyfika grup radio buttonów
Najbardziej interesującym przypadkiem jest oznaczenie jako wymagane grup radiobuttonów — czyli zestawu opcji, z którego użytkownik musi wybrać jedną.
W standardowym HTML nie można użyć atrybutu
required
bezpośrednio na
<fieldset>
lub na pojedynczych radio buttonach, które reprezentują cały wybór. Dodatkowo atrybut
aria-requiredrównież nie jest dozwolony na <fieldset> bez roli radiogroup.
To oznacza, że jeśli chcemy, aby technologia asystująca wiedziała, że wybór z grupy radiobuttonów jest obowiązkowy, musimy:
- nadać kontenerowi grupy rolę radiogroup (
role="radiogroup"), - dopisać do niej aria-required=”true”.
Dopiero wtedy technologia asystująca może poinformować użytkownika, że cała grupa wymaga wyboru jednej opcji.
Wsparcie w przeglądarkach i czytnikach – ważne spostrzeżenia z testów
Badania realnego zachowania przeglądarek i czytników pokazują, że:
- Niektóre kombinacje przeglądarka/czytnik poprawnie odczytują
aria-requireddodany do elementów z roląradiogroup, - Zwykłe oznaczenie „required” na
<fieldset>nie jest formalnie poprawne, nawet jeśli część czytników je ogłasza, - Nie zawsze każda konfiguracja czytnika i przeglądarki ogłasza stan prawidłowo — co pokazuje, że technologia asystująca może mieć ograniczenia.
W praktyce oznacza to, że najlepszym (a może najmniej złym) i zgodnym ze specyfikacją rozwiązaniem jest aria-required na elemencie z rolą radiogroup, a także dodanie widocznego komunikatu w legendzie lub obok grupy.
To podejście działa w większości popularnych kombinacji przeglądarka + czytnik i ogranicza ryzyko, że użytkownik „nie usłyszy”, że dana grupa jest obowiązkowa. Dodatkowo wspiera kontekst, w którym technologia asystująca przekazuje informację nie tylko o tym, że element istnieje, ale że wybór jest wymagany.
Praktyczne wskazówki
Żeby formularze były dostępne:
- Nie polegaj wyłącznie na wyglądzie (kolor, gwiazdki, dopiski),
- Zawsze oznacz wizualnie i programowo, że pole jest wymagane,
- Do prostych pól formularza używaj HTML
requiredtam, gdzie to możliwe, - Dla pól lub komponentów niestandardowych (np. grupy radiobuttonów) używaj
aria-requiredna kontenerze z odpowiednią rolą (np.role="radiogroup"), - Testuj formularze zarówno wizualnie, jak i przy pomocy czytników ekranu, aby upewnić się, że komunikat „wymagane” dociera do każdego użytkownika.
Takie podejście sprawia, że formularze rzeczywiście dostosowują się do potrzeb wszystkich użytkowników, nie tylko tych, którzy mogą zobaczyć ekran.
A jeżeli potrzebujesz wsparcia w audytowaniu – sprawdź nasze autorskie narzędzie AUDITA11Y: https://tusietestuje.pl/p/audita11y-kurs/
