1. Выберите задачу страницы до выбора её компоновки
Начните со страниц, выполняющих клиентскую или бизнес-задачу: сервисные страницы, страницы товаров, формы лидов, бронирование, вход в аккаунт, корзина и справка. Напишите одно утверждение о завершении для каждой, например: «Новый посетитель может понять эту услугу, увидеть релевантные доказательства и запросить звонок.» Если у страницы более одной задачи, решите, какая показывается первой.
Перечислите её содержимое как существенное, вспомогательное или опциональное. Существенное не значит краткое; посетителю может понадобиться контекст цен, критерии права, детали доставки или информация для сравнения. Обеспечьте для этих материалов понятный путь на узкой компоновке. Google рекомендует эквивалентное первичное содержание на мобильных и десктопных версиях, при этом разрешается иная презентация, например вкладки или аккордеоны.
При узкой ширине коллега должен суметь сказать, что предлагает страница, кому она помогает и какое следующее значимое действие.
2. Сделайте узкую базовую версию полной
Начните с рабочего одноколоночного пути, а не со сжатия десктопной раскладки. Используйте гибкие контейнеры, позволяйте тексту переноситься и добавьте meta-viewport, чтобы браузер подбирал размер компоновки под ширину устройства. Не блокируйте масштабирование. Проверьте, что меню, уведомления, изображения, встраивания и ошибки форм остаются внутри окна просмотра; непреднамеренная двухмерная (горизонтальная) прокрутка страницы обычно является дефектом.
Используйте 320 CSS-пикселей как требовательный чек для переплавки (reflow) обычного читаемого и задачевого контента. WCAG 2.2 описывает требование представления вертикального контента при этой ширине без потери информации или функциональности и без двухмерной прокрутки. Карты, диаграммы или табличные данные могут требовать собственной области прокрутки, но это не оправдывает заставлять окружающую страницу прокручиваться вбок.
Подгоняйте изображения под контейнер и указывайте их размеры, чтобы браузер мог зарезервировать пространство до их загрузки.
3. Добавляйте улучшения, не делая базовый путь хрупким
Принцип прогрессивного улучшения означает, что существенное содержимое и функциональность работают в базовой версии, а более продвинутые браузеры и большие экраны получают дополнения. Адрес, детали продукта, подписи форм, объяснение цены и путь отправки не должны зависеть от анимации, hover или поздних скриптов. Более широкая раскладка может добавить панель сравнения, постоянную навигацию или более тонкую фильтрацию, не делая базу неполной.
Попросите реализацию вставлять breakpoint (точку перелома) тогда, когда содержимое становится тесным или неэффективным, а не потому, что в списке появился конкретный девайс. Breakpoint — это просто место, где меняется правило раскладки. Не используйте узкие макеты, чтобы незаметно убирать подсказки, пункты политики, отзывы, метаданные или важные структурированные детали.
Покажите сначала базовую галерею и описание изображения, затем добавьте зум или свайп-контролы, когда соответствующие скрипты станут доступны.
4. Проектируйте элементы управления для касания, понятности и восстановления
Эргономика касания означает проектирование для рук, а не для точного курсора мыши. Уделите кнопкам, чекбоксам, иконкам закрытия, селекторам количества и вариантам формы достаточный размер и разделение, чтобы снизить количество ошибочных нажатий. Подписывайте иконки, если их смысл не очевиден. Не делайте hover единственным способом показать цену, подменю, пояснение или действие.
WCAG 2.2 включает критерий уровня AA по минимальному размеру целевых областей указателя — не менее 24 на 24 CSS-пикселя с оговорёнными исключениями, включая расстояние между элементами и встроенные ссылки. Рассматривайте это как минимальную отправную точку, а не как гарантию комфорта. Критические действия заслуживают понятных подписей, щедрых отступов и обратимого шага подтверждения. Для высокорисковых путей или формальных заявлений о соответствии привлекайте квалифицированное экспертное аудирование по доступности.
Держите подписи видимыми, показывайте полезную валидационную обратную связь и сохраняйте введённые значения после ошибки.
5. Рассматривайте медиа и встраиваемые компоненты как часть пути посетителя
Решите, является ли каждое изображение информативным, убеждающим или декоративным. Информативное изображение требует соответствующей текстовой альтернативы и кропа для узкой компоновки, сохраняющего необходимую деталь. Опции адаптивных изображений позволяют браузеру выбирать подходящий ресурс, а не заставлять каждого посетителя скачивать самый большой десктопный файл. Не позволяйте hero-изображению или видео скрывать цель страницы и главное действие.
Проведите инвентаризацию карт, чата, видео, платежей, расписаний, согласий и виджетов отзывов. На узком экране проверьте их состояние загрузки, размер элементов управления, ограниченную компоновку и практический запасной маршрут. Для платежей, идентификации или регулируемых потоков данных привлекайте квалифицированных специалистов по безопасности, приватности и соответствию; визуальное тестирование не является оценкой безопасности.
Зафиксируйте каждый внешний компонент, его владельца, его бизнес-функцию и утверждённый запасной вариант на случай медленной загрузки или отказа.
6. Тестируйте пути задач до релиза и планируйте исправления
Используйте режим адаптивности в браузере на ранних этапах, чтобы посмотреть узкие, средние и широкие ширины. Режим устройств в Chrome (Chrome Device Mode) может приближённо эмулировать окно просмотра, касание, ориентацию, сеть и CPU, но Chrome отмечает его как приближение, а не выполнение на реальном устройстве. По возможности выполняйте критические пути на реальных телефонах и в релевантных браузерах.
Тестируйте задачу, а не только снимок экрана: холодная загрузка, навигация, невалидная и валидная отправка форм, смена ориентации, масштабирование и возврат с экрана третьей стороны. Запишите URL, браузер или устройство, задачу, ожидаемый результат, владельца и решение об откате. Для крупных изменений шаблонов, оформления заказа, CMS или зависимостей этапируйте выпуск и подготовьтесь восстановить предыдущий путь, а не импровизировать под давлением.
Утверждайте только после того, как критическая задача работает, элементы управления удобны, отсутствует горизонтальная прокрутка страницы и ключевые зависимости имеют запасной вариант.