Допустим, вы уже прониклись важностью обеспечения доступности ваших сервисов, закатали рукава и готовы взяться за работу.

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

• у вас есть деньги

• можно легко законтрактоваться (недоступно для больших организаций)

• проект конечный и относительно небольшой (в долгосрочной перспективе становится выгоднее брать нужных сотрудников на аутстафф, а лучше в штат).

Если же у вас нет средств и возможности заключить контракт, рассчитывать приходится только на свои силы и на сотрудников вашей компании.

С чего же начать? Сделать методички для дизайнеров? Протестировать свои продукты на пользователях с нарушениями зрения? Отправить всех разработчиков читать материалы по доступной разработке?

Что вам действительно важно, если вы занялись доступностью? Вам важны работающие доступные сервисы, поэтому начать надо с решения конкретных проблем. Вам нужны быстрые победы. Много и недорого.

Шаг 1: Ищем подопытных

Для начала нужно понять, какой продукт и какая команда наиболее готовы к такому новшеству, как обеспечение доступности. В каком-то продукте у вас будут спрашивать «Ну и зачем нам тут доступность?», а в каком-то сотрудники будут всеми руками за и сами предложат варианты решения проблем.

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

• короткий time2market — нам важно увидеть результаты работы в проде как можно быстрее

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

• в команде интересуются доступностью — вместе с такой командой проще находить способы решения проблем, даже если вы сталкиваетесь с ними впервые

• продукт, значимый для компании (больше всего покупок, посещений) — чем более важный продукт вы почините, тем заметнее будет ваша работа

• неэкзотический стек технологий — такие сервисы проще дорабатывать, скорее всего, ваши проблемы уже где-то кто-то решал и в сети есть примеры реализации

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

Если же это не первое ваше родео, и некоторые команды уже самостоятельно выявляют и решают проблемы доступности, то можно выбрать продукт по другим критериям:

• продукт в разработке — позволит предотвратить появление проблем

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

• наиболее интересный для бизнеса (много посещений/покупок, флагманский продукт).

Важно. Заранее договоритесь с владельцем продукта/менеджером/etc, что вы принесёте ему какой-то объём задач для нового релиза. Ресурсы команды стоит бронировать заранее, чтобы ваши задачи на доработки доступности были реализованы, а не затонули в бэклоге.

Шаг 2. Находим проблемы

В выбранном продукте уже реализована куча сценариев, экранов и кейсов, за что же браться? Полезнее всего для конечного пользователя будет обеспечение доступности не отдельных экранов, а пользовательской задачи в целом. Если на вашем сайте пользовательская задача — выбрать и приобрести воздушного змея, то проблемой некорректного alt-текста иконки факса в футере можно пренебречь.

Поэтому необходимо определиться с пользовательскими задачами, выполнение которых вы будете исследовать. Не стоит браться за всё сразу, особенно на первых порах. Выделите несколько сценариев — самых-самых в следующих критериях:

• самый частотный — починив его, вы облегчите жизнь бОльшему количеству пользователей

• прибыльный — поможете увеличить средний чек/количество покупок

• социально значимый — логично при улучшении доступности обращать внимание на сценарии, которыми чаще воспользуются люди с ограниченными возможностями здоровья (ОВЗ)

• свежий и рекламируемый — к нему сейчас много внимания и было бы здорово, чтобы он был доступным.

Для того чтобы исследовать доступность выбранных сценариев, можно привлечь слепых и слабовидящих пользователей, экспертов по доступности или внешнее агентство. Если же у вас нет ничего из вышеперечисленного, вы можете воспользоваться методичкой по экспертной оценке доступности от Госуслуг и самостоятельно проверить сценарии. Методичка основана на WCAG 2.2 и позволяет проверить сервис на доступность для пользователей с различными ограничениями.

Важно. Найденные проблемы нужно как-то помечать. Чтобы в дальнейшем отслеживать эффективность профилактики, выявления и решения проблем доступности. Например, таким задачам можно ставить тег #доступность в Jira

Шаг 3. Чиним

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

• высокая — пользователь не может выполнить задачу

• средняя — пользователю трудно выполнить задачу, он тратит на неё много времени

• низкая — пользователь недоволен интерфейсом.

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

В первую очередь, конечно же, чиним проблемы с высокой критичностью. Будет здорово, если после отправки этих задач в разработку, у команды останется ещё какой-то ресурс на доработки. Тогда среди обнаруженных проблем выбираем те, исправление которых будет проще и/или заметнее:

• можно исправить одной строкой кода

• повторяется во многих задачах/экранах

