Доступность капчи и проверок: как не отсечь людей

Капчу ставят, чтобы отсечь ботов. Но у неё есть побочный эффект, о котором вспоминают редко: вместе с ботами она отсекает живых людей. Человек со слабым зрением не разберёт искажённый текст. Уставший клиент на маленьком экране бросит форму после второй неудачной попытки. Пользователь скринридера просто упрётся в стену. И каждый такой случай — это потерянный заказ, о котором вы даже не узнаете.

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

Капча как невидимый убийца конверсии

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

Коварство в том, что потери невидимы. Вы не видите тех, кто бросил форму на капче: они просто не оставили заявку и ушли. В отчётах это выглядит не как «капча отсекла клиентов», а как «мало заявок». Поэтому цену капчи почти всегда недооценивают: защиту от ботов замечают, а потерянных людей — нет.

Кого отсекает недоступная проверка

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

• Люди с нарушениями зрения. Визуальная капча без звуковой альтернативы для них непроходима в принципе.
• Пользователи скринридеров. Плохо размеченная капча не читается вспомогательными технологиями.
• Люди с когнитивными особенностями. Головоломки и искажённый текст создают непосильный барьер.
• Все на мобильных. Мелкий текст и сложный ввод на маленьком экране роняют прохождение у всех подряд.

Важно понимать: доступность — это не «функция для меньшинства». Улучшая проверку для людей с ограничениями, вы одновременно облегчаете жизнь всем — уставшим, спешащим, тем, кто на телефоне в дороге. Недоступная капча превращается в стену не только для ботов, но и для части реальных клиентов.

Что даёт и что забирает капча

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

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

Тихие проверки вместо головоломок

Существует набор методов, которые отсекают ботов, не показывая живому человеку вообще ничего. Это и есть основа современной защиты форм.

• Honeypot (приманка). Скрытое поле, невидимое человеку, но заполняемое ботами; заполнено — значит бот.
• Проверка времени. Человек не заполняет форму за миллисекунды; аномально быстрая отправка — признак бота.
• Анализ поведения. Движения, паузы, порядок заполнения отличают человека от скрипта.
• Ограничение частоты. Слишком много отправок с одного источника за короткое время блокируется.

Ключевое достоинство этих методов — они прозрачны для человека. Живой пользователь заполняет форму как обычно и ничего не замечает, а бот отсекается в фоне. Видимую проверку показывают только тогда, когда тихие сигналы указывают на подозрительную активность.

Многоуровневая защита форм

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

1. Уровень 1 — тихие проверки. Honeypot, время заполнения, ограничение частоты работают всегда и незаметно.
2. Уровень 2 — анализ подозрительности. Поведение и репутация источника повышают или понижают уровень доверия.
3. Уровень 3 — адаптивное усиление. Только при явном подозрении включается дополнительная проверка.
4. Уровень 4 — видимый тест. В крайнем случае показывается доступная капча с альтернативой.

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

Доступная капча, если без неё никак

Иногда видимая проверка всё же нужна — например, под активной атакой. В этом случае её нужно сделать доступной, а не просто «включить капчу».

• Звуковая альтернатива. К визуальному тесту обязательно прилагается аудиовариант.
• Корректная разметка. Проверка правильно читается скринридером, у полей есть понятные подписи.
• Ясные ошибки. Сообщение об ошибке объясняет, что не так и что делать, а не просто «неверно».
• Контраст и размер. Достаточный контраст, читаемый размер, работающий на мобильных.

Где капча уместна, а где вредна

Капчу нельзя вешать на все формы по умолчанию — её место определяется ценой потери пользователя и реальной угрозой.

• Оформление заказа. Самое опасное место для видимой капчи: клиент почти купил, барьер стоит дороже всего. Только тихие проверки.
• Регистрация и вход. Здесь тихие проверки плюс адаптивное усиление при подозрении.
• Обратная связь. Умеренная защита; видимый тест только при реальном спаме.
• Публичные формы под спамом. Если форму активно атакуют, видимая доступная проверка оправдана.

