ворд-пресс.рф
Решение

Мобильный UX и доступность MVP: чек-лист перед разработкой

Проверка мобильных интерфейсов и доступности форм, кнопок, навигации, ошибок и контраста без фиктивной оценки качества.

Адаптивная вёрстка — не просто отсутствие горизонтального скролла. У пользователя должны оставаться доступными основное действие, содержимое и способ исправить ошибку. Этот чек-лист подходит для прототипа и первых WordPress-экранов, но не заменяет полноценный аудит WCAG.

1. Проверка на узком экране

Посмотрите 320, 375 и 430 px, затем планшет и десктоп. Убедитесь, что главное действие доступно без угадывания, кнопки не «сжимаются», длинный код можно прокручивать внутри блока, а меню не блокирует содержимое. Проверяйте реальные тексты на русском, включая длинные названия ошибок.

На странице с таблицей решите явно: горизонтальная прокрутка с указателем или карточный список. Не прячьте важные столбцы без альтернативы.

2. Проверка с клавиатуры

Пройдите страницу через Tab, Shift+Tab, Enter, Space и Escape там, где есть диалог. Порядок фокуса должен соответствовать логике чтения. Фокус заметен, модальное окно закрывается и возвращает управление к инициатору, кнопки не маскируются под ссылки и наоборот.

У мобильного меню не должно быть «ловушки»: закрыв его, пользователь снова получает доступ к странице.

3. Формы, статусы и сообщения

У каждого поля есть видимая подпись; обязательные поля помечены; ошибка связана с конкретным полем и объясняет исправление; введённое не теряется. После отправки результата пользователь понимает, сохранилась ли операция, а при сетевом сбое получает безопасный вариант повторить её.

Состояние не обозначается только цветом. Например, рядом с красной рамкой появится текст «Неверный формат файла».

4. Содержательные изображения и медиа

Информативному изображению нужен alt по смыслу. Чисто декоративные изображения можно не создавать вовсе. У видео, необходимых для прохождения шага, потребуются доступные текстовые альтернативы. Проверяйте структуру заголовков начиная с H1 страницы, без повторного H1 в содержимом.

Официальный ресурс W3C Easy Checks помогает сделать первую проверку. Автоматический отчёт Lighthouse полезен для поиска типовых проблем, но не гарантирует доступность.

Практический протокол проверки

## MOBILE-A11Y-CHECK
- Проверенная страница и версия:
- Устройство/ширина:
- Главный сценарий выполнен: да/нет
- Клавиатура и фокус:
- Формы и сообщения ошибок:
- Контраст и читаемость:
- Проблемы с переносом текста:
- Альтернативы медиа:
- Блокирующие проблемы:
- Исправление и повторная проверка:

Когда двигаться дальше

Основное действие можно выполнить на телефоне и с клавиатуры, блокирующие проблемы зафиксированы. Проверку повторяют после изменений, а не отмечают выполненной только из-за успешного запуска Lighthouse.

Источник: https://www.w3.org/WAI/test-evaluate/easy-checks/

Материал был полезен?

Помогите нам сделать материалы точнее и понятнее.