С телефона страница открывается, меню помещается, картинки не вылезают за края. Но покупатель не может нажать кнопку под клавиатурой, закрыть окно с предложением или исправить номер, не потеряв заполненную форму. В отчёте адаптивности всё может выглядеть благополучно, а заказ или заявка всё равно не доходят до конца.
Мобильное удобство проверяют по целому сценарию: человек ищет товар или услугу, открывает карточку, заполняет форму, отправляет данные и понимает, что произошло. Ширина макета — только начало проверки.
Проверяйте сценарий на телефоне, а не только в эмуляторе
Сначала выберите реальные устройства и браузеры, которыми пользуются ваши клиенты. Для короткой первичной проверки подойдут хотя бы один iPhone с Safari и один Android-телефон с Chrome. Если основная аудитория пользуется другими браузерами или устройствами, включите их тоже. Зафиксируйте модель, версию ОС и браузера: экранная клавиатура, верхняя панель браузера, масштаб текста и поведение полей могут различаться.
Эмулятор помогает увидеть вёрстку при заданной ширине, но не заменяет нажатия пальцем и настоящую экранную клавиатуру. Проверьте портретную и альбомную ориентацию, увеличение текста и масштабирование страницы. Не запрещайте пользователю приближать страницу через user-scalable=no или ограничение maximum-scale: при плохом зрении это может сделать текст и элементы недоступными. Документация MDN отдельно предупреждает, что отключение масштабирования мешает пользователям с нарушениями зрения.
Пройдите путь как обычный посетитель, без входа в административную панель и без заранее заполненных данных браузера. Ищите конкретный товар или услугу; откройте результат; измените вариант, количество или фильтр; добавьте товар в корзину, если она есть; перейдите к форме. Заполните поля, отправьте их и проверьте, что сайт действительно сохранил заказ или заявку. Важен не скриншот страницы, а весь путь до понятного результата.
Найдите места, где интерфейс перекрывает действие
Откройте клавиатуру в каждом поле. Убедитесь, что поле и кнопка отправки остаются видимыми либо до них можно прокрутить страницу. Нижняя фиксированная панель, баннер согласия или липкая шапка могут занять большую часть короткого экрана. Проверьте несколько высот окна: на телефоне видимая область меняется при появлении клавиатуры и панелей браузера. Если кнопка уезжает под клавиатуру, человек не должен гадать, как её открыть или завершить ввод.
Проверьте всплывающие окна и меню. У всплывающего окна должна быть заметная кнопка закрытия. Для модального диалога, который блокирует взаимодействие с остальной страницей, после открытия фокус переводят внутрь, а после закрытия возвращают к элементу, который его открыл. Закройте окно клавишей Escape там, где это применимо, и проверьте поведение с клавиатурой и экранным диктором. На сенсорном экране кнопка закрытия должна быть легко находимой и нажимаемой, а не крошечным крестиком у края.
Прокрутите страницы в обе стороны. В обычном потоке не должно появляться случайного горизонтального скролла из-за таблицы, длинного артикула или широкого блока. При повороте телефона проверьте, не пропадает ли выбранный вариант и остаётся ли доступна основная кнопка. Вернитесь из карточки назад: поиск, фильтры и положение в списке желательно сохранить, чтобы не заставлять посетителя начинать заново. В корзине проверьте, остаются ли выбранные товары и введённые данные после перехода к предыдущему шагу.
Поля должны помогать вводу, а не мешать ему
У каждого поля должна быть видимая подпись, связанная с ним программно через label. Подсказка внутри поля может показать пример, но не должна быть единственным названием: после ввода текста она исчезает. Если поле обязательно, поясните это заранее; ошибки привяжите к полю, сформулируйте словами и не очищайте остальные введённые данные после неудачной отправки.
Для телефона используйте type="tel", а не type="number": номер телефона не является величиной для арифметики, а формат может включать знак плюса, пробелы и скобки. Атрибут inputmode="tel" подсказывает браузеру подходящую клавиатуру, а autocomplete="tel" помогает автозаполнению. Эти подсказки не заменяют серверную проверку. Маска номера должна принимать международный формат и не мешать вставке, редактированию и вводу номера с кодом страны. Проверьте валидные варианты с плюсом, пробелами и скобками, а также неполный номер: сообщение об ошибке должно объяснять, что исправить.
Для адреса электронной почты, имени и иных знакомых данных задайте подходящие type и autocomplete, если они применимы. Не заставляйте человека повторно вводить уже известную информацию без причины. На мобильном устройстве это особенно заметно: каждое лишнее поле означает ещё одно переключение клавиатуры и шанс потерять ход.
Размер кнопки — не единственный критерий
WCAG 2.2, критерий 2.5.8 уровня AA, задаёт минимальную цель 24 на 24 CSS-пикселя либо требует подходящего расстояния между меньшими целями. В критерии есть и другие исключения — например, для встроенных ссылок в тексте, эквивалентной цели и некоторых случаев, когда размер определяется пользовательским агентом. Поэтому проверяют не только ширину кнопки, но и применимость исключения, расстояние до соседних элементов и вероятность промахнуться.
44 на 44 CSS-пикселя — требование более строгого критерия WCAG 2.2 2.5.5 уровня AAA для увеличенной цели, также с исключениями. Это не универсальный минимум AA для каждого элемента. Для важных действий — «В корзину», «Продолжить», «Отправить» — крупная область нажатия часто удобнее. Ссылки, крестики, стрелки карусели и переключатели должны иметь достаточное расстояние и визуально понятное состояние нажатия.
Подтверждение должно означать сохранение
После отправки проверьте, что сообщение об успехе появляется только после ответа сервера, подтверждающего сохранение данных. Если сайт показывает «Спасибо» сразу по нажатию, не дожидаясь результата, посетитель может уйти с ощущением завершённого заказа, которого ещё нет. При ошибке оставьте введённые значения и покажите, что можно сделать дальше: проверить формат, повторить отправку или выбрать другой канал связи.
Проверьте также повторное нажатие и медленное соединение. Кнопка должна показывать, что запрос выполняется. Одной блокировки кнопки мало: серверная обработка также должна защищать от дублей при повторной отправке. Если сервер не ответил, честно сообщите, что статус отправки неизвестен, и предложите безопасный следующий шаг. Для заказа полезно показать номер или состав после того, как запись подтверждена сервером; для заявки — ясное подтверждение, что обращение принято.
Скорость загрузки влияет на то, как быстро человек может начать сценарий, но хорошая оценка скорости сама по себе не доказывает удобство. Проверьте, можно ли читать и нажимать элементы, пока догружаются изображения и виджеты. Не перекрывают ли форму чаты, акции и уведомления. Особенно внимательно смотрите на первый экран карточки и корзины: не заставляйте ждать декоративные элементы, прежде чем станет доступно действие.
Короткий чек-лист проверки
- Пройти поиск, карточку, форму и подтверждение на реальных iPhone/Safari и Android/Chrome из вашей аудитории.
- Повторить путь в портретной и альбомной ориентации, с увеличенным текстом и системным масштабированием.
- Открыть клавиатуру в каждом поле и проверить доступность кнопки отправки.
- Убедиться, что шапка, баннеры и всплывающие окна не закрывают содержание или элементы управления.
- Проверить подписи полей, автозаполнение, телефон с международным кодом и сохранение введённых данных при ошибке.
- Проверить фильтры, возврат назад, состояние корзины и отсутствие случайной горизонтальной прокрутки.
- Подтвердить, что сообщение об успехе появляется после ответа о сохранении на сервере.
Если на сайте уже теряются обращения, проверьте также техническую цепочку: как найти место, где заявки не доходят до почты или CRM. А регулярную проверку пользовательских сценариев можно включить в регламент техподдержки сайта.
Источники
- W3C WAI: WCAG 2.2, критерий 2.5.8 «Размер цели (минимум)»
- W3C WAI: WCAG 2.2, критерий 2.5.5 «Увеличенный размер цели»
- MDN: настройка viewport и масштабирование
- MDN: атрибут inputmode
- web.dev: рекомендации по формам оплаты и адреса
Что можно проверить вместе с SolverWeb
Если с телефона трудно найти товар, заполнить форму или понять, сохранился ли заказ, мы проверим сценарий на реальных устройствах и браузерах, разберём перекрытия и ошибки формы, затем предложим конкретные доработки. Для проверки отправки сверим ответ сервера с фактически сохранённой записью.
Обсуждение
Поделитесь мнением — первый комментарий задаст тон.