Первое, что важно понимать: нельзя чуть-чуть позаниматься доступностью, а потом прекратить. Как только вы прекращаете заниматься доступностью, всё тут же ломается.
Второе: когда люди начинают заниматься адаптацией, они видят верх айсберга, но на самом деле внизу ещё огромное количество того, что их ждёт.
И третье: у некоторых людей есть заблуждение, что можно дать продуктовым командам гайды или стандарты, а они сами всё сделают. Вам придётся проходить этот путь с командой и вместе расти.
Общаемся с командной и показываем важность адаптации
На первом этапе надо показать людям из команды, что доступность сервиса действительно важна. Для каждого человека — топ-менеджера, продакта или тимлида, разработчика или дизайнера, — скорее всего, потребуются свои аргументы. Валерия подробно рассказывала об этом в другом выступлении.
Одних убедят «кнуты»: требования законодательства, инвесторов или рынка, внешние и внутренние рейтинги, примеры из судебной практики.
Для других важнее будут «пряники»: рост прибыли и развитие бренда, повышение мотивации в команде или «плюсик в карму».
Но есть один универсальный способ убедить практически всех. В Яндексе мы приглашаем команду на открытое тестирование и показываем, как сегодня устроен интерфейс сервиса.
Это отлично работает, потому что топ-менеджеры или руководители понимают, что проблема есть и она совсем не в том, что пользователь незрячий, а в самом интерфейсе. Продакты убеждаются, что не придётся делать отдельные фичи, а разработчики видят, как они влияют на доступность приложения.
Обсуждаем ресурсы на адаптацию сервиса
На втором этапе вам нужно закинуть удочку про ресурсы. Делайте это ещё до оценки бэклога и прочих шагов, потому что не факт, что ресурсы на адаптацию сервиса вообще есть.
Когда вы приходите к руководителю с вопросом о ресурсах, возможны три варианта:
- Все хорошо понимают, зачем развивать доступность сервиса, ресурсы есть и вам их сразу готовы выделить. Дальше вы просто идёте заниматься адаптацией.
- Вам говорят, что в приложении достаточно других проблем, которые нужно решать в первую очередь. Тут не поспоришь, поэтому адаптацию придётся пока отложить.
- В ответ вы слышите: «Я то за, но...». Это значит, что либо вам нужно обратиться на уровень выше, потому что человек, с которым вы говорите сейчас, не отвечает за нужные вам ресурсы. Либо есть какая-то скрытая проблема, о которой вы ещё не знаете и которая блокирует саму возможность адаптации сервиса для незрячих людей.
Проводим аудит и выявляем конкретные проблемы
На третьем этапе надо протестировать базовые сценарии. Это значит, что тестировщик и незрячий эксперт вместе ищут, обсуждают и фиксируют проблемы доступности сервиса. Иногда к ним присоединяется разработчик или другой представитель сервиса.
Тестировщик или представитель сервиса, по нашему опыту, должен участвовать в аудите, потому что он:
- Может дать необходимые дополнительные данные, например доступ к тестовому стенду, преднастроенную тестовую учётную запись
- Знает возможности и интерфейс сервиса, понимает, что важно проверить, а что менее значимо
- Должен погрузиться в тему цифровой доступности, чтобы потом суметь ответить на вопросы коллег
- Фиксирует проблемы доступности и затем передаёт их в работу команде или конкретным людям
Формируем бэклог
На четвёртом этапе из всего массива найденных проблем выбираем те, которые планируем исправить в обозримой перспективе. В этом участвуют незрячий эксперт, представитель сервиса и менеджер по доступности. У каждого из них свои задачи:
- Незрячий эксперт оценивает серьёзность проблемы (critical, normal, minor), иногда указывает на необходимость доработок и обосновывает её
- Представитель сервиса (тестировщик, тимлид, менеджер) группирует проблемы, намечает конкретные задачи и ресурсы на их решение
- Менеджер по доступности ведёт встречу, а также связывает проблему с конкретными элементами интерфейса
На выходе получаем список проблем доступности высокого приоритета, по которому уже можно оценить и запросить необходимые ресурсы.
Получаем ресурсы
Есть три варианта, как будут развиваться события, когда вы определитесь с бэклогом:
- Вы можете решить все проблемы разом. Так получается, когда сервис небольшой или вы только-только его запустили.
- Вы можете поэтапно убирать критические проблемы доступности. Например, сначала адаптировать все функции в базовом сценарии, а уже потом переходить к менее значимым недочётам.
- Вам могут сказать: берём в работу одну-две проблемы и всё. В этом случае работа по адаптации растянется надолго или вообще не начнётся. Такое происходит, если в самом начале не удалось донести до команды или руководства, насколько важна доступность.
В любом случае, если вы получили необходимые ресурсы, можно переходить к самому понятному этапу адаптации сервиса.
Чиним и тестируем
Знакомый всем разработчикам цикл: решаем проблему, отдаём тестировщикам, они проверяют работоспособность сервиса и возвращают задачу нам.
Рано или поздно этот цикл заканчивается и оказывается, что обеспечить доступность сервиса — это только вершина айсберга. Сложность в том, чтобы удерживать её на высоком уровне в течение всего времени работы сервиса.
Что делать, чтобы сохранить высокий уровень доступности
В Яндексе есть три инструмента, которые помогают отслеживать состояние сервисов и не терять их доступность.
Рейтинг доступности. Ежегодно мы формируем рейтинг всех сервисов по уровню их доступности. Это верхнеуровневая оценка, которая позволяет понять, может ли незрячий человек воспользоваться сервисом без помощи.
Аудит и формирование рейтинга позволяют продвинуть цифровую доступность как корпоративную ценность Яндекса и вовлечь большее число сервисов в работу по адаптации.
Регулярные регрессы. Каждый сервис постоянно развивается, появляется новая функциональность и новые интерфейсы. Ежемесячный регресс помогает отследить, что уже адаптированный сервис после всех нововведений остаётся доступным.
Сервис тестируют незрячие эксперты по специальному набору тест-кейсов. Они отличаются от обычных тем, что в них нет «визуальных» слов и понятий: «шестерёнка», «в левом верхнем углу экрана», «кнопка должна стать красной». Тест-кейсы, в которых есть такие слова, невозможно использовать в случае, когда тестировщик использует программу экранного доступа для слабовидящих.
Если во время регресса незрячий тестировщик находит какие-либо проблемы, то передаёт их представителю сервиса, чтобы завести соответствующие задачи для разработчиков.
Отстройка внутренних процессов команды. Это самый важный инструмент, который помогает удерживать высокий уровень доступности наших сервисов. Мы на собственном опыте убедились, что:
- Внутри каждого сервиса должен быть человек, который отвечает за его доступность.
- Дизайн-система, UI-киты, библиотеки компонентов должны включать адаптированные элементы.
- Каждый член команды должен отвечать за ту часть доступности, на которую может повлиять. Например, дизайнер учитывает потребности людей с дальтонизмом, а менеджер проекта продумывает, подходит ли сервис для пользователей с нарушением слуха.
- Важно продумать, как будут распределяться баги: в техдолг, в конкретные продуктовые команды или как-то ещё.
- Обязательно раз в полгода-год напоминать о важности адаптации сервисов и развития их доступности.
Все вместе эти инструменты помогают поддерживать и улучшать доступность сервисов Яндекса.
Заключение
За последние три года в Яндексе адаптировали 13 сервисов для незрячих пользователей. Чтобы обеспечить доступность, мы:
- Показывали, что проблема есть
- Закидывали удочку про ресурсы
- Тестировали сервисы с помощью незрячих экспертов
- Формировали бэклог и выполняли оценку
- Договаривались о ресурсах
- Чинили и тестировали
В то же время мы поняли, что однажды адаптировать сервис мало, нужно постоянно поддерживать уровень его доступности. Для этого мы используем три инструмента:
- Рейтинг доступности
- Ежемесячные регрессы
- Отстройку процессов внутри команд
А ещё очень важно во время адаптации сервисов учитывать культуру и процессы именно в вашей компании и не пытаться натянуть чужой опыт на себя, если он не подходит.
Другие идеи о доступности и подробный рассказ об адаптации сервисов для незрячих вы найдёте в записи выступления.