Техлид Альфа-Банка Иван Шуст (на Хабре — Shust_Ivan) год выстраивал невизуальную доступность в приложении Alfa Mobile: работу скринридеров VoiceOver и TalkBack, голосовые метки, озвучивание ошибок и статусов, альтернативы жестам и перетаскиванию. Его вывод по итогам года: технически доработка сводится к разметке компонентов и правильным contentDescription, но доходят исправления до релиза или нет, решает устройство процесса — кто заводит задачи, как они влияют на показатели команд и кто из руководителей может процесс оспорить.

За accessibility в проекте отвечает техлид наряду с аналитикой, навигацией и техдолгом; отдельного подразделения нет. Правовая рамка — ФЗ-181 о доступности среды для инвалидов (ст. 14–15) и рекомендация Банка России 10-МР от 2024 года финансовым организациям повышать доступность дистанционных каналов. Аудиторию оценивают примерно в 6 млн человек в стране с нарушениями зрения, и доля растёт вместе со старением населения.

Почему вопрос не закрывается разметкой

Проект живёт давно, и внутри накопилось несколько технологий сборки экранов: чистый натив, виджеты, SDUI, многошаг, webView. Компонентная база — больше 300 элементов на каждую платформу: обычные Android-компоненты, Material Design, локальные, две дизайн-системы (старая и новая), плюс веб-компоненты, которые приезжают через webView. Рядовой разработчик обычно работает с одной-двумя технологиями, а поддержка доступности задевает все сразу.

Ставку сделали на компонентную базу: если довести доступность в компонентах, она проникает в экраны по мере их пересборки. Для компонентов определили единый контракт на две платформы, согласовывали его больше квартала. У компонента есть дефолтная доступность, максимально нейтральная и не завязанная на конкретную фичу. Если команде дефолта мало, она переопределяет поведение — локально для нативной фичи или через контракт для BDUI-технологий, где поля контракта перекрывают дефолт. Позже это кратно ускорило поставку исправлений.

Кто тестирует

Первым наняли незрячего QA — Надежду Василенко; перед собеседованием консультировались с Толей Попко из Яндекса, как его проводить. Из пяти кандидатов выбрали одного, работа идёт больше года. Затем взяли QA-стажёра (Алёну Зуеву) на подготовку задач и пререквизитов, вывели её в продуктовую команду как полноценного QA, а на задачи доступности она тратит 20% времени по внутреннему правилу Альфы «80 на 20»: 80% времени — продуктовая команда, 20% — задачи техлида.

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

Как задача доходит до команды

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

Тогда завели отдельный тип FR (feature request), который на показатели не влияет, и стали агитировать команды брать задачи ради пользовательского опыта. Задачи почти не брали.

Рабочей оказалась связка: задача заводится как FR, а через 3 месяца автоматически переводится в тип дефекта промсреды, который уже бьёт по команде. Расчёт — за квартал ответственный за продукт успеет выделить спринт разработчика. Поддержку процесса подтвердил руководитель продуктов Борис Гаврилов на общей встрече с ответственными за продукты.

На этом этапе команда допустила ошибки, которые перечислю отдельно:

• договорённость не зафиксировали письмом;
• задачи назначали на QA команд, хотя части коллег было выгодно их игнорировать;
• часть коллег не воспринимала почту как источник задач;
• часть выбрала тактику молчания;
• задачи часто попадали не в ту команду и месяцами мигрировали между командами, потому что заводил их один человек с приоритетом наполнить бэклог.

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

Стейкхолдер, которого пропустили

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

Метрики

Чтобы отслеживать результат, в аналитику добавили флаг: включён ли у пользователя TalkBack или VoiceOver. По нему выделили группу сильно слабовидящих и незрячих и построили два графика — уникальные пользователи в месяц и их активность.

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

Что получилось за год

• Android: пользователей с TalkBack — в 4,2 раза больше, средняя активность выше на 35%;
• iOS: пользователей с VoiceOver — в 2,9 раза больше, средняя активность выше на 22%;
• вход в топ-5 банков по цифровой доступности в рейтинге USABILITYLAB.

Что забрать для своего проекта

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