Dostępność ≠ Overlay: gdy nie można wypełnić formularza za pomocą czytnika ekranu

Pole może być oczywiste wizualnie, a mimo to czytnik odczytuje jedynie „pole edycji”. Bez powiązanej etykiety nie wiadomo, czy chodzi o imię, adres e-mail czy numer telefonu.

Każda kontrolka potrzebuje dostępnej nazwy i, gdy to właściwe, poprawnie powiązanej etykiety HTML. Wymagane pola i oczekiwany format trzeba wyjaśnić wcześniej; tekst zastępczy nie zastępuje etykiety.

Tab powinien przenosić fokus między kontrolkami w logicznej kolejności. Listy wyboru, pola wyboru, przyciski i kalendarze muszą działać bez myszy, z widocznym fokusem i bez niespodziewanych przeskoków.

Czerwona ramka nie wyjaśnia błędu. Należy opisać go tekstowo, powiązać komunikat z polem i umożliwić poprawę bez utraty danych. Dynamiczne komunikaty powinny być prawidłowo odczytywane.

Przy zakupach i ważnych operacjach warto zapewnić możliwość sprawdzenia i potwierdzenia danych, gdy jest to potrzebne. Przycisk wysyłania wymaga jasnej nazwy, a wynik musi zostać przekazany w dostępny sposób.

WCAG 2.2 obejmują etykiety i instrukcje (3.3.2), identyfikację błędów (3.3.1), nazwę, rolę i wartość kontrolek (4.1.2) oraz obsługę klawiaturą (2.1.1). Liczy się test rzeczywistego działania.

Blind Reader może wyjaśniać cel strony, pomagać znaleźć formularze, wspierać nawigację i obsługę głosową. Wprowadza też wybrane automatyczne poprawki, m.in. lepsze oznajmianie pól wymaganych. Uzupełnia prawidłowo zbudowane formularze.

Wypełnij formularz klawiaturą i za pomocą NVDA, VoiceOver lub innego czytnika. Sprawdź nazwy pól, wywołaj błąd, popraw go i potwierdź wysłanie. Jeśli któryś etap jest niedostępny, bariera nadal istnieje.

• W3C WAI — Forms Tutorial
• W3C — WCAG 2.2, Labels or Instructions (3.3.2)
• W3C — WCAG 2.2, Error Identification (3.3.1)
• W3C — WCAG 2.2, Name, Role, Value (4.1.2)

Formularz jest dostępny wtedy, gdy można ukończyć zadanie, a nie tylko zobaczyć formularz.

Odcinek 18 · Dostępność ≠ Overlay