Редакция Romanov Lab · Обновлено
Аккуратный скриншот мобильной версии ещё не показывает, можно ли пользоваться сайтом. Меню может перестать закрываться после поворота телефона, клавиатура перекрыть кнопку, а длинный адрес электронной почты растянуть карточку. Проверка адаптивности должна включать содержимое, состояния и действия посетителя, а не только несколько заранее выбранных ширин.
Перед началом соберите перечень шаблонов и основных сценариев. Для сайта услуг это обычно выбор направления, чтение условий и обращение. Для каталога добавляются фильтры и карточки. Часть требований полезно определить ещё в брифе на разработку, чтобы итоговая проверка не стала первым обсуждением мобильной версии.
Составьте разумную матрицу проверки
Выберите браузеры и устройства по аудитории сайта, если такие сведения уже есть. Для нового проекта зафиксируйте предполагаемый набор и пересмотрите его после накопления данных. MDN рекомендует согласовывать поддерживаемые платформы и по возможности проверять сайт на реальных устройствах. Эмуляция в браузере ускоряет поиск ошибок, но не воспроизводит все особенности телефона.
В матрице укажите браузер, операционную систему, ширину окна, ориентацию и способ ввода. Не ограничивайтесь названиями моделей устройств. Настольный браузер тоже может быть открыт в узком окне. Протестируйте промежуточные ширины около точек перестроения: дефект часто живёт между двумя красивыми макетами.
Сначала проверьте целостность страницы
- У страницы нет случайной горизонтальной прокрутки из-за заголовка, изображения, таблицы или широкого декоративного элемента.
- Основные блоки читаются в логичном порядке после перехода из нескольких колонок в одну.
- Текст не обрезается фиксированной высотой карточки и не исчезает за кнопкой.
- Ключевые условия услуги доступны на небольшом экране, включая примечания и ограничения.
- Фиксированная шапка и нижняя панель не закрывают содержимое и элементы управления.
- Страница сохраняет рабочее состояние после изменения ширины и ориентации.
Для настоящей таблицы допустима отдельная прокручиваемая область, если двумерное представление необходимо для смысла. Но это не повод делать всю страницу шире экрана. Ориентир WCAG Reflow требует сохранения информации и функций при ширине, эквивалентной 320 CSS-пикселям, с оговорёнными исключениями для содержимого, которому необходимы два измерения.
Пройдите навигацию и интерактивные состояния
Откройте и закройте мобильное меню несколько раз, перейдите по вложенному пункту и вернитесь назад. Проверьте, сохраняется ли нормальная прокрутка страницы после закрытия подложки. Если в меню есть длинные подписи, они не должны перекрывать соседние элементы или скрывать кнопку закрытия.
Карусели, вкладки, фильтры и раскрывающиеся блоки проверяют отдельно. Действия, доступные при наведении мыши, должны иметь понятный способ выполнения на сенсорном экране. Не переносите автоматически настольное поведение на телефон. Убедитесь, что после фильтрации пользователь видит изменение результата, а после перехода назад может продолжить работу.
Проверьте форму с экранной клавиатурой
Заполните форму на реальном телефоне. Важно увидеть, куда сдвигается экран, когда появляется клавиатура, остаются ли видимыми подпись и ошибка текущего поля, можно ли перейти к следующему вводу. Откройте длинный список, вставьте значение из буфера и используйте автозаполнение.
Затем отправьте неправильные и правильные тестовые данные. Проверьте состояние загрузки, повторное нажатие и результат. Если подтверждение появляется далеко за пределами видимой области, человеку может казаться, что ничего не произошло. Детальную проверку формы удобно связать с рекомендациями по обработке заявки.
Используйте неудобный, но реалистичный контент
Короткие демонстрационные тексты скрывают проблемы. Подставьте длинное название услуги, несколько абзацев, список, подпись к фотографии и адрес без удобных мест переноса. Проверьте карточку без изображения и карточку с вертикальным снимком. Ошибки шаблона лучше обнаружить до того, как редактор опубликует настоящий материал.
Отдельно увеличьте масштаб и размер текста. Не блокируйте масштабирование ради сохранения композиции. MDN описывает настройку viewport для соответствия ширины страницы экрану устройства, однако сам этот тег ещё не делает интерфейс адаптивным. Поведение определяется всей вёрсткой и содержимым.
Посмотрите на загрузку и переходы
Откройте страницу с ограниченной скоростью сети и холодным кешем. Наблюдайте, не перемещается ли нужная кнопка при появлении шрифта или изображения, понятно ли ожидание и можно ли пользоваться уже загруженной частью. Это дополняет измерения производительности, но не заменяет их.
Проверьте вход по прямой ссылке на внутреннюю страницу. Пользователь не обязан начинать с главной, а часть проблем проявляется только после обновления адреса или возврата назад. Важны также ссылки на телефон, почту, документы и внешние сервисы: для каждой нужен предсказуемый результат на мобильном устройстве.
Соберите тестовый набор содержимого
Для проверки одной страницы подготовьте несколько вариантов данных. Первый — обычный материал, второй — длинный, третий — неполный. У услуги могут быть короткое название и название из нескольких строк; у статьи — фотография и отсутствие фотографии; у списка — один элемент и много элементов. Цель не в том, чтобы выдержать бессмысленную строку на тысячи знаков, а в том, чтобы выдержать то, что редактор действительно может опубликовать.
Полезный набор: длинный адрес электронной почты, название организации, цена с пояснением, несколько кнопок, список документов, таблица характеристик и изображение с подписью. Проверяйте вместе, а не по отдельности. Длинная подпись может сместить кнопку внутри карточки, а ряд из трёх таких карточек обнаружит проблему, которую одиночный компонент не показывает.
Выбирайте точки перестроения по содержимому
Если меню перестаёт помещаться при определённой ширине, нет смысла ждать условной границы «планшета». Найдите ширину, на которой начинает ломаться именно этот компонент, и проверьте несколько соседних значений. Подход MDN к адаптивному дизайну опирается на гибкую компоновку и медиазапросы; конкретные границы должны соответствовать содержимому проекта. Названия популярных устройств удобны для организации тестов, но не определяют все возможные размеры окон.
Учебный пример: три карточки услуг помещаются на широком экране, но при сужении описание превращается в слишком узкую колонку. Сначала команда уменьшает число колонок, затем оценивает длину строк, ширину кнопок и расстояние между карточками. Если карточки содержат разные объёмы текста, фиксировать одинаковую высоту любой ценой опасно: текст может обрезаться. Лучше определить, какие части должны выравниваться, а где допустима естественная высота.
Проверка должна идти в обе стороны: от широкого окна к узкому и обратно. Некоторые дефекты проявляются только после изменения состояния. Например, закрытое на телефоне меню остаётся скрытым при возвращении к широкой версии, потому что его состояние управляется одновременно стилями и скриптом. Скриншот при первоначальном открытии широкого окна такой дефект не обнаружит.
Разберите мобильный сценарий от входа до результата
Возьмём учебную заявку на услугу. Пользователь приходит по прямой ссылке, раскрывает условия, открывает форму и вводит контакт. Важно проверить цепочку целиком: фиксированная кнопка может быть удобной в начале, но перекрывать последнюю строку условий или сообщение об ошибке после появления клавиатуры.
- Открыть внутреннюю страницу с холодной загрузкой и дождаться появления основных блоков.
- Прокрутить до условий, раскрыть подробности и убедиться, что текст не обрезан контейнером.
- Открыть форму, затем повернуть устройство и проверить сохранность введённых значений.
- Ввести данные с клавиатуры, вставить часть из буфера и проверить автозаполнение.
- Отправить форму с пропущенным обязательным полем: ошибка и путь к исправлению должны оставаться доступными.
- Исправить значение, получить подтверждение и вернуться назад без непредсказуемой повторной отправки.
Для тестирования используйте согласованный стенд или специальный тестовый маршрут. Не создавайте десятки реальных обращений менеджеру только ради проверки размеров экрана. Если другой среды нет, заранее согласуйте маркировку тестовых записей и их обработку.
Отличайте переполнение от допустимой прокрутки
Горизонтальное движение всей страницы часто означает, что один элемент не смог сжаться. Проверьте длинные слова, минимальную ширину дочерних блоков, фиксированные размеры, внешние виджеты и изображения. Скрыть переполнение у всего документа — соблазнительный способ убрать полосу прокрутки, но он способен просто спрятать полезный текст и элементы управления.
Для таблицы с реальными связями по строкам и столбцам отдельная прокрутка может быть оправдана. При этом пользователь должен понимать, что таблицу можно сдвинуть, а заголовки и данные — оставаться связаны по смыслу. Альтернатива в виде карточек подходит не всегда: если человеку нужно сравнивать множество значений по столбцу, такая перестройка может усложнить задачу. Решение проверяют на конкретном содержимом, учитывая оговорки WCAG Reflow.
Используйте эмуляцию и телефон для разных вопросов
В эмуляции удобно быстро искать проблемную ширину, проверять множество шаблонов и воспроизводить состояние сети. Реальный телефон нужен, чтобы оценить экранную клавиатуру, жесты, взаимодействие с системными приложениями и поведение элементов браузера. Эти способы дополняют друг друга. Если реального устройства для определённой платформы нет, отметьте пробел в покрытии, а не записывайте платформу как успешно проверенную.
Рядом с каждой проверкой храните состояние: пройдено, найден дефект, не проверено, неприменимо. Не объединяйте последние два варианта: «не проверено» означает неизвестный результат. Повторный тест после исправления проводят в исходных условиях и на соседнем размере окна. Если изменён общий шаблон карточки, полезно проверить и услуги, и статьи, использующие его.
Короткий протокол для передачи разработчику
Пример записи: «Страница услуги, узкое окно, меню открыто. После перехода к широкой версии пункты не появляются; обновление страницы восстанавливает меню. Ожидается доступная навигация без перезагрузки. Повторяется после закрытия меню на узком экране». Такая запись показывает последовательность действий и помогает найти причину. Снимок широкой пустой шапки без предыстории этого не объясняет.
Приёмку адаптивности завершает перечень сценариев и условий, а не набор одобренных картинок. Если после запуска добавился новый блок или сторонний виджет, повторите затронутые сценарии: исходная проверка не распространяется автоматически на изменённый интерфейс.
Оформите результат, который можно исправить
- Запишите адрес и состояние страницы, устройство, браузер и размер окна.
- Опишите краткие шаги воспроизведения и ожидаемое поведение.
- Приложите снимок или короткую запись с областью проблемы.
- Укажите влияние: блокирует задачу, мешает чтению или касается только оформления.
- После исправления повторите проверку на соседних ширинах и связанных шаблонах.
Перед запуском должен остаться понятный список проверенного и известных ограничений. Согласованная матрица помогает повторять тест после новых блоков, обновлений и публикаций. При создании сайта такую проверку разумно включать в каждый готовый шаблон, чтобы финальная приёмка подтверждала качество, а не начинала поиск основных ошибок.
Источники
MDN: проверка в разных браузерах; MDN: viewport; W3C: Reflow.
Нужен план для вашего проекта? Напишите нам в Telegram или по электронной почте. Обсудим разработку, продвижение или поддержку сайта.
