Версия для слабовидящих — заплатка: доступный сайт делают правилами, которые проверяет машина

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

Разберём, что заказать и проверить вместо одной кнопки, на требованиях W3C и нашем опыте удержания правил на vibecoding.ru: клиентского кейса доступности и аудита нашего сайта по WCAG у нас нет.

Не хотите разбираться сами? Внедряем ИИ в ваш бизнес: задачи без лимита, одна цена в месяц, отмена в любой момент.

Что покупают по запросу «версия сайта для слабовидящих»? Часто панель: выбрать шрифт, увеличить буквы, сменить цвета. Такие настройки предлагает, например, скрипт lidrekon; FineVision предлагает код для вставки. Они могут быть полезны человеку, которому не подходит исходное оформление.

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

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

Как записать доступность в задаче? Начните с того, зачем человек пришёл: найти расписание, прочитать документ, отправить заявку. Выберите нужные вашей организации пути и перечислите страницы, формы и файлы внутри каждого. Иначе подрядчик сможет показать удобную главную страницу, а посетитель застрянет в документе или записи на приём.

Затем переведите «чтобы было удобно» в наблюдаемые условия. Для обычного текста ориентир WCAG 2.2 AA: контраст не ниже 4,5:1, для крупного текста порог 3:1; у критерия есть исключения. Увеличение текста до 200% должно сохранять содержание и функции, кроме оговорённых стандартом субтитров и изображений текста. В приёмке формы смотрят и успешное заполнение, и ошибку.

Это полезно и при работе с ИИ: «сделай доступно» оставляет агенту слишком много догадок. Описать результат и критерий «готово» помогает наш шаблон постановки задач агенту. В задаче должны оказаться и сами условия, и способ показать их выполнение.

Можно ли поручить доступность автоматике? Часть работы: искать отсутствующие подписи, проверять определяемые инструментом пары текста и фона, повторять отправку формы. При каждой правке проверка задаёт одинаковый вопрос и останавливает выпуск, если сохранённое условие больше не выполняется.

Но описание картинки может присутствовать и быть бесполезным: «изображение» вместо смысла схемы. Кнопка может иметь имя, а сообщение после её нажатия не объяснять, принята ли заявка. W3C прямо указывает, что один инструмент не определяет соответствие сайта требованиям доступности: нужна квалифицированная оценка человеком.

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

Что из этого мы проверили на себе? На vibecoding.ru записаны правила вида: контраст обычного текста, видимый фокус, подписи изображений, язык страницы и уменьшение движения по настройке пользователя. Их наличие не даёт оснований объявлять сайт соответствующим WCAG. Проверки должны подтверждать каждое условие в обозначенной области.

Наш пример относится к более узкой задаче: машинная проверка считает употребления цветов текста вне разрешённой палитры и не даёт увеличить их количество. Это ограничитель разрастания отклонений. Он не измеряет контраст текста с фоном: разрешённый цвет можно поставить на неподходящий фон и пройти такую проверку.

Почему мало написать правило, видно на другом случае: после перехода канона на «вы» старая страница сохраняла прежнее обращение, пока это не заметили руками. Правку сделали, машинную проверку заказали. Способы разбирать такие отклонения в старом коде разобраны в статье о техническом долге; здесь урок для доступности: у каждого обещания должна быть своя проверка, а у проверки указан предел.

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

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

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

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

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

Если сайт меняется постоянно, это задачи подписки: правила доступности в описании проекта, исправления и проверки каждого выпуска. На странице подписки тариф «Один проект» стоит 250 000 ₽ в месяц за один продукт и один поток работы, цена проверена 7 октября 2026. Разовая настройка панели сама по себе не основание покупать такую подписку; объём оценки доступности и ручной приёмки нужно согласовать для вашего проекта.

1. Заказывайте возможность прочитать информацию и выполнить действие. Наличие панели не заменяет этот результат.

2. Запишите критерии, страницы и состояния пути. Для каждого условия назовите автоматическую или ручную проверку.

3. Принимайте и успешное действие, и ошибку, с увеличенным текстом и без мыши. Отчёт относится к указанной версии сайта.

4. Закрепите проверку перед следующим выпуском и ответственного за найденную проблему. Исправление должно улучшать следующую приёмку.