Сайт может выглядеть аккуратно на первом экране и ломаться после обычного действия: название товара длиннее соседних, посетитель увеличил текст, открыл меню или получил сообщение об ошибке. В таких состояниях важны последствия. Можно ли прочитать условие, выбрать раздел и закончить заявку — или часть интерфейса оказалась за краем экрана?
Проверить это можно без чтения кода. Ниже — последовательность, которая помогает владельцу сайта обнаружить конкретные препятствия и передать разработчику проверяемую задачу. Причина сбоя может находиться в стилях, логике интерфейса или содержимом; по одному снимку нельзя уверенно назначить техническое исправление.
Подготовьте страницы, на которых есть чему ломаться
Не ограничивайтесь главной. Возьмите страницу услуги с длинным заголовком, список карточек, подробную карточку с характеристиками и форму. Если на сайте есть таблица, раскрывающиеся разделы или всплывающее окно, включите их в проверку. Один общий шаблон иногда используется на многих страницах, но разное наполнение проявляет разные дефекты.
Начните с опубликованного содержимого. Для подстановки учебных данных и проверки отправки формы используйте согласованную тестовую копию. Не изменяйте реальные названия и условия ради эксперимента и не отправляйте случайные контакты в рабочую систему заявок.
Записывайте страницу, браузер и его версию, устройство, масштаб и состояние интерфейса. Снимок должен показывать весь проблемный блок; для меню и формы полезна короткая запись действий. Личные сведения в записи скройте.
Сначала проверьте длинные строки и слова
Найдите самые длинные названия, подписи кнопок и характеристики. Смотрите на них в карточке списка и на отдельной странице: ограничения ширины могут различаться. Если реального наполнения пока мало, попросите команду добавить на тестовой копии учебные варианты:
- название из нескольких слов: «Комплект оборудования для автоматизации складского учёта и маркировки товаров»;
- длинное слово без пробелов: «Электроэнцефалографический»;
- длинное обозначение модели: «MODEL-ABCDEFGHIJKLMNOPQRSTUVWXYZ-1234567890».
Это примеры для проверки, а не сведения о товаре. Они выявляют разные проблемы: обычный текст должен переноситься между словами, а непрерывное обозначение требует отдельного решения. Не просите автоматически обрезать всё длинное: для покупателя модель или условие могут быть важнее ровной высоты карточек.
Сузьте окно и наблюдайте, что происходит с блоком. Дефектом будет текст поверх цены, название за границей карточки, подпись под соседней кнопкой или исчезнувшая последняя строка. Важная проверка — сохраняется ли целиком смысл: многоточие в списке допустимо как согласованное решение, если полное название доступно понятным способом. На странице, где человек принимает решение, обрезанное существенное условие нельзя считать исправленным лишь потому, что блок стал ровным.
Критерий исправления: текст и обозначения доступны, не перекрывают соседние элементы и не раздвигают обычную страницу. Карточка может стать выше — одинаковая высота не должна достигаться потерей нужной информации. Как именно переносить непрерывную строку или показывать полное значение, определяет разработчик с учётом её смысла.
Затем увеличьте масштаб, сохранив возможность действовать
В настольном браузере воспользуйтесь его меню масштаба. Начните со 100%, увеличьте до 200%, затем проверьте более крупный масштаб, который поддерживает браузер. На промежуточных значениях тоже могут появляться наложения. Увеличивать сам снимок экрана бесполезно: нужно изменить отображение работающей страницы.
На каждом размере прочитайте длинный заголовок, откройте меню и перейдите к форме. Следите за фиксированными панелями: шапка или нижняя кнопка могут занять большую часть окна и закрыть содержимое. Если кнопка остаётся видимой, но её подпись обрезана, действие всё равно может стать непонятным.
В WCAG 2.2 увеличение текста до 200% рассматривается отдельно от перестроения страницы на узкой ширине. Для обычного вертикально прокручиваемого содержимого ориентир перестроения — 320 CSS-пикселей без потери информации и функций и без необходимости читать строки, двигаясь в двух направлениях. Такая ширина, например, получается из области просмотра 1280 CSS-пикселей при масштабе 400%. Это размеры области браузера, а не паспортное разрешение монитора. Точные условия измерения попросите проверить команду.
Для вашей приёмки полезен простой результат: увеличенный текст можно прочитать, нужные действия доступны, элементы не наложены друг на друга. Переход нескольких колонок в одну или превращение меню в раскрываемую панель сами по себе не являются ошибкой.
Проверьте меню в переходах между состояниями
Пустая закрытая шапка ещё ничего не говорит об открытом меню. Откройте его, раскройте вложенный раздел, найдите последний пункт и закройте панель предусмотренным способом. Повторите это после прокрутки страницы и при увеличенном масштабе.
Дальше меняйте ширину окна, пока меню открыто. Здесь можно заметить сбой, который не виден на двух отдельных снимках: мобильная панель остаётся поверх настольной навигации, исчезает кнопка закрытия или после закрытия перестаёт прокручиваться страница. Проверьте и обратный переход к узкому окну.
Критерий исправления: все нужные пункты достижимы, панель можно закрыть, после перехода или закрытия содержимое доступно, а возврат к другой ширине не оставляет интерфейс в промежуточном состоянии. Для длинного меню допустима собственная вертикальная прокрутка, если до последнего пункта можно добраться.
Пройдите те же действия с клавиатуры
Уберите мышь и начинайте с начала страницы. Клавиша Tab обычно переводит фокус вперёд, Shift+Tab — назад. Фокус — это элемент, на который подействует следующая команда с клавиатуры; он должен быть заметен. Для обычных ссылок используйте Enter, для кнопок — Enter или пробел. У сложных элементов управление может отличаться.
Откройте меню, перейдите в раздел, доберитесь до формы и её кнопки. Проверяйте не только срабатывание. Если выделение ушло за закрытую панель или под фиксированную шапку, человек не понимает, где находится. Если после закрытия окна невозможно продолжить путь по странице, это отдельное препятствие.
Отметьте элементы, которые мышью работают, а клавиатурой пропускаются, и места, из которых нельзя выйти обычным перемещением фокуса. Не требуйте Tab на каждом абзаце: эта клавиша прежде всего нужна для перехода между интерактивными элементами. Если на вашем компьютере она выбирает только поля формы, сначала уточните настройки клавиатурной навигации браузера и системы.
Открытый диалог может удерживать фокус внутри себя: это ожидаемо, если его можно закрыть с клавиатуры и продолжить работу. Проверяйте доступную кнопку закрытия и предусмотренный способ выхода; часто используется Escape. Один циклический переход между элементами открытого диалога ещё не доказывает ошибку.
Критерий исправления: основной маршрут выполняется с клавиатуры, положение фокуса видно, порядок переходов позволяет понять действие, а закрытые элементы не перехватывают управление. Работа экранного диктора и другие свойства доступности требуют отдельной проверки — успешное прохождение с Tab не подтверждает их автоматически.
Покажите форме ошибки, а не только пустые поля
На тестовой копии оставьте обязательное поле пустым или введите значение, которое не соответствует явно указанному формату. После попытки отправки проверьте расположение сообщения. Оно может занимать больше строк, чем команда ожидала: подвинуть кнопку, наложиться на следующее поле или оказаться за нижним краем окна.
Должно быть понятно, какое поле требует исправления и что произошло. Одна изменившаяся рамка без текстового пояснения не решает эту задачу. Исправьте значение и снова пройдите форму: сообщение должно соответствовать текущему состоянию, а остальные введённые данные — оставаться доступными. Для обычной заявки исчезновение всего заполнения после одной ошибки стоит отдельно согласовать и исправить.
Проверьте форму в узком окне, а на телефоне — ещё и с открытой экранной клавиатурой. Наблюдайте, можно ли увидеть подсказку, перейти к следующему полю и достать кнопку. Если на тестовой среде команда может воспроизвести сбой отправки, посмотрите также его сообщение: оно не должно перекрывать управление или изображать успех.
Не смешивайте выводы. Сообщение видно — это проверка отображения. Заявка действительно получена компанией — проверка передачи данных. Одно не доказывает другое. Выбор полей, формулировки и подтверждение отправки подробнее рассматриваются в статье о понятной форме заявки.
На узком экране выясните, что именно прокручивается вбок
Верните обычный масштаб и постепенно уменьшайте ширину окна. Проверяйте не только привычные размеры телефона: промежуточная ширина может оставить слишком мало места для двух колонок, прежде чем они перестроятся. Повторите открытие меню и показ ошибок формы, затем посмотрите страницу на реальном телефоне.
Попробуйте сдвинуть содержимое вбок в двух местах: внутри широкой таблицы и на обычном абзаце вне неё. Смотрите, остаются ли текст, шапка и кнопки в доступной ширине. Большое пустое поле справа — полезный симптом, но причина может находиться далеко от видимого блока.
У таблицы характеристик может быть обоснованная горизонтальная прокрутка: она сохраняет соответствие строк и столбцов. Практически удобный вариант — отдельная область таблицы, где видны продолжение и способ пролистывания, а соседний текст переносится по ширине. Проверьте, доступны ли крайние столбцы и можно ли сопоставить значение с названием строки.
Другая ситуация — таблица или длинная строка вытянула блоки страницы, и для чтения обычного абзаца приходится ездить вправо и влево. Это уже препятствие. Исключение WCAG для содержимого, которому нужна двумерная компоновка, относится к соответствующей части, например таблице данных, и не оправдывает разъехавшийся окружающий текст.
Критерий исправления: обычные блоки читаются в доступной ширине, необходимое широкое содержимое остаётся доступным, а его прокрутка не мешает основному действию. Просто скрыть всё за правой границей недостаточно: отсутствие полосы прокрутки ещё не означает, что пропавшие столбцы или кнопки стали доступны.
Если нужны более широкие проверки именно мобильного сценария — касания, изображения, ориентация устройства и путь клиента, — используйте материал об адаптивном сайте и мобильной версии.
Передайте наблюдение и условие повторной проверки
Запись «сайт съехал» трудно воспроизвести. Достаточная запись отвечает на четыре вопроса: где, в каких условиях, после какого действия и что мешает посетителю. Предположение о причине запишите отдельно от наблюдения.
Учебный пример: «В списке товаров уменьшить окно, открыть карточку с длинным названием, затем увеличить масштаб до 200%. Последняя строка названия закрывает цену. Ожидается полное читаемое название и доступная цена без наложения. Приложены ширина области браузера, его версия и запись экрана».
Сначала исправляйте препятствия, которые блокируют действие или скрывают существенные условия. Затем — затруднения чтения и навигации; после них можно разбирать декоративные расхождения. Это рабочий порядок приёмки, а не доказательство влияния каждого дефекта на продажи.
После исправления повторите исходные шаги с тем же содержимым и соседние состояния. Перенос длинного названия проверьте в списке и карточке, исправленную форму — с ошибкой и без неё, меню — после смены ширины. Если меняли общий компонент, согласуйте проверку других страниц, где он используется. Принимайте восстановленную возможность прочитать и действовать, а не только новый снимок удачного размера.
Для реализации согласованных макетов и состояний предметом работ будет адаптивная вёрстка сайта. Если препятствия найдены на телефоне в уже работающем сайте, обсудите мобильную адаптацию, передав записи и критерии исправления. Такой список ограничивает объём работ конкретными проблемами; он сам по себе не требует полного редизайна и не заменяет полную оценку доступности.
