Работа над доступностью: с чего начать, куда копать, как оценить прогресс
Допустим, вы уже прониклись важностью обеспечения доступности ваших сервисов, закатали рукава и готовы взяться за работу.
Самый простой способ — обратиться в агентство. На рынке есть несколько компаний, которые помогают оценивать доступность сервисов, проводить обучение ваших сотрудников и всячески помогать вам на этом нелегком пути. У них есть опыт, свои наработки, эксперты, готовые курсы. Услуги агентства — это здорово, если:
у вас есть деньги
можно легко законтрактоваться (недоступно для больших организаций)
проект конечный и относительно небольшой (в долгосрочной перспективе становится выгоднее брать нужных сотрудников на аутстафф, а лучше в штат).
Если же у вас нет средств и возможности заключить контракт, рассчитывать приходится только на свои силы и на сотрудников вашей компании.
С чего же начать? Сделать методички для дизайнеров? Протестировать свои продукты на пользователях с нарушениями зрения? Отправить всех разработчиков читать материалы по доступной разработке?
Что вам действительно важно, если вы занялись доступностью? Вам важны работающие доступные сервисы, поэтому начать надо с решения конкретных проблем. Вам нужны быстрые победы. Много и недорого.
Alt: Как говорил Рик Морти: Давай. Вошли и вышли, приключение на один квартал
Шаг 1: Ищем подопытных
Для начала нужно понять, какой продукт и какая команда наиболее готовы к такому новшеству, как обеспечение доступности. В каком-то продукте у вас будут спрашивать «Ну и зачем нам тут доступность?», а в каком-то сотрудники будут всеми руками за и сами предложат варианты решения проблем.
Но мало найти лояльную команду, надо чтобы наши первые шаги в обеспечении доступности не затянулись на год-другой. Поэтому среди всех продуктов/сервисов/команд мы выбираем те, где:
короткий time2market — нам важно увидеть результаты работы в проде как можно быстрее
для продукта важна доступность — меньше копий будет сломано при попытке припихнуть задачи доступности в бэклог к ближайшему релизу
в команде интересуются доступностью — вместе с такой командой проще находить способы решения проблем, даже если вы сталкиваетесь с ними впервые
продукт, значимый для компании (больше всего покупок, посещений) — чем более важный продукт вы почините, тем заметнее будет ваша работа
неэкзотический стек технологий — такие сервисы проще дорабатывать, скорее всего, ваши проблемы уже где-то кто-то решал и в сети есть примеры реализации
Чем больше критериев соблюдается, тем быстрее и безболезненнее вы получите первые результаты.
Если же это не первое ваше родео, и некоторые команды уже самостоятельно выявляют и решают проблемы доступности, то можно выбрать продукт по другим критериям:
продукт в разработке — позволит предотвратить появление проблем
новая, ещё не исследованная платформа — поможет выявить типичные проблемы для продуктов на платформе, благодаря чему их будет проще предотвращать, находить и решать
наиболее интересный для бизнеса (много посещений/покупок, флагманский продукт).
Alt: Врываемся на встречи команд со словами «А давайте вам доступность сделаем?»
Важно. Заранее договоритесь с владельцем продукта/менеджером/etc, что вы принесёте ему какой-то объём задач для нового релиза. Ресурсы команды стоит бронировать заранее, чтобы ваши задачи на доработки доступности были реализованы, а не затонули в бэклоге.
Шаг 2. Находим проблемы
В выбранном продукте уже реализована куча сценариев, экранов и кейсов, за что же браться? Полезнее всего для конечного пользователя будет обеспечение доступности не отдельных экранов, а пользовательской задачи в целом. Если на вашем сайте пользовательская задача — выбрать и приобрести воздушного змея, то проблемой некорректного alt-текста иконки факса в футере можно пренебречь.
Поэтому необходимо определиться с пользовательскими задачами, выполнение которых вы будете исследовать. Не стоит браться за всё сразу, особенно на первых порах. Выделите несколько сценариев — самых-самых в следующих критериях:
самый частотный — починив его, вы облегчите жизнь бОльшему количеству пользователей
прибыльный — поможете увеличить средний чек/количество покупок
социально значимый — логично при улучшении доступности обращать внимание на сценарии, которыми чаще воспользуются люди с ограниченными возможностями здоровья (ОВЗ)
свежий и рекламируемый — к нему сейчас много внимания и было бы здорово, чтобы он был доступным.
Alt: Эксперты по доступности пристально следят за авторизацией через Госуслуги, как Киллгрейв за Джессикой Джонс
Для того чтобы исследовать доступность выбранных сценариев, можно привлечь слепых и слабовидящих пользователей, экспертов по доступности или внешнее агентство. Если же у вас нет ничего из вышеперечисленного, вы можете воспользоваться методичкой по экспертной оценке доступности от Госуслуг и самостоятельно проверить сценарии. Методичка основана на WCAG 2.2 и позволяет проверить сервис на доступность для пользователей с различными ограничениями.
Важно. Найденные проблемы нужно как-то помечать. Чтобы в дальнейшем отслеживать эффективность профилактики, выявления и решения проблем доступности. Например, таким задачам можно ставить тег #доступность в Jira
Шаг 3. Чиним
По итогам исследований вы, скорее всего, найдёте ворох проблем. Чтобы выбрать те, за которые хвататься в первую очередь, определите их критичность:
высокая — пользователь не может выполнить задачу
средняя — пользователю трудно выполнить задачу, он тратит на неё много времени
низкая — пользователь недоволен интерфейсом.
Чтобы облегчить ранжирование проблем доступности, у Госуслуг есть справочник типичных проблем, где прописана рекомендуемая критичность.
В первую очередь, конечно же, чиним проблемы с высокой критичностью. Будет здорово, если после отправки этих задач в разработку, у команды останется ещё какой-то ресурс на доработки. Тогда среди обнаруженных проблем выбираем те, исправление которых будет проще и/или заметнее:
можно исправить одной строкой кода
повторяется во многих задачах/экранах
встречается в компоненте, переиспользуемом в нескольких продуктах/сервисах
базовые элементы UI-kit (мелкий шрифт, низкий контраст, небольшие кнопки и пр.)
Alt: Разработчик исправляет tabindex, а я смотрю на магию на фронте, как очень любопытная рыба на дайвера
Например, многие проблемы в работе экранного диктора решаются прописыванием корректных aria-атрибутов (что недолго). А небольшое повышение яркости серого цвета в стилях сделает весь текст на сайте контрастным.
Шаг 4. Определяем зоны роста
После того, как вы нашли проблемы и порешали их, необходимо выдохнуть и устроить ретро. Чтобы в следующий раз работа получилась быстрее и эффективнее, вам надо ответить на несколько вопросов:
были ли спорные моменты, когда вам приходилось договариваться с командой о каких-то решениях
чего вы ещё не знаете, что может вам пригодиться в дальнейшем
что можно было учесть заранее, чтобы не допустить больше найденных проблем.
Alt: В основе всех методичек по доступности в мире лежит WCAG. Без него всё это рухнет
Что вам может понадобится
Разработка чек-листов для аналитиков, проектировщиков, дизайнеров и разработчиков, чтобы предотвратить возникновение проблем доступности при разработке сервисов
Разработка методики оценки доступности, обязательная оценка доступности сервиса во время функционального тестирования и дизайн-контроля
Оптимизация вашего UI-kit и дизайн-системы для соответствия требованиям доступности
Описание правил поведения отдельных элементов и форм, чтобы они были доступными и их поведение было одинаковым во всех формах и продуктах
Разработка редполитики, чтобы общаться с пользователями на понятном языке
Формирование правил описания доступности в макетах
Все эти материалы готовятся на основе WCAG, но некоторые готовые примеры вы можете подсмотреть на сайте с гайдами Госуслуг.
Шаг 5. Делимся опытом
Этот шаг обязателен, если вы не хотите формировать отдельные команды по доступности, а планируете переложить эту задачу на членов команды разработки сервиса. Если вы начнёте регулярно рассказывать о доступности, её важности и методах достижения, то поможете сотрудникам углублять знания и применять их в своей работе.
Alt: Один и тот же кейс можно рассказать и в курилке и на конфе. Только на конфе ты чуть более нарядный
Расскажите всем, какие проблемы вы нашли и решили, как это делали, какие вспомогательные материалы разработали. Рассказать можно где и как угодно:
коллегам в курилке или на посиделках
на синхронах или ретро
выступить на конференции — внешней или внутренней, которую можно и организовать по такому поводу
прочитать лекцию или выступить на вебинаре
написать пост на хабр или в блог
написать пост в телеграм-канал — в свой или предложить автору любимого канала опубликовать ваш пост
На Госуслугах мы регулярно публикуем материалы про доступность в нашем блоге на Хабре и телеграм-канале.Также выступаем на конференциях, читаем лекции в компании и даже провели полноценную внутреннюю стажировку с сертификатами по итогу обучения.
Шаг 6. Наблюдаем
Во всей этой движухе важно не погрязнуть в потоке задач и обучений, необходимо отслеживать ваши успехи. Для этого можно воспользоваться специальным опросником, он позволит:
найти свои слабые места — зоны роста
отследить динамику: проведите опрос с разницей в год, и поймёте, насколько бодро у вас развивается направление
показать текущее состояние доступности в ваших продуктах руководству.
Alt: Как выглядит опросник
Короткую версию опросника (первые 10 пунктов) можно отправить в отделы аналитики, проектирования и дизайна, разработки, тестирования. Так вы поймёте ситуацию не только по продуктам, но и по специальностям.
В опроснике вы оцениваете сервис/команду по разным параметрам 0 до 3 баллов, где 0 — ничего не делаем, а 3 — всё делаем, всё умеем. В итоге можно получить примерный уровень зрелости доступности в компании в целом.
1 уровень — начальный: В компании уже начали вести работы по обеспечению доступности. В соответствии с качественным подходом (доступность — набор знаний), первым и самым важным этапом является наращивание компетенций команды
2 уровень — частичный: по мере того как в компании появляются компетентные сотрудники, проводятся доработки проблем доступности, а критерии доступности добавляются в процесс разработки ПО
3 уровень — полный: на этом этапе доступность становится важной характеристикой продуктов компании, её систематически отслеживают и повышают. В компании к этому моменту нарабатывается достаточный объём знаний и кейсов, чтобы активно делиться ими с сообществом.
После того как мы придумали этот опросник на Госуслугах, мы протестировали его на своих продуктах. Поделюсь с вами оценкой первых 10, которые попали в опросник. Разброс в оценке оказался большой — от 0,4 («А что такое доступность? Мы и не слышали»), до 2 («Знаем, умеем, стараемся») из максимума в 3 балла.
Alt: Пример результатов опроса по компании
По итоговой оценке этих первых продуктов видно, на чём нам надо сконцентрировать усилия в ближайшее время. На момент проведения опроса требования к доступности не были включены в наши стандарты запуска сервисов, но скоро обновлённая версия стандартов будет утверждена.
Шаг 7. Повторяем
Весь описанный процесс можно провести за один квартал. Вы можете встроить работы по обеспечению доступности в производственные процессы ваших продуктовых команд, ставить им задачи в спринты и выступать на ретро.
Выводы
Чтобы компания всегда разрабатывала доступные сервисы, работайте сразу в нескольких направлениях:
сотрудники должны знать, что такое доступность, понимать и использовать критерии её достижения
у сотрудников должны быть чек-листы для оценки доступности, кейсы с примерами решения проблем
доступность должна быть частью требований к сервису
должен проводиться регулярный контроль доступности новых продуктов и анализ уже существующих
исправление багов доступности должно нести такую же ценность для продукта, как и исправление обычных багов.
