Акт приёмки не подписали: разбор аудита доступности сайта для слабовидящих

Аудит доступности сайта для слабовидящих — это проверка вёрстки, контрастности и HTML-разметки на совместимость с экранными дикторами NVDA и JAWS, увеличением шрифта и клавиатурной навигацией. Для B2B-компании это не жест доброй воли: часть корпоративных и государственных заказчиков прописывает соответствие ГОСТ Р 52872 в договоре, и сайт без такой проверки может сорвать приёмку и оплату по контракту.

Заказчик открыл сайт с NVDA — и не прошёл дальше формы заявки

Московская веб-студия — клиент, с которым мы работаем по разным направлениям аудита, — сдавала корпоративный сайт для крупного производственного заказчика. В договоре был пункт про соответствие ГОСТ Р 52872-2019: у заказчика есть внутренняя политика доступности, и перед подписанием акта его специалист по контролю качества проверяет любой новый цифровой продукт вручную, с включённым экранным диктором NVDA.

Он открывает сайт, доходит до формы заявки на коммерческое предложение — и застревает. Диктор молчит там, где должен читать название поля, фокус после клика по кнопке «Отправить» перескакивает не на сообщение об ошибке, а куда-то в подвал страницы. Специалист закрывает вкладку и пишет письмо: акт не подписан, к сайту есть претензии по доступности, продукт не соответствует условиям договора.

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

Почему это не редкость: ГОСТ давно не только для госсайтов

ГОСТ Р 52872-2019 «Интернет-ресурсы. Требования доступности для инвалидов по зрению» напрямую обязателен для сайтов государственных органов и организаций, оказывающих услуги населению. Для обычного коммерческого сайта он формально добровольный — но именно поэтому крупные заказчики стали ссылаться на него в договорах с подрядчиками: проще написать в техзадании «сайт должен соответствовать ГОСТ Р 52872», чем формулировать собственными словами, что значит «сайт должен читаться скринридером».

Стандарт опирается на международные рекомендации WCAG 2.1 и описывает два уровня соответствия — базовый и расширенный. В договорах с корпоративными заказчиками чаще требуют хотя бы базовый уровень: корректные подписи полей, достаточный контраст текста, доступность управления с клавиатуры. Именно эти пункты и проверяет приёмочная комиссия — вручную, с экранным диктором, а не по чек-листу в PDF.

Что нашла проверка при чтении сайта на слух

Мы разбирали этот сайт вместе со студией уже после отказа в приёмке. Список претензий заказчика совпал с тем, что показал наш аудит: пять конкретных нарушений, каждое из которых мешает работать с сайтом человеку с ослабленным зрением.

• ✓Поля формы заявки не связаны с подписями через атрибут label — диктор зачитывает их как «поле редактирования, пусто», не называя, что именно нужно ввести.
• ✓Текст на карточках товаров в каталоге — серый на светло-сером фоне, с недостаточным контрастом: при слабом зрении и на экране с бликами он сливается с подложкой.
• ✓У изображений товаров и иконок в меню нет атрибута alt — диктор либо молчит, либо зачитывает имя файла вроде img_2394.jpg.
• ✓Порядок перехода по клавише Tab не совпадает с визуальным порядком блоков: фокус прыгает из шапки сразу в подвал сайта, минуя основное меню и форму.
• ✓Прайс-лист и типовой договор на сайте лежат в виде сканов PDF без текстового слоя — экранный диктор не может прочитать в них вообще ничего.

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

Во что это обошлось студии

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

Студия сняла разработчика с другого проекта, чтобы закрыть претензии в срок — это сдвинуло дедлайн по соседнему заказу и потребовало объяснений уже перед другим клиентом. Найти на рынке специалиста по доступности веб-интерфейсов срочно и не по рыночной ставке не получилось: услуги таких экспертов в авральном режиме стоят дороже, чем плановая проверка на этапе разработки.

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

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

Как проходит аудит доступности на практике

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

1. ✓Автоматическое сканирование вёрстки — находит явные нарушения: отсутствие alt, пустые label, недостаточный контраст текста и фона.
2. ✓Ручная проверка клавиатурой без мыши — Tab, Shift+Tab, Enter: видно ли фокус, логичен ли порядок перехода между элементами.
3. ✓Прогон ключевых сценариев с экранным диктором NVDA и JAWS — заполнение формы, переход по меню, открытие карточки товара.
4. ✓Проверка контраста текста на всех типовых блоках сайта — не только в базовой теме, но и в карточках, всплывающих окнах, футере.
5. ✓Отдельная проверка документов — PDF, прайсов, договоров: если текстового слоя нет, проще пересобрать документ как обычную HTML-страницу, чем распознавать скан.

Автоматика находит явные ошибки за минуты, но не покажет, логично ли читается форма при реальной навигации — это видно только вручную, с диктором и клавиатурой. Поэтому правки закрывали по цене исправления, а не по алфавиту: сначала подписи полей и alt-атрибуты — это правки в разметке и в CMS, без изменения дизайна. Потом контраст — правка цветовых переменных в стилях. В последнюю очередь — порядок фокуса, потому что он требует пересборки структуры страницы, а не косметики.

Три способа закрыть такие претензии — и в чём разница

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

Стоимость такой проверки считается по брифу — зависит от количества страниц, форм и типовых сценариев на сайте. Актуальные тарифы на аудит смотрите на странице цены и тарифы.

Как не наступить на те же грабли при следующей приёмке 🔍

Доступность для слабовидящих — один из девяти разделов, которые входят в аудит сайта: рядом с ней в том же отчёте идут скорость загрузки, безопасность и корректность вёрстки на мобильных устройствах. Это удобно именно для таких ситуаций — приёмка редко проверяет что-то одно, и разумнее закрыть все технические риски одним заходом, а не возвращаться к сайту по одной претензии за раз.

Если в договоре с заказчиком есть пункт про ГОСТ Р 52872 или про доступность в целом, стоит запускать такую проверку до подписания акта, а не после отказа. Это дешевле по времени и деньгам, чем спешно искать специалиста, когда транш уже заморожен. Тем, кто регулярно сдаёт сайты корпоративным и государственным заказчикам, имеет смысл включить проверку доступности в стандартный чек-лист перед сдачей проекта — так же, как тестирование форм или проверку на разных браузерах.

❓ Частые вопросы

Как понять, что сайту нужен такой аудит, если жалоб от пользователей не было?

Жалобы от людей со слабым зрением редко доходят до подрядчика напрямую — они просто уходят с сайта или звонят по телефону вместо формы. Тревожный сигнал — требование доступности в договоре или тендерной документации, отказ заказчика подписывать акт со ссылкой на ГОСТ.

Сколько времени занимает аудит доступности сайта?

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

Достаточно ли автоматических сканеров вроде плагинов для проверки контраста?

Автосканеры находят явные ошибки — отсутствие alt, недостаточный контраст. Но они не покажут, логично ли читается форма при реальной навигации клавиатурой и диктором — это проверяется только вручную с NVDA или JAWS.

Что делать с PDF-документами на сайте — прайсами, договорами, сертификатами?

Если в PDF нет текстового слоя, экранный диктор не прочитает документ вообще. Проще пересобрать такой документ как обычную HTML-страницу на сайте, особенно если прайс часто обновляется, чем распознавать и размечать скан заново.

Входит ли проверка доступности в общий аудит сайта UKVED или это отдельная услуга?

Доступность для слабовидящих — один из разделов комплексной проверки сайта по 9 направлениям. Её можно заказать вместе со скоростью, безопасностью и SEO или отдельно, если нужен точечный отчёт перед приёмкой у заказчика по договору.