Сначала назначение, затем оформление
Заголовок обозначает раздел, ссылка ведёт к другому ресурсу, кнопка выполняет действие. Эти различия нужно выразить средствами HTML, а не только цветом и размером букв. Если обычный текст визуально превратить в кнопку, необходимые способы управления не появятся автоматически. Стандартные элементы уже имеют определённое поведение, которое проще сохранить. Для поля ввода нужна понятная подпись, связанная с полем. Подсказка внутри пустого поля исчезает при наборе и не заменяет постоянного объяснения того, что требуется.
Пройдите путь без мыши
Нажатие Tab обычно перемещает фокус между доступными интерактивными элементами. Пользователь должен видеть, где находится этот фокус, и понимать порядок переходов. Для карточки логично сначала прочитать сведения, затем перейти к форме и отправке. Визуальная перестановка блоков с помощью CSS может разойтись с порядком элементов в документе. Проверять нужно оба порядка. Если меню открывается, продумайте также закрытие и возвращение к предыдущему действию. Проверка одной кнопки отдельно не обнаруживает разрывов всего пользовательского пути.
Испытайте макет длинным содержимым
Короткое название удобно помещается почти везде. Реальная проверка начинается с длинного заголовка, нескольких строк подписи и увеличенного текста. Сужайте окно постепенно: проблема может появиться между привычными размерами телефона и ноутбука. Содержимое не должно перекрывать соседние элементы или исчезать из-за фиксированной высоты. Изображению нужны подходящие ограничения размера. При этом не всякое горизонтальное прокручивание является ошибкой: для широкой таблицы иногда предусматривают отдельную область. Решение зависит от смысла содержимого, а не от запрета любого выхода за экран.
Добавьте состояния, которых нет на картинке
Форма существует до ввода, во время отправки, после успеха и после ошибки. Для каждого состояния нужны понятные сообщения и возможность продолжить действие. Если отправка не удалась, полезно сохранить уже введённые данные и объяснить следующий шаг. Ошибку нельзя обозначать исключительно красной рамкой: добавьте текстовое пояснение. Проверка этих ситуаций помогает обнаружить требования, отсутствующие в статичном макете. В рабочей команде их согласуют заранее, а готовность страницы описывают через воспроизводимое поведение.
Попробуйте на практике
Составьте проверку карточки вымышленного городского мастерского занятия. Достаточно бумаги; при наличии собственной учебной страницы можно проверить её в браузере.
- Нарисуйте название, описание, поле имени и кнопку отправки. Подпишите назначение каждого элемента и ожидаемое действие.
- Пронумеруйте переходы между интерактивными элементами. Укажите, как пользователь узнает, какой элемент выбран сейчас.
- Замените название предложением из пятнадцати слов, а подпись поля двумя строками. Нарисуйте узкий вариант без обрезанного текста.
- Опишите три результата отправки: ожидание, успех и ошибку соединения. Для ошибки сохраните введённое имя и предусмотрите повтор.
- Запишите пять отдельных проверок с ожидаемым результатом. Если есть учебная реализация, выполните их и отметьте обнаруженные расхождения.
Как проверить результат. План охватывает смысл элементов, порядок управления, узкую ширину, длинное содержимое и ошибку отправки. Каждый пункт описывает наблюдаемое поведение, по которому другой человек сможет проверить результат.
Частые вопросы
Нужно ли сразу добавлять JavaScript?
Только когда требуется поведение, которого нет у выбранных стандартных элементов. Сначала полезно проверить возможности HTML и CSS, затем усложнять реализацию по конкретной задаче.
Достаточно ли автоматической проверки доступности?
Она помогает находить часть ошибок, но не устанавливает понятность всего сценария. Ручной проход с клавиатурой и проверка содержимого дополняют автоматические результаты.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.