Казалось бы, на дворе 2026 год, есть статьи про доступность (и ещё больше на английском) и, собравшись организовать повышение доступности у себя в отдельно взятом «корпоративном микрорайоне», просто берёшь, читаешь, но сталкиваешься с тем, что о процессах организации разработки и тестирования accessibility мало что есть, но не останавливаешься, так как молод, полон сил и наивен, и проживаешь год, полный удивительных приключений и невыносимой радости бытия.
Меня зовут Шуст Иван, за мной закреплено более 15 продуктовых команд, что делают фичи ежедневного входа, профиля, истории операций и связанные с безопасностью. Поэтому я, как лид, имею прямое отношение к процессам внедрения accessibility в Альфе, проживший последний год, пытаясь наладить и внедрить процессы accessibility, расскажу о всех граблях, которые мы собрали. Вы узнаете о рабочих подходах при работе с доступностью и как делать вот точно-точно не надо.
Технических подробностей будет мало. Но будет очень много про процессы/политику/конфликты, — всё то, что так сильно любят лиды будет интересно всем. В общем, добро пожаловать под кат.
Кратчайшее интро
Всем привет, давайте знакомиться! Меня зовут Шуст Иван, и я техлид Андроид-разработки в Альфа-Банке в проекте Alfa Mobile (приложение для физлиц). Техлид в Альфе отвечает не только за техническую часть продукта, но и за технические компетенции. К примеру, я отвечаю, за аналитику, работу с техдолгом, навигацию/диплинки, множество других вещей из внутренней кухни и, главное, за доступность. Но кроме того, техлид ещё и активно выстраивает процессы и ведёт коммуникации со смежниками.
Поэтому я, как лид, имею прямое отношение к процессам внедрения accessibility в Альфе. О чём и расскажу.
P. s. подпись под каждой картинкой размещена специально для незрячих пользователей, я же таки про визуальную доступность вещать буду.
С каких позиций мы стартовали
Кажется, что в 2026 говорить о необходимости доступности даже не стоит, но так как у нас серьезная статья, а не абы что, здесь будет статистика, которая гласит, что (по разным оценкам разных аналитических бюро) где-то 6 млн (плюс-минус) человек в стране живут с нарушениями зрения. Но так как население стремительно стареет, то количество людей с проблемами со зрением становится больше и статистика постоянно изменяется.
Также нужно учитывать, что пожилые люди будут становиться только продвинутее и искушеннее с точки зрения обращения с цифровыми продуктами. А если добавить к этому, что в стране действует ФЗ-181 о доступности информации и среды для инвалидов (ст. 14–15) и Банк России (10-МР, 2024) рекомендовал финансовым организациям повышать доступность дистанционных каналов (мобильные/веб-сервисы), то становится понятно, что не заниматься доступностью нельзя. Точнее можно, но лучше заниматься.
Теперь перейдем к самой accessibility. Accessibility, она же доступность, она же a11y, кому как нравится, грубо делится на два больших блока: визуальная и невизуальная (имеется в виду для пользователей с проблемами зрения):
Визуальная: это про читаемость (масштаб текста), контраст цветов, корректная верстка и порядок фокуса.
Невизуальная: работа со скринридерами (VoiceOver/TalkBack), понятные голосовые метки и подсказки, альтернативы жестам и «перетаскиванию», озвучивание ошибок и статусов, текстовые альтернативы изображениям.
Сегодня речь пойдет о невизуальной доступности.
И, казалось бы, невизуальная доступность это про «сделай правильную разметку компонентов в XML, расставь правильно contentDescription» и радуйся жизни. Да вот если бы всё было так просто…
Наш проект живёт достаточно давно (а если ваш долгожитель, то скорее всего ваша и картина будет похожа), чтобы в нем завёлось несколько технологий, на которых могут собираться экраны, несколько видов компонентов, несколько архитектурных подходов. Справедливости ради, надо сказать, что мы не бежим всё переводить на новую технологию или подход, а проводим ленивую миграцию, это позволяет сильно экономить ресурсы. Как вы наверное уже догадались, я люблю фразы «Появилась новая технология, она как нам поможет ультануть и катить фичи в 10 раз быстрее». Если я её с утра не услышу — день не задался, хожу весь смурный и грустно смотрю в окно…
Давайте же перечислим, на чём можно было собрать наши экраны:
чисто натив;
виджеты;
диполя;
SDUI;
многошаг;
webView,
будь он проклят.
Компонентная база состоит из:
обычных компонентов android;
компонентов из android material design;
локальных компонентов;
компонентов из старой дизайн системы;
компонентов из новой дизайн системы;
диполей;
виджетов;
нечто из компонентной базы веб разработчиков, ибо там тоже зоопарк элементов (эти компоненты используются через webView,
будь он трижды проклят).
Но не пугайтесь, жизнь рядового разработчика обычно не выходит за границы применения 1-2 технологий. Но вот поддержка доступности сопряжена со страданиями…
Активно заниматься невизуальной доступностью мы начали чуть больше года назад. До этого банк заказывал аудит доступности и нам приходили отчеты. Отчеты превращались в Jira задачки. Задачки выдавались новеньким. Системности в этом не было как и надежды, а отлаженный механизм системности пылился на том же складе, что и компетенции.
Но были два наивных лида, которым было не всё равно — Денис Прозукин, лид iOS и я. Сейчас остался только я, но не мог же не упомянуть, потому что это первый жизненный урок на вашем пути accessibility — ваш отряд доступности может становиться меньше. А вот препятствий меньше не будет.
Ну и давайте же начнём с первого препятствия.
С чего начать?
С вникания в тонкости невизуальной доступности.
Решили мы узнать о передовом опыте наших коллег с других бигтехов, провели множество встреч, и вот какие типы стратегий выделили. Может стратегий было больше, но мы нашли только три:
№1. Делать красивые отчеты о том, что и где плохо, красиво презентовать командам, и они уже сами решают, а надо ли им тратить время на доработки (очевидно, что никто ничего не правит).
Плюсов нет, а минусы и так понятны — протирка очков, а не работа.
№2. Точечно исправляем проблемы, мотивируем коллег своим примером, проводим демо, повышаем вовлеченность коллег.
Плюсы: не требует выстраивания процессов, дешево в реализации.
Минусы: подходит для маленьких коллективов.
№3. Составляем чек-листы с лучшими практиками, проводим мильён воркшопов, составляем рейтинги лучших/худших команд/направлений/продуктов в области доступности, рассказываем на каждом углу о том, как это важно и нужно.
Плюсы: объясняем коллегам зачем это нужно, но не как это сделать.
Минусы: малая эффективность в рамках одного большого проекта.
Так как мы были заточены на результат, то сразу отвергли первый вариант. Второй импонировал, но не подходил под структуру нашей организации, так как в банке работает очень много команд и людей. Третий путь тоже не устроил, так как больше подходил для компании со множеством независимых продуктов и конским бюджетом (догадайтесь какого цвета бренд этой компании =).
Значит будет четвертый.
Начали его мы со сборки команды, об этом я расскажу в отдельном пункте. В параллель с этим решили, что раз ядром большинства экранов является компонентная база, то надо сначала перевести ее, а по мере перевода доступность будет всё больше и больше проникать в экраны. Ставка была сделана правильно, как оказалось после.
Первоначальный план был следующий:
Набрираем команду.
Создаём техкомпетенцию accessibility со своим чатом и регулярными встречами, куда может прийти любой и попросить помощи.
Подсчитываем все компоненты и заводим таблицы в нашем рабочем пространстве.
Занимаемся доработкой доступности этих компонентов.
Внедряем регулярные аудиты приложения силами незрячего QA, заводим дефекты промсреды (ведь это же дефекты).
Команды, желая исправить дефекты, которые влияют на их показатели, берут в работу и помогают нам переводить компоненты.
Выделяем метрики, дорабатываем аналитику, собираем дашборды, мониторим графики.
После перевода всех компонентов открываем шампанское и радуемся жизни
Однако
За время пути.
Собака
Могла подрасти!
Реализация плана
А теперь посмотрим на реализацию плана на местности.
№1. Как собирали команду
Начали мы с самого главного — мы решили найти незрячего QA. Это очевидно — ведь, кто является экспертом в невизуальной доступности больше, чем незрячий?
Перед собесом мы решили посоветоваться с Толей Попко из Яндекса, как нам проводить собес и на что обращать внимание и т. д., в чём он нам и помог.
Было порядка 5 кандидатов. В целом все показали себя с хорошей стороны, но мы решили остановить свой выбор на Надежде Василенко. На данный момент мы с Надей работаем уже больше года. Я очень часто замечаю за собой, что я просто забываю, что она является незрячей, настолько она отлично ориентируется в цифровых продуктах: таск-трекере, ktalk'е, а-чате.
Потом мы поняли, что у нас нет человека, который будет помогать Наде с заведением задач в таск-трекере и подготовке пререквизитов, решили пойти попросить ставку QA-стажера и наняли Алену Зуеву. После мы вывели её в продуктовую команду, как полноценного QA, а нашими задачами она занимается уже 20% времени, но нам этого хватает.
Отмечу, что в Альфе есть замечательное правило разделения времени «80 на 20». 80% времени разработчик или любой другой it-специалист должен выполнять задачи в продуктовой команде, а 20% быть занят задачами от своего техлида: строить баню, колоть дрова и подметать лужи.
Поэтому для банка обеспечение невизуальной доступности в месяц равно сумме зарплаты Нади, а не целого отдела. На самом деле это очень важный момент. С нынешним положением дел в экономике, когда режутся косты, содержание одного человека это куда приятнее, в отличие от целого отдела.
Конечно же в этой всей истории нам никак нельзя было обойтись без лида QA — сия ноша упала на плечи Анатолия Яценко.
№2. Как поддерживали accessibility в компонентах
Далее мы выписали список всех компонентов их вышло более 300 на каждую платформу.
Решили, что поддерживать доступность будем на базовом уровне, так как не знаем контекста использования того или иного компонента, да и он может меняться от фичи к фиче. Предвидя сценарии, когда может потребоваться в зависимости от контекста поменять озвучку, мы решили определить единый контракт между платформами. Копья над ним мы ломали чуть больше квартала, но по итогу он получился универсальным сразу на две платформы.
Технически это все выглядит следующим образом:
У компонента поддержана дефолтная доступность, она максимально нейтральна и не заточена под конкретную фичу.
Далее, если какой-то команде недостаточно дефолтного поведения, то они могут его переопределить, либо локально, если фича нативная, либо через контракт, если используется одна из наших BDUI-технологий. Поля в контракте переопределяют соответствующие поля в дефолтной реализации.
Впоследствии подобный подход позволил кратно увеличить скорость поставок исправлений.
А вообще мы этот раздел как-то опишем в отдельной статье более детально.
№3. Как выстраивали процессы
Изначально мы хотели заводить дефекты промсреды, так как очевидно, что это просто не учтенные дефекты. Однако первые попытки пойти этим путем привели нас к конфликту с продуктовыми командами. Ведь наличие и количество дефектов промышленной среды напрямую влияло на показатели команд.
Команды отклонили все дефекты и мы взяли паузу — продумать план по захвату мира. Решили заводить просто задачи с issueType FR (feature request, наш внутренний тип), он уже не влиял ни на какие показатели. А чтобы ребята брали эти задачи в работу, решили агитировать команды за все хорошее и рассказывать, как это позитивно влияет на пользовательский опыт и все в этом духе.
Итог был неутешительный. Задачи почти не брались в работу =(
Значит надо действовать хитрее и мы придумали такой процесс: заводим задачи с типом FR, которые никак не влияют на показатели команды, однако через 3 месяца с момента заведения они переводятся в тип дефекта пром среды, которые уже бьют по команде.
Мы исходили из того, что умные ПО решат перестраховаться и за 3 месяца-то успеют выделить спринт разработчика на исправления проблем. Так как мы уже были обстрелянными лидами, то мы решили заручиться поддержкой руководителя всея продуктов Борисом Гавриловым. Он поддержал наши начинания и даже подтвердил это на общей встрече со всеми ПО.
Но мы совершили несколько фатальных ошибок:
Не зафиксировали эту договоренность в письме.
Назначали заведенные задачи на QA команд, но не учли того факта, что части коллег было выгодно проигнорировать эти задачи.
Другая часть коллег просто не умела нормально работать с письмами. Как оказалось, в IT это обычная проблема.
Третья часть просто не понимала что происходит и решила выбрать тактику камня.
Но большая часть задач падали не на те команды, а так как реакция была далеко не молниеносная, то задача могла блуждать от одной команды к другой с лагом в несколько месяцев (напомню что задачи заводила одна Алена, на тот момент был приоритет наполнить бэклог).
Повторно всё согласовав и зафиксировав в письме, мы решили, что теперь-то неуязвимы. Граблю с тактическими камнями поправили тем, что Толя лично назначал задачи на ПО и информировал их в почте об этом, дабы все шаги были записаны и ПО больше не могли говорить, что они не были в курсе.
Казалось бы все работает, наконец-то задачи начали закрываться, к нам стали приходить ребятами с просьбой о помощи, а мы всем помогали. Но не всё так просто.
Были ещё одни люди, которых мы не учли в нашем процессе, а точнее лиды — IT-лиды. IT-лид — это руководитель направления, в чьём подчинении может быть от нескольких десятков человек до нескольких сотен. И на них также влияет количество дефектов в их командах. И они не любят, когда на них скидывают задачи.
Но набив себе много шишек, мы стали опытными и предчувствуя новую граблю, заранее уходили с её траектории. Как-то одним днем к нам пришел один из IT-лидов с попыткой оспорить наш согласованный процесс. И тут на сцену выходит политика =) Я не придумал ничего лучше, чем просто позвать своего IT-лида, пусть борются в равной весовой категории.
От меня лишь требовалось подавать патроны показатели закрываемости задач, числа по увеличению пользователей, внутренние указы и прочее, что крыть было нечем.
В итоге мы выстроили процесс. С ним все смирились и привыкли. Конечно, мы не звери и идем на встречу коллегам, переносим сроки вправо и не заводим дефекты пром среды, но только если есть на то реальные причины.
№4. Как строили планы по захвату «почты, телеграфов, телефонов, мостов и вокзалов»
№1. Мы понимали, что нам нужно рассказывать о компетенции, чем она занимается и зачем она этим занимается. Мы провели несколько воркшопов, которые помогли коллегам понять, зачем и для кого они исправляют дефекты.
№2. На первом этапе всё приемочное тестирование осуществлялось только нами (Надей и Аленой), во избежании проблем, но по мере набора оборотов это начало становиться бутылочным горлышком и решили переложить эту ответственность всецело на командных QA. Но у ребят не было необходимого опыта, поэтому его решили закрыть воркшопами.
№3. Также мы составили чек-лист доступности, в котором описали, как делать надо и как не надо, также подробно описали процессы тестирования, чтобы команды могли сами справляться. В чек-листе собрали основную инфу об инструментах VoiceOver/TalkBack: как ими пользоваться, какие настройки можно включить и как они влияют на поведение этих инструментов.
№4. Собрали типы навигаций, выделили термины и дали им определения.
№5. Собрали шпаргалку по типам элементов, на что обращать внимание, какие состояния могут быть и примеры, много примеров.
№6. Конечно же собрали положительные и отрицательные примеры реализации.
№7. Создали публичный чат в корпоративном мессенджере, куда мог прийти абсолютно любой человек и попросить помощи или совета.
№8. Также начали проводить еженедельный встречи в онлайн-режиме в определенное время (куда нужно было предварительно записаться).
По итогу, коллеги знают куда можно обратиться за помощью, имеют на руках примеры как оно должно все работать, а также референсы в коде.
№5. Метрики. Нужно больше метрик
Я душнила очень люблю графики, поэтому на этапе прорабатывания процесса мы занялись проработкой метрик, которые бы указывали на результаты нашей работы.
Самое очевидное что пришло на ум, так это:
график по количеству уникальных пользователей в месяц,
график по активности пользователей в месяц.
Очевидно, что нас интересовала только определённая группа пользователей (сильно слабовидящие и незрячие). Так как эта группа пользователей использует для взаимодействия с приложениями такие программы как TalkBack и VoiceOver, то мы решили добавить отправку в аналитику флажка, информирующего о том, включена ли у пользователя эта программа или нет. Все гениальное просто =)
Выделив группу, построив графики, мы начали следить…
Наблюдая за ростом пользователей и их активностью появилась гениальная мысль — построить такой дашборд, который показывал бы на каком экране есть проблемы. Работало бы это на сравнении конверсий экранных переходов группы пользователей, у которой нет проблем со зрением, с конверсиями в группе, у которой есть ограничения по зрению.
Жаль ничего не вышло… Увы но выборка данных у одной из групп оказалась слишком маленькой. Но какая была идея…
Каких результатов добились
Понятно, что многое рассказывать нельзя, но на Android за год мы:
увеличили количество пользователей с TalkBack в 4.2 раз,
среднюю активность пользователей подняли на 35%
На iOS за год:
увеличили количество пользователей с VoiceOver в 2.9 раза,
среднюю активность пользователей подняли на 22%.
И вошли в топ 5 банков по цифровой доступности по рейтингу от USABILITYLAB.
Краткие выводы
Подытожу основные тезисы.
Ваши изменения в процессах должны быть подкреплены метриками и показателями. По ним можно судить о правильности выбранного вами плана действий.
Почта мощнейший инструмент фиксации всех договоренностей.
При проектировании процесса старайтесь учитывать интересы всех сторон, ну или учитывайте их хотя бы на первом шаге, до тех пор пока у вас не появятся доказательства эффективности вашей работы, тогда можно и закрутить гайки потуже.
Даже не пытайтесь побороть коллегу выше вас по должности, привлекайте на свою сторону людей в той же «весовой категории», что и ваш «соперник».
В процессе борьбы не забывайте, что вы все коллеги и работаете над одним продуктом. Не ссорьтесь и не ругайтесь, сегодня у вас разные позиции, а завтра вы можете оказаться по одну сторону.
А ещё подписывайтесь на канал Надежды в Телеге под названием «Исходя из опыта». Там кладезь информации по доступности, регулярные интервью с незрячими работниками ИТ, подкасты, исследования и просто много интересных постов в самобытными мыслями.
