Начните с проверки главного действия на сайте: откройте форму заявки и попробуйте заполнить её без мыши. После вайбкодинга доступность сайта стоит проверять двумя способами: автоматическим тестом через Playwright и axe-core и вручную с клавиатуры. Claude Code поможет подготовить тест, разобрать замечания и исправить код. Ниже — порядок работы для владельца бизнеса без опыта разработки: что поручить агенту, какие результаты запросить и как убедиться, что после исправлений посетитель по-прежнему может отправить заявку или оформить заказ.
Что подготовить перед проверкой доступности сайта?
Доступность означает, что человек может прочитать содержимое и воспользоваться сайтом, в том числе без мыши или с программой экранного доступа. Для сайта малого бизнеса начните с того пути, который ведёт к обращению: посетитель открывает услугу, переходит к форме, заполняет поля и получает подтверждение.
Работайте в тестовой копии сайта или отдельной ветке проекта. Проверка формы не должна создавать настоящие заказы. Если тестовое окружение ещё не готово, сначала поручите Claude Code выяснить, как запустить проект локально и какие действия вызывают отправку заявки.
- Выберите один путь посетителя, например от страницы услуги до подтверждения заявки.
- Запишите состояния для проверки: открытое меню, пустая форма с ошибками, сообщение об успешной отправке.
- Попросите Claude Code найти существующие браузерные тесты и объяснить, как их запустить.
Такой подход соответствует практике из материала «Ультимативный гайд по вайбкодингу по шагам»: после каждой фазы разработки автор проводит тестирование, в том числе через браузер с Playwright (Битрикс24 Журнал). Для вашей задачи полезен именно этот принцип: проверять рабочий сценарий после изменений, пока понятно, какой участок кода меняли.
Как поручить Claude Code проверку через Playwright и axe-core?
Playwright управляет браузером: открывает страницу, нажимает кнопки и заполняет поля. axe-core анализирует страницу на ошибки доступности, которые поддаются автоматической проверке. Для совместной работы этих инструментов используют пакет @axe-core/playwright. Claude Code может подготовить тест в проекте и объяснить его результат обычным языком.
Если Playwright уже настроен, попросите агента использовать существующую конфигурацию. Не нужно создавать второй набор настроек или обновлять все зависимости ради одной проверки. Перед установкой пакетов пригодится порядок проверки зависимостей после вайбкодинга.
Передайте Claude Code такое задание:
«Изучи проект и найди способ запуска браузерных тестов. Пока не меняй код. Предложи план проверки доступности выбранного пути через Playwright и @axe-core/playwright. Учти открытое меню, ошибки формы и подтверждение отправки. Используй тестовую среду без реальных заявок. После согласования добавь тест и запусти его. Для каждого замечания покажи страницу, состояние интерфейса, проблемный элемент и объяснение для владельца сайта».
Проверять только страницу сразу после загрузки недостаточно. Сообщение об ошибке появляется после отправки пустой формы, а содержимое всплывающего окна — после нажатия кнопки. Попросите агента сначала воспроизвести нужное состояние в браузере и только затем запускать анализ.
В отчёте нужны отдельные отметки: что тест проверил, что он пропустил и что требует ручной оценки. Успешный запуск теста без найденных нарушений не подтверждает полную доступность сайта. В частности, автоматическая проверка не определит за владельца бизнеса, понятен ли посетителю текст ошибки.
Как разобрать ошибки контраста, подписей полей и кнопок?
Просите Claude Code связывать каждое замечание с действием посетителя. Формулировка «ошибка доступности элемента» мало помогает принять решение. Формулировка «поле телефона не имеет программно связанной подписи, поэтому программа экранного доступа не получает его название» уже указывает на причину и способ исправления.
- Контраст текста. Попросите проверить цвет текста вместе с фоном, включая ошибки формы и текст на кнопках. Если анализатор не смог оценить участок, оставьте его для ручной проверки.
- Подписи полей. У поля должно быть понятное название, которое связано с ним в коде. Подсказка внутри поля исчезает при вводе и не заменяет постоянную подпись.
- Названия кнопок. Кнопке с одной иконкой нужно доступное имя. Для посетителя и программы экранного доступа должно быть понятно, что она делает: открывает меню, закрывает окно или запускает поиск.
- Сообщения об ошибках. Попросите связать сообщение с нужным полем. Посетителю нужна конкретная инструкция, например какое значение исправить, а не только красная рамка.
Сначала исправляйте препятствия на пути к заявке: недоступную кнопку, непонятное поле, окно без возможности закрыть его с клавиатуры. Декоративные элементы проверяйте после основного сценария. Это порядок работы, а не основание игнорировать остальные замечания.
Поручайте агенту небольшое изменение с повторным запуском теста. Например: «Добавь связанную подпись к полю телефона, сохрани текущую вёрстку и проверь заполнение формы». Если одновременно попросить переделать дизайн и устранить все замечания, будет труднее установить причину нового сбоя.
Как проверить клавиатуру и результат исправлений вручную?
Откройте тестовую страницу и уберите руку с мыши. Клавиша Tab обычно переводит фокус к следующему элементу, Shift+Tab возвращает назад. Проверяйте, видно ли текущий фокус и совпадает ли порядок переходов с порядком действий на странице.
- Пройдите от начала страницы до формы с помощью Tab и убедитесь, что фокус не пропадает и не застревает.
- Откройте меню или диалог с клавиатуры и проверьте, можно ли выполнить действие и закрыть окно.
- Отправьте пустую форму в тестовой среде и найдите ошибку без помощи мыши.
- Исправьте ввод и завершите сценарий, затем повторите автоматический тест.
Отдельно проверьте увеличение страницы средствами браузера: подписи не должны перекрывать поля, а кнопка отправки должна оставаться доступной. Затем пройдите тот же путь на узком экране. Для этой части используйте чек-лист мобильной версии сайта после вайбкодинга.
Скриншоты помогают заметить наложение текста и смещение элементов. В материале «Скиллы для Claude Code, которые делают его лучше» описан цикл визуальной проверки через Playwright: агент получает снимок результата, находит дефекты и вносит исправления (vc.ru). Но по скриншоту нельзя проверить название поля для программы экранного доступа или порядок перехода клавишей Tab. Для этого нужны отдельные проверки.
Если важный сценарий остаётся непонятным, проверьте его с программой экранного доступа или включите такую проверку в задание специалисту. Результатом должна стать запись конкретного пути: что объявляет программа, где возникает препятствие и как его воспроизвести.
Типичные ошибки при проверке доступности после вайбкодинга
- Проверять только главную страницу. Добавьте в задание форму, меню и состояния после действий пользователя.
- Считать отсутствие автоматических замечаний гарантией. Пройдите основной сценарий вручную с клавиатуры.
- Просить агента скрыть предупреждение. Требуйте устранить причину; исключения из проверки пусть он объясняет отдельно.
- Принимать исправление без повторного теста. После изменения подписи или кнопки снова проверьте отправку формы.
- Принимать отчёт без воспроизводимых шагов. Запросите путь к тесту, команду запуска и описание оставшихся ограничений.
Если проверку выполняет внешний специалист, зафиксируйте состав результата заранее: выбранные страницы и состояния, тесты в проекте, список исправлений и замечания для ручной оценки. Так отдельная услуга по проверке сайта после вайбкодинга получает понятные границы. Владелец бизнеса принимает рабочий путь посетителя, а не только скриншот успешного запуска.
Следующий шаг займёт одну минуту: откройте главную страницу, нажимайте Tab до кнопки заявки и запишите первый элемент, на котором перестаёте видеть фокус.
