Как проверить сайт на телефоне: меню, формы и ширина страницы

Проверяйте сайт на телефоне: пройдите меню, заполните тестовую форму и найдите блоки шире экрана. Эмуляция в браузере помогает, но не заменяет устройство.

Что должно получиться

После проверки у вас будет список воспроизводимых проблем, а не впечатление «на мобильном неудобно». Для каждой проблемы нужны адрес страницы, устройство, браузер, действие и наблюдаемый результат. Так разработчик сможет повторить ситуацию, а вы — убедиться, что исправление помогло.

Рабочая мобильная страница позволяет пройти нужный путь без борьбы с интерфейсом: найти раздел, прочитать условия, выбрать вариант, заполнить поля и понять результат. Красивая первая часть экрана не подтверждает, что человек сможет закончить действие ниже по странице.

Начните с задач посетителя. Для сайта услуг это может быть просмотр описания и отправка сообщения; для каталога — поиск товара и выбор характеристик. Не совершайте настоящую покупку или оплату ради проверки внешнего вида. Такие действия требуют отдельного согласованного сценария и тестового окружения.

Из чего это складывается

Выберите небольшой, но осмысленный набор страниц

Включите главную, страницу с длинным текстом, типовую карточку и страницу с формой. Если есть личный кабинет, проверьте его отдельно тестовой учётной записью. Разные типы страниц могут использовать разные шаблоны; удачная проверка главной не распространяется автоматически на остальные.

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

Как это сделать по шагам

1. Определите сценарии и границы. Запишите, что посетитель должен сделать. Отделите просмотр интерфейса от отправки сообщений, создания записей и других действий с последствиями.
2. Подготовьте безопасную проверку. Для форм и кабинета используйте согласованное тестовое окружение и тестового получателя. На рабочем сайте не создавайте поток пробных обращений без договорённости.
3. Откройте сайт на реальном телефоне. Запишите модель устройства, систему и браузер. Проверьте портретное положение и поворот экрана, если сценарий не требует определённой ориентации.
4. Пройдите навигацию от начала до конца. Откройте меню, перейдите во вложенный раздел, вернитесь назад и проверьте, что состояние страницы понятно.
5. Проверьте содержание и управление. Прокрутите страницу, увеличьте текст, откройте раскрывающиеся блоки. Найдите элементы, которые обрезаны, перекрыты или требуют слишком точного касания.
6. Проверьте форму в тестовом сценарии. Заполните поля, исправьте ошибку, уберите клавиатуру и завершите действие. Убедитесь, что результат понятен и данные дошли до согласованного получателя.
7. Сопоставьте результат с эмуляцией. В инструментах браузера на компьютере изменяйте ширину плавно. Используйте это для поиска границы поломки, затем повторите проверку на устройстве.
8. Оформите и перепроверьте замечания. Передайте точные шаги, снимки без личных данных и ожидаемое поведение. После исправления повторите тот же путь и соседние действия.

Проверьте ширину страницы

Медленно прокрутите страницу и попробуйте сдвинуть её вбок. Если вместе с содержанием уезжает вся страница, найдите участок, который выходит за границы. Частые кандидаты — таблица, длинная непрерывная строка, изображение с жёсткой шириной и блок, который рассчитан на широкий экран.

Само наличие горизонтального движения ещё не объясняет причину. Таблица или карта иногда нуждается в отдельной области прокрутки, чтобы сохранить смысл. Это отличается от ситуации, когда из-за одного блока вбок движутся заголовок, основной текст и кнопки всей страницы.

В рекомендациях W3C по перестроению содержимого есть отдельная оговорка для частей, которым необходимо двумерное представление. Поэтому не превращайте замечание «есть горизонтальная прокрутка» в требование без разбора убрать её везде. Опишите, какая информация недоступна и мешает ли область пользоваться остальной страницей.

Проверьте масштаб, а не только размеры макета

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

Если мобильная версия выглядит как уменьшенная широкая страница, разработчику стоит проверить настройку viewport в документе. Она задаёт браузеру ориентир для области отображения, но сама по себе не делает блоки гибкими. Даже правильная настройка не исправит фиксированную ширину таблицы или неудачное расположение элементов.

Пройдите меню пальцем

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

Обратите внимание на соседние цели касания. Если вместо нужной ссылки регулярно открывается другая, зафиксируйте место и действие. Не нужно придумывать универсальный размер кнопок для всех интерфейсов: сначала покажите воспроизводимую проблему и проверьте применимые требования доступности.

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

Проверьте форму с открытой клавиатурой

