Как обеспечить цифровую доступность по всем правилам: опыт Яндекс Капчи
Привет! Меня зовут Павел Конон, я аналитик в команде Антиробота в Яндексе. Занимаюсь развитием инструмента капчи в команде Антиробота. Думаю из названия команды понятно, что мы работаем над системой онлайн классификации источников запросов — робот или человек.
Сегодня хочу рассказать о том, как мы решаем нетривиальную задачу: делаем нашу капчу более доступной для слабовидящих пользователей и при этом соблюдаем все требования безопасности и ГОСТ. С одной стороны нам нужно упростить прохождение капчи для людей с различными особенностями, с другой — оставить такую же сложность для роботов. Поэтому такие способы как упрощение заданий, проставление конкретному пользователю куки татем‑от‑капчи или возможность выбирать более подходящий тип задания, мы довольно быстро отклонили. И начали искать другие варианты.
Почему важна доступность на капче
Капча — крайняя в цепочке проверок запроса на роботность. Сюда перенаправляются запросы, для которых система Антиробота исчерпала способы пассивных проверок, и требуется взаимодействие с пользователем.
Сама капча состоит из двух этапов: быстрого (галочка, слайдер) и дополнительного (картиночное задание). К тому же такое разделение помогает упростить прохождение проверки: по нашим метрикам более 50% людей, попавших на капчу, проходят её на первом этапе (галочке, слайдере).
Не пройти капчу человек может по многим причинам. Возможно, какое‑то картиночное задание действительно неразборчиво: из‑за яркого солнца плохо виден интерфейс на экране телефона, неоднозначное решение задания, на старой версии телевизора не поддерживаются современные библиотеки JavaScript. За техническими проблемами следить несколько проще (и мы это делаем), а вот собирать сигнал о проблемах с доступностью сложнее. На текущий момент мы ожидаем, что пользователь либо обновит задание (например, переключится на аудиокапчу или попробует несколько раз пройти картиночное задание), либо напишет в поддержку, пользуясь формой обратной связи. Такие обращения имеют особый приоритет.
Обязательно нужно учитывать ситуации, в которых человек не может легко решить капчу из‑за личных особенностей или окружающих условий. Это может происходить в случаях перелома пальца, ситуационного или постоянного ухудшения зрения, когнитивных сложностей. В подавляющем большинстве таких случаев капча должна быть проходимой. Это мы и подразумеваем под доступностью.
Ниже мы рассмотрим виды нашей капчи и реализацию способов доступности. Но вначале я расскажу о принципах, которыми мы руководствовались.
Принципы доступности
Мы ориентируемся на два документа:
ГОСТ Р 52 872–2019 «Интернет‑ресурсы и другая информация, представленная в электронно‑цифровой форме. Приложения для стационарных и мобильных устройств, иные пользовательские интерфейсы. Требования доступности для людей с инвалидностью и других лиц с ограничениями жизнедеятельности»:
Web Content Accessibility Guidelines (WCAG) 2.1.
Хочу отметить, что в обоих документах суть одна, потому что ГОСТ основан на WCAG 2.1 и оперирует теми же критериями. Это общемировая практика: национальные стандарты пишутся как адаптация рекомендаций WCAG, разрабатываемых экспертными группами W3C.
Если кратко, то в них содержится четыре принципа. Ниже я опишу наше понимание этих принципов и ту функциональность, которая позволила нам их реализовать.
Воспринимаемый контент
Информация и компоненты пользовательского интерфейса должны быть представлены пользователям в том виде, в котором пользователи могут их полноценно воспринять.
Основные мысли этого принципа следующие:
У всех видов медиаконтента есть альтернативные представления (чаще всего текстовые). Это важно для машиночитаемости контента и интерфейсов (предоставляем доступность через использование программ экранного доступа).
Пользователь может адаптировать контент под свои потребности (например, увеличивать шрифт, приближать картинки).
Контент имеет определённую контрастность. Но тут есть нюансы. Актуальный стандарт оперирует понятием «коэффициент контрастности», который рассчитывается по формуле 
, где 
— значение относительной яркости более светлого цвета, а 
— значение относительной яркости более тёмного цвета. Не секрет, что эта формула на некоторых значениях ведёт себя неадекватно, например, по ней белый текст на синем фоне хуже, чем чёрный текст на синем фоне.
Это известная проблема, и её планируют решать в следующих версиях стандарта. Ну, а пока на практике в отрасли принято страховать расчёты по ней при помощи здравого смысла и дизайнерского чувства прекрасного.
Ну и в целом сейчас есть рекомендация не жалеть контрастности и ориентироваться не на минимально допустимые значения, а выше, потому что с распространением мобильных устройств пользователи всё чаще работают с интерфейсами где‑то на улице под солнцем или в метро с пролетающими за окнами источниками света, так что экран бликует и контент засвечивается.
Управляемый контент
Компоненты пользовательского интерфейса и навигация должны быть управляемыми.
Вроде бы очевидный принцип, однако можно легко забыть, что всё должно быть доступно для управления с клавиатуры (нет таких элементов управления, до которых можно добраться только с помощью мыши). Необходимы текстовые подсказки для ссылок, описания действий по кнопкам, пояснения назначения элементов.
Также должны быть и общие пояснения о назначении страницы. В случае капчи — это заголовок страницы «Ой, Капча» и понятный текст, что требуется от пользователя.
Дополнительно хочу обратить ваше внимание на динамические элементы. У пользователя должно быть достаточно времени для ознакомления с содержанием и реагированием на него.
Важно помнить, что элемент управления в фокусе должен быть выделен как визуально, так и через текстовые подписи при управлении с клавиатуры.
Пример выделения элементов при фокусировке с помощью клавиатуры
Понятный контент
Информация и возможные действия с пользовательским интерфейсом должны быть понятными.
Важным мы посчитали локализацию (язык), предсказуемость происходящего и возможность быстро получить помощь.
Сейчас страницы капчи доступны на 17 языках. Задания капчи выполнены таким образом, чтобы было интуитивно понятно, что требуется от пользователя. Сейчас аудиокапча доступна только на двух языках: русском и английском.
На страницах даны описания происходящего, указано, что необходимо сделать для прохождения, есть текстовые описания при неверном вводе ответа.
На каждой странице капчи есть ссылки на форму обратной связи. По этой ссылке можно прочитать ответы на часто задаваемые вопросы либо обратиться в нашу поддержку.
Надёжный контент
Контент должен быть достаточно надёжным для его обработки разнообразными пользовательскими приложениями, включая вспомогательные технологии.
Контент должен оставаться тем же при различных способах его чтения (программы экранного доступа, различные типы устройств и форм‑факторов, различные сочетания браузеров и ОС).
Наилучший способ проверить надёжность — это ручное тестирование. Поэтому перед каждой выкаткой новых версий капчи мы проверяем её в различных окружениях. Наибольшую сложность представляют собой окружения со старыми версиями JavaScript, устаревшие версии браузеров и нетипичные устройства (например, старые телефоны и ТВ).
Но даже если мы реализуем все принципы и требования на наивысшем уровне (ААА), это не означает доступность контента абсолютно всем пользователям со всеми типами ограничений. Тут могу только обратить внимание, что мы регулярно отслеживаем доступность наших сервисов и постоянно её улучшаем.
Как протестировать интерфейс на доступность
Наиболее простой вариант — использовать встроенный инструмент Lighthouse или подобные ему. Он доступен в консоли разработчика. Он позволит быстро оценить страницу как в мобильной, так и в десктопной версии. Также даст базовые рекомендации, что можно улучшить. Однако не стоит полностью полагаться на этот вариант проверки, т. к. такое автоматизированное тестирование проявит несоответствие лишь хорошо формализуемых критериев доступности без погружения в хитросплетения пользовательских сценариев.
Другой (более полный) способ — полномасштабный аудит, создание набора тест‑кейсов по доступности и ручная проверка всех сценариев. У нас в Яндексе есть выделенная команда, которая проводит регулярные проверки сервисов на доступность. Почитать про работу команды доступности можно тут и тут.
Стандарты доступности оперируют набором формальных критериев в виде проверяемых утверждений. Часть этого может быть достаточно успешно проверена автоматическими или полуавтоматическими инструментами. Однако сейчас в отрасли принято считать, что эффективной автоматизации поддаётся только около 20% аудита доступности. Остальное так или иначе предполагает ручную работу специалиста, владеющего необходимыми знаниями и навыками.
Кроме того, обеспечение доступности — не столько задача, сколько процесс, который не должен останавливаться.
В целом, процесс обеспечения доступности и контроля её качества предполагает следующие основные этапы:
Первичный аудит. На этом этапе происходит исследовательское тестирование продукта, выявляются и документируются дефекты доступности, а также вырабатываются и согласовываются способы их устранения.
Доработка интерфейса с целью устранения выявленных дефектов доступности. На этом этапе разработчики чинят интерфейс, а также налаживают процессы, призванные обеспечить поддержку доступности в будущем: формируются внутренние инструкции, интегрируются инструменты автоматической валидации и тестирования, да и просто формируются правильные привычки у команды.
Верификация исправлений. На этом этапе проводится повторное масштабное тестирование продукта, чтобы подтвердить исправление ранее выявленных проблем, а также убедиться, что в процессе починки в другом месте не стало хуже.
Постановка продукта на систематическое регрессионное тестирование. На этом этапе разрабатывается тест‑дизайн сервиса, его ключевая функциональность покрывается тестами, создаются необходимые артефакты тестирования: автотесты, чек‑листы, тест‑кейсы.
Поддержание доступности. В рамках этого этапа продукт продолжает существовать до своего закрытия или фундаментальной переработки. Регулярно проводится регрессионное тестирование, выявляемые дефекты документируются и исправляются, а для появляющейся новой функциональности запускается малая копия всего вышеописанного процесса.
Чтобы эффективно поддерживать такой процесс, необходимо, чтобы в команде были специалисты из области разработки и тестирования, которые также должны обладать дополнительными знаниями в области доступности пользовательских интерфейсов.
Нам в Яндексе повезло — такие люди у нас есть. В том числе мы работаем вместе с представителями нозологических групп, то есть с людьми, у которых те или иные особенности здоровья. Благодаря этому мы обладаем компетенциями для полного цикла разработки с учётом доступности. Часть ключевых компетенций обеспечивается отдельными специалистами, взаимодействие с которыми может запросить любой из наших сервисов: например, проконсультироваться с экспертом по технологиям или поставить свой продукт на регулярное регрессионное тестирование доступности специальной QA‑командой. И да, порой эти специалисты сами приходят к сервисам, чтобы ускорить внедрение доступности в Яндексе.
Как мы сделали доступную капчу
Стандартная галочка
Ниже я хочу показать, как мы реализовали принципы доступности в коде. Начнём со страницы с галочкой.
Рассмотрим элементы на странице:
Заголовок. Понятно, что что‑то произошло и указано ключевое слово «Капча». В header страницы достаточно добавить одну строчку с короткой и понятной фразой.
Ссылка на главную Яндекса. Это пример оформления ссылок. Достаточно добавить описание в тэг aria‑label и заполнить тэг class для чтения программой экранного доступа.
Текст с пояснением, что требуется от пользователя. Тут ничего особенного.
Ссылка на ЧаВо с ответами, как уменьшить частоту появления капчи. Эта ссылка должна быть кликабельна на любом окружении.
Чекбокс. Тут важно отразить его текущее состояние (отмечен или нет). Делаем это с помощью атрибута aria‑checked. Далее связываем метку (aria‑labelledby) и описание (aria‑describedby) с элементами, где указаны сами значения. Так программы экранного доступа могут понятно рассказать об элементе.
Интерактивный набор ссылок. Тут важна кнопка с вопросиком, которая показывает другие ссылки. Для неё тэг aria‑label явно указан как «Показать ссылки».
Текст со ссылкой на форму обратной связи. Ссылка ведёт на страницу с ответами на ЧаВо, внизу которой есть раздел «Написать в службу поддержки».
Кроме галочки пользователю может быть предложено пройти слайдер.
Подходы к разметке элементов те же. Необходимые дополнения — описание состояния бегунка и проработка способов управления.
Состояние бегунка (1) описывается довольно просто с помощью тэгов aria‑....
А управление реализовано как с помощью клавиатуры напрямую (стрелки влево/вправо), так и с помощью кнопок передвижения справа (2). Это необходимо, например, для управления с пульта SmartTV.
Обращу внимание, что активные элементы выделены жёлтой рамкой. Кроме этого есть поясняющий текст «Продолжайте тянуть».
Если система посчитала пользователя всё ещё подозрительным, ему будет предложено пройти дополнительное задание: распознать текст на картинке, выбрать силуэты в указанной последовательности или собрать картинку, передвигая слайдер. Всё вышесказанное остаётся актуальным и для этих заданий. Поэтому подробно на их разборе останавливаться не буду. Скажу только, что для нормальной работы на широком спектре окружений нам понадобилось сделать альтернативную реализацию JS‑кода заданий, чтобы убрать ошибки несовместимости версий.
Аудиокапча
Понятно, что решение картиночных заданий может быть доступно не всем, потому что оно предполагает работу исключительно с визуальным контентом. Поэтому для людей с особенностями зрения, слабовидящих и незрячих, мы предлагаем альтернативный вариант в виде аудиокапчи. Расскажу о её функциональности подробнее.
Переключиться на неё можно с любого дополнительного задания по кнопке «Изменить тип задания».
После переключения фокус автоматически устанавливается на кнопку «Прослушать», а в её описании даны пояснения, что требуется сделать. Опять же всё реализовано с помощью атрибутов aria‑....
Сразу после начала воспроизведения задания фокус переместится в поле ввода ответа.
Поскольку ответ всегда состоит из четырёх цифр, то при введении строки длиной четыре символа он автоматически отправляется на проверку.
При неверном вводе пользователю будет показано и озвучено сообщение об ошибке и необходимости повторного прохождения. Это же поведение актуально и для всех типов дополнительных проверок.
Для удобства повторное воспроизведение реализовано по нажатию на клавиши CTRL, когда курсор находится в поле ввода ответа. Воспроизведение задания начнётся сразу без инструкции.
Если аудиозадание неразборчиво, его всегда можно обновить. При обновлении фокус автоматически перенесётся на кнопку «Прослушать». Если, несмотря на обновление задания, оно всё равно остаётся неразборчивым, хочу порекомендовать слушать аудиозадание в наушниках. Это значительно упрощает его распознавание.
В случае когда вы повторно попали на капчу и опять потребовалась дополнительная проверка, она сразу переключится на аудиоверсию. Это реализовано посредством хранения состояния в localStorage.
Хотелось бы завершить фразой с пожеланием посещать нашу страницу с капчей, но прекрасно понимаю, что это никогда не доставляет радости людям:) Надеюсь на ваше понимание, если вы иногда будете попадать на капчу. Мы делаем многое, чтобы люди как можно реже сюда попадали, а также стараемся сделать прохождение капчи доступным для всех.
Вся функциональность доступности внедрена в SmartCaptcha. Поэтому если для вашего продукта требуется капча и перед вами стоит задача обеспечения её максимальной доступности, в том числе в соответствии с российским ГОСТ Р 52 872–2019 и международным WCAG 2.x (ISO/IEC 40 500:2012), то с помощью одного продукта вы можете подбить двух зайцев. Да и доступность интерфейса всегда лучше, чем его недоступность. Поэтому никогда не забывайте об accessibility в своих сервисах и проектах.