• встречается в компоненте, переиспользуемом в нескольких продуктах/сервисах

• базовые элементы UI-kit (мелкий шрифт, низкий контраст, небольшие кнопки и пр.)

Например, многие проблемы в работе экранного диктора решаются прописыванием корректных aria-атрибутов (что недолго). А небольшое повышение яркости серого цвета в стилях сделает весь текст на сайте контрастным.

Шаг 4. Определяем зоны роста

После того, как вы нашли проблемы и порешали их, необходимо выдохнуть и устроить ретро. Чтобы в следующий раз работа получилась быстрее и эффективнее, вам надо ответить на несколько вопросов:

• были ли спорные моменты, когда вам приходилось договариваться с командой о каких-то решениях

• чего вы ещё не знаете, что может вам пригодиться в дальнейшем

• что можно было учесть заранее, чтобы не допустить больше найденных проблем.

Что вам может понадобится

• Разработка чек-листов для аналитиков, проектировщиков, дизайнеров и разработчиков, чтобы предотвратить возникновение проблем доступности при разработке сервисов

• Разработка методики оценки доступности, обязательная оценка доступности сервиса во время функционального тестирования и дизайн-контроля

• Оптимизация вашего UI-kit и дизайн-системы для соответствия требованиям доступности

• Описание правил поведения отдельных элементов и форм, чтобы они были доступными и их поведение было одинаковым во всех формах и продуктах

• Разработка редполитики, чтобы общаться с пользователями на понятном языке

• Формирование правил описания доступности в макетах

Все эти материалы готовятся на основе WCAG, но некоторые готовые примеры вы можете подсмотреть на сайте с гайдами Госуслуг.

Шаг 5. Делимся опытом

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

Расскажите всем, какие проблемы вы нашли и решили, как это делали, какие вспомогательные материалы разработали. Рассказать можно где и как угодно:

• коллегам в курилке или на посиделках

• на синхронах или ретро

• выступить на конференции — внешней или внутренней, которую можно и организовать по такому поводу

• прочитать лекцию или выступить на вебинаре

• написать пост на хабр или в блог

• написать пост в телеграм-канал — в свой или предложить автору любимого канала опубликовать ваш пост

На Госуслугах мы регулярно публикуем материалы про доступность в нашем блоге на Хабре и телеграм-канале.Также выступаем на конференциях, читаем лекции в компании и даже провели полноценную внутреннюю стажировку с сертификатами по итогу обучения.

Шаг 6. Наблюдаем

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

• найти свои слабые места — зоны роста

• отследить динамику: проведите опрос с разницей в год, и поймёте, насколько бодро у вас развивается направление

• показать текущее состояние доступности в ваших продуктах руководству.

Короткую версию опросника (первые 10 пунктов) можно отправить в отделы аналитики, проектирования и дизайна, разработки, тестирования. Так вы поймёте ситуацию не только по продуктам, но и по специальностям.

В опроснике вы оцениваете сервис/команду по разным параметрам 0 до 3 баллов, где 0 — ничего не делаем, а 3 — всё делаем, всё умеем. В итоге можно получить примерный уровень зрелости доступности в компании в целом.

• 1 уровень — начальный: В компании уже начали вести работы по обеспечению доступности. В соответствии с качественным подходом (доступность — набор знаний), первым и самым важным этапом является наращивание компетенций команды

• 2 уровень — частичный: по мере того как в компании появляются компетентные сотрудники, проводятся доработки проблем доступности, а критерии доступности добавляются в процесс разработки ПО

• 3 уровень — полный: на этом этапе доступность становится важной характеристикой продуктов компании, её систематически отслеживают и повышают. В компании к этому моменту нарабатывается достаточный объём знаний и кейсов, чтобы активно делиться ими с сообществом.

После того как мы придумали этот опросник на Госуслугах, мы протестировали его на своих продуктах. Поделюсь с вами оценкой первых 10, которые попали в опросник. Разброс в оценке оказался большой — от 0,4 («А что такое доступность? Мы и не слышали»), до 2 («Знаем, умеем, стараемся») из максимума в 3 балла.

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

Шаг 7. Повторяем

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

Выводы

Чтобы компания всегда разрабатывала доступные сервисы, работайте сразу в нескольких направлениях:

• сотрудники должны знать, что такое доступность, понимать и использовать критерии её достижения

• у сотрудников должны быть чек-листы для оценки доступности, кейсы с примерами решения проблем

• доступность должна быть частью требований к сервису

• должен проводиться регулярный контроль доступности новых продуктов и анализ уже существующих

• исправление багов доступности должно нести такую же ценность для продукта, как и исправление обычных багов.