Постройте охват вокруг пользовательских задач
Перечислите маршруты и результат, которые создают ценность: поиск сервиса, поиск по сайту, добавление товара, бронирование, вход, обращение за помощью или оплата. Для каждого укажите компоненты, которые могут менять форму или давать сбой: навигация, фильтры, карточки, таблицы, изображения, баннеры, формы, выезжающие панели (drawers) и встроенные виджеты. Тестируйте ширины, при которых ваш контент начинает сужаться, а не просто каталог текущих моделей телефонов. Тестируйте чуть ниже, на и чуть выше каждой точки перехода (breakpoint).
Включите узкие и телефоно-подобные средние ширины, ширину, похожую на планшет, ноутбук, широкий десктоп и ландшафтную ориентацию, когда она меняет задачу.
Используйте длинные заголовки, пустые результаты, ошибки валидации, бейджи цен, полные адреса и более длинные метки, когда такие состояния существуют.
Докажите перерасстановку, читаемость и масштабирование
Подтвердите, что на странице корректно задан viewport, затем проверьте наличие горизонтальной прокрутки страницы. Фиксированные изображения, широкие поля ввода, отрицательные отступы, off-canvas панели и баннеры — типичные причины. Критерий Reflow в WCAG 2.1 описывает вертикально скроллируемый контент при ширине, эквивалентной 320 CSS-пикселей, включая viewport 1280 пикселей при 400% зуме. Если этот критерий в области оценки, протестируйте реальную ситуацию с масштабированием. Карта, видео или таблица данных могут требовать двумерной раскладки, но сохраняйте прокрутку внутри компонента и позволяйте окружающей странице перестраиваться.
Проверьте хэдеры, основное содержимое, футер, закреплённые панели, диалоги и сводки ошибок на каждой проверяемой границе.
Реорганизуйте информацию для узкого экрана; не удаляйте молча требование, деталь цены или путь к поддержке.
Нагружайте контент и формы
Операции с контентом могут вызвать адаптивные сбои без CSS-релиза. Тестируйте самый длинный утверждённый заголовок, несколько бейджей, отсутствие изображения, выбранный фильтр, большое юридическое уведомление и заполненное браузером поле. Когда колонки складываются, убедитесь, что порядок чтения и клавиатурный порядок остаются логичными. Завершите реальную форму на маленьком устройстве: откройте контролы, исправьте ошибку и отправьте. Тестируйте сторонние виджеты на странице, приближённой к продакшену, потому что их контейнер, состояние согласия, шрифты и стили могут изменить результат.
Отражайте вероятные максимальные длины и комбинации, но не включайте данные клиентов или платёжную информацию в доказательства QA.
Откройте уведомления, чат, акции и сообщения валидации одновременно; ничего не должно закрывать основное действие или сфокусированное поле.
Пропроверяйте все пути ввода
Большой экран не гарантирует мышь, а маленький экран не гарантирует только touch. Медиa-фича hover (hover media feature) проверяет, может ли основной ввод удобно наводить указатель, поэтому hover должен дополнять, а не быть единственным способом доступа к действию или объяснению. Тестируйте клавиатуру и указатель на десктопе, тап и прокрутку на сенсорном устройстве и смешанные способы ввода там, где это релевантно. Проверьте компактные кнопки закрытия, степперы, чипы, календари и иконные действия. Критерий Target Size (Minimum) в WCAG 2.2 задаёт целевой размер 24 на 24 CSS-пикселя с определёнными исключениями, включая отступы и встроенные ссылки. Это критерий с областью применения и исключениями, а не обещание, что каждый 24-пиксельный контрол одинаково удобен для всех.
Переберите вкладки (Tab) по странице. Фокус должен оставаться видимым, следовать осмысленному порядку и входить и выходить из меню и диалогов предсказуемо.
Сделайте важное раскрытие на hover доступным через фокус, тап или видимый контрол и предотвратите сбивающее поведение при первом тапе.
Проверяйте ресурсы и производительность в ограниченных условиях
Изображение может поместиться в контейнер, но при этом быть неподходящим файлом для устройства. Проверьте, что медиа сохраняет размер контейнера, резервирует место под макет, сохраняет полезную область обрезки и запрашивает подходящие кандидаты. Srcset и sizes дают браузеру информацию для выбора среди поставленных источников изображений; они не гарантируют конкретный запрос. Используйте троттлинг в DevTools, чтобы выявить проблемы на раннем этапе, но его контролы CPU и сети симулируют условия относительно компьютера разработки. Повторно проверьте ключевые пути на реальном устройстве и соединении. Проинспектируйте шрифты, медиа-хиро, карусели, клиентскую логику и скрипты третьих сторон на предмет задержек, сдвигов или блокируемых тапов.
Зафиксируйте маршрут, viewport, реальное или симулированное соединение и то, что стало медленным или нестабильным; сравнивайте сопоставимые условия.
Где безопасно, отложите ненужные встраивания в тестовой сборке, чтобы понять, остается ли основная задача пригодной для использования.
Устраняйте как проактивную работу по поддержанию доступности (uptime)
Для Status Is UP готовность к адаптивности — это проактивная оптимизация доступности: выявите путь, блокирующий пользователя на устройстве, исправьте причину, подтвердите исправление и предотвратите повторение. Это не утверждение, что мониторинг может оценить каждый дефект макета или взаимодействия. Приоритизируйте по влиянию на задачу и охвату. Перед деплоем протестируйте прилегающие ширины и изменённый путь на реальном оборудовании. Запланируйте откат для изменений в общей навигации, стилях, скриптах, платёжных или интеграционных частях. После релиза повторите шаги проверки и прикрепите доказательства к записи о изменении.
Указывайте маршрут, устройство или viewport, ориентацию, ввод, состояние, ожидаемый результат, фактический результат и редактированный снимок (redacted capture).
Предпочитайте исправление в компоненте, правиле макета, токене или доставке изображений вместо переопределения только для маршрута; дайте исключения владельца и план удаления.