Как проверить мобильную версию сайта, сделанного ИИ

Пошаговая проверка адаптивности сайта: ширины экрана, формы, модальные окна, клавиатурный фокус, доступность, реальный телефон и один полезный тест Playwright.

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

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

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

Иллюстрации в статье условные: они объясняют порядок проверки и не изображают реальные результаты тестов.

Responsive design — это не отдельная «мобильная копия» и не набор картинок для нескольких моделей. Компоновка должна подстраиваться под доступное пространство и возможности устройства: колонки собираются в одну, навигация меняет форму, текст остаётся читаемым, а основное действие не исчезает за краем.

Проверьте HTML страницы. В секции head должна быть настройка viewport вида <meta name="viewport" content="width=device-width, initial-scale=1">. Без неё мобильный браузер может отрисовать страницу в виртуальной ширине и затем уменьшить её целиком. Не отключайте пользовательское масштабирование через user-scalable=no и не ограничивайте его без веской причины: увеличение страницы остаётся важным способом чтения.

WCAG 2.2 Reflow даёт полезную измеримую точку: при ширине, эквивалентной 320 CSS-пикселям, информация и функции обычного вертикально прокручиваемого содержимого должны сохраняться без прокрутки сразу в двух направлениях. Это не запрет на любые широкие элементы. Таблицам, картам и диаграммам двумерное расположение иногда необходимо; тогда ограничьте горизонтальную прокрутку их собственным контейнером, а не всей страницей.

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

1. 320 CSS-пикселей — проверка reflow и самого узкого рабочего состояния;
2. обычный мобильный viewport, например около 390 пикселей;
3. промежуточная ширина планшета;
4. широкий экран ноутбука или настольного компьютера.

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

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

Откройте страницу в Chrome, запустите DevTools и включите Device Toolbar. Выберите режим Responsive, а не ограничивайтесь одним профилем телефона.

1. Установите ширину 320 CSS-пикселей.
2. Медленно растягивайте viewport до планшетной и широкой версии.
3. Следите, не появляется ли горизонтальная прокрутка всей страницы.
4. Проверьте портретную и альбомную ориентацию.
5. Включите touch-эмуляцию и попробуйте все управляющие элементы.
6. При необходимости включите ограничение сети и процессора, чтобы увидеть задержки и скачки компоновки.

Chrome прямо предупреждает: Device Mode — приближение первого порядка. Он имитирует viewport, touch-события и часть браузерных параметров, но не превращает компьютер в телефон и не воспроизводит его процессор. Если поведение вызывает сомнение, повторите сценарий на реальном устройстве.

Быстрая диагностика горизонтальной прокрутки

В консоли DevTools сравните document.documentElement.scrollWidth и document.documentElement.clientWidth. Если первое значение больше второго, документ шире viewport. Это сигнал найти виновника, но не готовый диагноз: отдельный контейнер таблицы или карты может прокручиваться горизонтально намеренно.

Обычно проблему создают фиксированная ширина, длинная непрерывная строка, изображение без max-width, позиционированный элемент или отступы, которые не помещаются в доступное пространство. Временно добавляйте outline подозрительным элементам в DevTools и проверяйте их bounding box, не меняя production-код вслепую.

Навигация и возврат

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

Форма и экранная клавиатура

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

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

Модальное окно

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

Длинные данные и увеличение текста

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

Иллюстрация показывает, куда смотреть при проверке. Это условная схема, а не скриншот найденных ошибок.

Минимальный размер цели указателя по WCAG 2.2 SC 2.5.8 — 24 × 24 CSS-пикселя, если не действует нормативное исключение. Среди исключений: достаточный интервал между соседними целями, эквивалентный подходящий элемент управления на той же странице, ссылка внутри строки текста, размер, заданный браузером без изменения автором, а также представление, где конкретный размер необходим или предписан. Поэтому не превращайте число 24 × 24 в механическое требование ко всем ссылкам, но проверяйте маленькие соседние кнопки особенно внимательно.

Для обычного текста WCAG требует контраст не ниже 4,5:1, для крупного — 3:1. Крупным считается примерно текст от 24 CSS-пикселей обычного начертания или от 18,5 CSS-пикселя жирного. Порог не округляют: значение ниже 4,5:1 не проходит как 4,5:1.

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

Включите системную настройку уменьшения движения и проверьте prefers-reduced-motion: reduce. Несущественные переходы и параллакс стоит убрать, сократить или заменить спокойным эффектом. Это не означает запрет любой анимации: цель — избежать движения, без которого задача пользователя не меняется.

