Модуль 6 · Урок 23
Accessible forms і помилки
Accessible form пояснює, що ввести, до введення; повідомляє, яке саме поле не пройшло перевірку; і дає suggestion, коли правильний формат відомий. Placeholder не замінює label, а browser validation не замінює server validation.
Persistent label і programmatic association
<label for="email">Email</label>
<input id="email" name="email" type="email"
autocomplete="email" required
aria-describedby="email-hint email-error">
<p id="email-hint">Наприклад, reader@example.test</p>for має точно збігатися з унікальним id. Label лишається видимим після введення. Placeholder — короткий hint усередині field, який зникає, може мати слабкий contrast і не є надійною назвою.
Пов’язані поля — одна зрозуміла group
<fieldset>
<legend>Формат</legend>
<label><input type="radio" name="format" value="pdf"> PDF</label>
<label><input type="radio" name="format" value="epub"> EPUB</label>
</fieldset>legend дає спільний context для radio/checkbox group. Required status, format і constraints повідомляйте до submit у тексті та programmatically. Зірочка без пояснення або колір без тексту не дають достатньої інструкції.
Error identification і suggestion
aria-describedby поля.aria-describedby додає description, але не створює visible error і не замінює label. Якщо suggestion може поставити під загрозу security або purpose, документуйте межу.
Практика
- Заповніть form-error worksheet для email, format group і submit.
- Замініть placeholder-only inputs на visible associated labels.
- Створіть text error із назвою поля, problem і suggestion.
- Перевірте keyboard, accessibility tree, browser validation і simulated server-error state.
Лабораторна нічого не надсилає
Client-side constraints потрібні для UX, але не є security boundary. Production backend завжди повторно валідовує й нормалізує дані.
Офіційні джерела
Закріпіть матеріал уроку
Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.