Общее правило: чем ближе форма к деньгам, тем осторожнее с видимыми барьерами. На оформлении заказа ставить головоломку между клиентом и оплатой — прямой способ терять заказы, которые уже почти состоялись.

Защита форм в 1С-Битрикс

В 1С-Битрикс есть встроенная капча, которую можно включать на формах регистрации, авторизации, обратной связи и оформления заказа. Но включить её везде — не решение, а способ навредить конверсии. Правильный подход — комбинировать штатные и собственные механизмы.

1. Тихие проверки в основе. Honeypot-поля и ограничение частоты запросов на формах — незаметно для людей.
2. Адаптивная капча. Штатную капчу включать не всегда, а по признакам подозрительной активности.
3. Проверка на сервере. Валидация и антибот-логика работают на стороне сервера, а не только в браузере.
4. Доступность видимого теста. Если капча показывается, она размечена корректно и имеет альтернативу.

Реализация адаптивной защиты — это работа с событиями форм и, при необходимости, собственная логика. Как аккуратно расширять поведение Битрикса без ломки ядра, мы разбираем в материале про разработку модулей 1С-Битрикс. А безопасность серверной части и обработки запросов — в статье про безопасность REST и вебхуков.

Как измерять влияние на людей

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

• Отказы на формах с капчей. Резкий рост брошенных форм после включения капчи — прямой сигнал потерь.
• Доля неуспешных прохождений. Как часто люди не проходят проверку с первой попытки.
• Сравнение вариантов. Конверсия форм с разными способами защиты бок о бок.
• Жалобы и обращения. Прямые сигналы от пользователей, что не смогли пройти проверку.

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

Тестирование доступности

Доступность форм нельзя проверить «на глаз» — её тестируют так же, как проверяют человек с ограничениями. Минимальный набор проверок.

• Скринридер. Пройдите форму и капчу с включённым скринридером — читается ли всё, понятны ли ошибки.
• Только клавиатура. Форма должна заполняться и отправляться без мыши.
• Мобильные устройства. Проверка на реальном телефоне, а не только на десктопе.
• Контраст и масштаб. Читаемость при увеличении и на разных экранах.

Такое тестирование стоит включить в регулярную проверку сайта, чтобы доступность не деградировала при обновлениях. Автоматизировать часть проверок помогает настроенный CI/CD-деплой, где базовые проверки прогоняются на каждой выкладке.

Частые ошибки

• Капча на каждой форме. Видимый барьер по умолчанию везде — гарантированная потеря конверсии.
• Капча на оформлении заказа. Головоломка между клиентом и оплатой в самом ценном месте.
• Нет звуковой альтернативы. Люди с нарушениями зрения не могут пройти проверку в принципе.
• Плохая разметка. Капча не читается скринридером, ошибки непонятны.
• Только клиентская проверка. Антибот-логика в браузере обходится, серверной защиты нет.
• Не измеряют потери. Влияние капчи на конверсию никто не отслеживает.
• Нет запасного пути. Не прошёл капчу — клиент потерян без возможности связаться.

Чек-лист внедрения

1. Тихие проверки в основе. Honeypot, время заполнения и ограничение частоты работают на всех формах.
2. Защита слоями. Видимый тест — только при реальном подозрении, а не по умолчанию.
3. Оформление без капчи. На финальном шаге заказа видимых барьеров нет.
4. Доступная альтернатива. Если капча показывается, есть звуковой вариант и корректная разметка.
5. Запасной путь. У не прошедшего проверку остаётся способ связаться и оформить заказ.
6. Серверная проверка. Антибот-логика работает на сервере, а не только в браузере.
7. Измерение потерь. Отслеживаются отказы и прохождение форм с защитой.
8. Тесты доступности. Формы проверены скринридером, клавиатурой и на мобильных.

Вывод

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

Правильный путь — многоуровневая защита: тихие проверки (honeypot, время, поведение, частота) по умолчанию, адаптивное усиление только при подозрении и видимый доступный тест как крайняя мера. На оформлении заказа видимой капче не место вовсе. Стройте защиту слоями, измеряйте её влияние на людей и тестируйте доступность — и вы отсечёте ботов, не теряя клиентов.