Ручной проход ловит визуальные и аппаратные особенности. Автотест нужен для повторяемой проверки того, что основное действие не исчезло после следующего изменения.

Простейший тест строится как «действие → наблюдаемая проверка». Откройте страницу через page.goto(), найдите элемент по роли, нажмите его и проверьте результат через expect: нужный блок видим, URL изменился или текст ошибки появился. Playwright автоматически ждёт, пока элемент станет пригодным для действия, а асинхронные web-first assertions повторяют проверку до результата или тайм-аута. Поэтому не добавляйте произвольные паузы только для того, чтобы тест «успел».

Профиль из devices[...] имитирует user agent, размер экрана, viewport, touch и другие параметры браузерного окружения. Свой viewport можно задать отдельно. Если вы расширяете профиль устройства и переопределяете ширину, объявляйте viewport после ...devices[...], иначе значение из профиля перезапишет вашу настройку.

Сначала проверьте прямые зависимости проекта: npm ls --depth=0 @playwright/test playwright. Ненулевой код может означать, что локальной зависимости нет. Затем проверьте запуск CLI командой npx playwright --help. Важно: при отсутствии локальной зависимости npx может предложить загрузить пакет в npm cache, поэтому эта команда сама по себе не доказывает наличие Playwright в проекте. Список тестов без запуска можно получить через npx playwright test --list, а основной прогон запускается npx playwright test. Для диагностики используйте --headed, --debug или --ui. Команду сборки не угадывайте: возьмите точный script из package.json или документации проекта.

Автотест не доказывает работу экранной клавиатуры и реального touch-стека. Он дополняет, а не заменяет физический телефон.

Страница ездит вправо. Найдите элемент, который шире viewport; проверьте фиксированные размеры, изображения, абсолютное позиционирование и длинные строки. Не скрывайте проблему глобальным overflow-x: hidden, пока не понятна причина: так можно спрятать доступное содержимое.

Кнопка видна, но не нажимается. Проверьте перекрывающий слой, pointer-events, порядок наложения и фактический bounding box. Затем повторите на touch-устройстве.

Клавиатура закрывает отправку. Проверьте высоту модального окна, фиксированные панели и возможность прокрутить активное поле в видимую область. Повторите в Safari и Chrome на доступных физических устройствах.

После поворота всё ломается. Проверьте жёсткие высоты, единицы viewport и состояние открытого меню или модального окна. Сценарий должен продолжаться без потери введённых данных.

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

Страница готова к кандидатной проверке, если:

• корректный meta viewport включён, а масштабирование не отключено;
• при 320 CSS-пикселях обычное содержимое сохраняет смысл и функции без двумерной прокрутки;
• основной сценарий завершается на узком, среднем и широком экране;
• меню, форма, ошибки, модальное окно и Back ведут себя предсказуемо;
• touch-цели, контраст и видимый фокус проверены;
• увеличение текста и уменьшение движения не ломают путь;
• один критический сценарий закреплён автотестом;
• финальный smoke пройден на физическом телефоне.

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

Достаточно ли одного профиля iPhone в DevTools?

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

Нужно ли убирать любую горизонтальную прокрутку?

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

Если разработку ведёт агент, закрепите этот проход в постановке задачи: ширины, сценарий, ожидаемый результат, обязательный physical-device smoke и команда теста. В статье о рабочей связке Codex и Hermes показано, как разделить инженерное изменение, проверку и приёмку результата.

Если хотите продолжить работу с ИИ над своим проектом, посмотрите программу воркшопа «Человек 2.0» Codex + Hermes. В ней есть урок по дизайну сайта. Посмотреть программу воркшопа.

• web.dev — Responsive web design basics: https://web.dev/articles/responsive-web-design-basics
• Chrome Developers — Device Mode: https://developer.chrome.com/docs/devtools/device-mode
• W3C — Understanding Reflow: https://www.w3.org/WAI/WCAG22/Understanding/reflow.html
• W3C — Target Size (Minimum): https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
• W3C — Contrast (Minimum): https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html
• W3C — Focus Visible: https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html
• MDN — prefers-reduced-motion: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion
• Playwright — Writing tests: https://playwright.dev/docs/writing-tests
• Playwright — Emulation: https://playwright.dev/docs/emulation
• Playwright — Command line: https://playwright.dev/docs/test-cli