Сначала выберите поле в верхней части формы, затем поле ближе к концу. Убедитесь, что видно место ввода, подпись и сообщение об ошибке. Клавиатура меняет доступную область экрана, поэтому форма может ломаться только во время ввода, хотя до касания выглядит правильно.

Введите заведомо неподходящее тестовое значение там, где формат ограничен, затем исправьте его. Проверьте, понятно ли объяснение и сохраняются ли остальные уже введённые данные. Не используйте реальные чужие телефоны или адреса: при успешной отправке они могут попасть в уведомления и внешние системы.

После согласованной тестовой отправки проверьте обе стороны: что увидел посетитель и что получил адресат. Отсутствие видимой ошибки не доказывает доставку сообщения. Если проверка проводится только до отправки, так и отметьте в отчёте — этот участок пути ещё не подтверждён.

Закреплённые панели и окна

Проверьте страницу после появления уведомлений, согласий и плавающих панелей. Они могут по отдельности занимать немного места, но вместе закрывать поле или кнопку. Особенно полезно повторить путь после поворота экрана и с открытой клавиатурой.

У модального окна должны оставаться понятный способ закрытия и доступ к необходимым элементам. Если содержимое длиннее экрана, проверьте его прокрутку. Снимок первого состояния не показывает, можно ли добраться до последнего действия внутри окна.

Частые ошибки

• Тестировать только сужением окна компьютера. Это помогает искать проблемы ширины, но не воспроизводит всё поведение сенсорного устройства.
• Считать один телефон проверкой всех устройств. Запишите охват и ограничения; при необходимости добавьте другие используемые посетителями платформы.
• Оценивать только первый экран. Основная форма, таблица и заключительная кнопка могут находиться значительно ниже.
• Отправлять пробные сообщения без согласования. Они создают лишние записи и могут запускать настоящие уведомления.
• Закрывать замечание после изменения CSS. Исправление подтверждается повторением сценария, а не фактом редактирования файла.
• Смешивать проблемы отображения и загрузки. Задержку появления блока и неправильную ширину полезно описывать отдельно.

Как проверить

• Проверены несколько типов страниц, а не только главная.
• Основной путь пройден на настоящем устройстве.
• Меню открывается, позволяет перейти в раздел и закрывается.
• Текст читается после увеличения, важные элементы не исчезают.
• Проблемные широкие блоки описаны отдельно от нормальной прокрутки таблиц и карт.
• Форма проверена с клавиатурой и исправлением ошибки в согласованном окружении.
• У каждого замечания есть адрес, условия, шаги и ожидаемый результат.
• После исправления повторены исходный сценарий и соседние действия.

Сохраните в отчёте и ограничения проверки. Например: просмотр и заполнение проверены на телефоне, фактическая отправка — только на тестовом сайте. Такая точность помогает принять работу по понятным условиям и не выдавать частичную проверку за полную.

О пределах эмуляции рассказывает документация Chrome, о перестроении содержимого — пояснение W3C, о настройке области отображения — справочник MDN. Для продолжения используйте проверку формы обратной связи, измерение скорости сайта и различие UI и UX. Исправления можно обсудить с исполнителем через раздел «Разработка».

Вопросы и ответы

Можно ли ограничиться эмуляцией телефона в браузере?

Эмуляция полезна для предварительной проверки и поиска проблемных размеров. Она не заменяет настоящее устройство: работа клавиатуры, касания и другие особенности могут отличаться. Ключевой путь повторите на телефоне.

Сколько телефонов нужно для проверки?

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

Горизонтальная прокрутка всегда считается ошибкой?

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

Почему форма ломается только при вводе?

Открытая клавиатура меняет видимую область экрана. Закреплённые блоки, окна и поля могут перекрывать друг друга именно в этом состоянии. Передайте разработчику шаги с указанием активного поля и ориентации устройства.

Нужно ли запрещать увеличение страницы?

Не используйте запрет увеличения как исправление вёрстки. Пользователю может быть нужен крупный текст. Лучше проверить, какие блоки перестают помещаться, и устранить причину потери содержания или управления.

Как проверить отправку, не засоряя рабочую систему?

Согласуйте тестовый сайт, получателя и способ учёта пробных записей. Если такого режима нет, ограничьте текущую проверку интерфейсом и отдельно договоритесь о полноценной отправке. Не создавайте реальные обращения самовольно.

Что приложить к замечанию разработчику?

Укажите адрес, устройство, браузер, ориентацию, точные действия и ожидаемый результат. Добавьте снимок или короткую запись экрана без личных данных. После правки повторите эти же действия, чтобы подтвердить результат.