Привет, я Таня Миронова — руководитель направления доступности Госуслуг в компании РТЛабс.  В этой статье я расскажу, для кого мы делаем наши сервисы доступными и поделюсь секретной техникой экспресс-тестирования доступности. Доступность — это определённый уровень вашего сервиса. Это не бонус, не особые потребности и не то, что можно предложить по запросу — так просто должно быть.  Простейший пример — пандус. Многие используют его просто так, когда занята лестница или устали ноги, нужно завезти коляску с ребёнком или велосипед, когда в руках большая сумка. Так опция, которая долгое время считалась необязательной, оказалась просто ещё одной удобной возможностью. А ведь раньше от неё открещивались: «Да к нам инвалиды и мамаши с колясками не ходят». Добавляя в свои сервисы такие опции, мы не делаем продукт доступнее только для людей с нарушениями — мы делаем его лучше для всех наших клиентов. Для исследования доступности сервисов можно выделить 3 ключевых инструмента: экспертная оценка, юзабили-тестирование и тест пирата.  Экспертная оценка по чек-листам. Когда-то мы изучили ГОСТ, WCAG, прочую нормативку и рекомендации по доступности интерфейсов, а затем выписали все требования в отдельный документ. Получился эксель на 105 строк. Эта таблица позволила проанализировать требования, найти упущенные в нормативке моменты и сформулировать понятные человеческие рекомендации.  На основе этих рекомендаций сформировали чек-листы доступности для веба и мобильных приложений. В дополнение составили специальный мануал, чтобы чек-листами было удобнее пользоваться. По ним проверяем каждый пользовательский сценарий — смотрим, есть ли в нём проблемы доступности, мешающие выполнению ключевой задачи в интерфейсе. Подробнее про чек-листы расскажу в отдельной статье, там же приведу примеры найденных проблем. Юзабилити-тестирования с незрячими и слабовидящими пользователями. Подойдёт, если:  нужно исследовать доступность нового продукта, новой фичи; сравнить доступность с предыдущей версией; получить объяснение плохих или непонятных метрик в аналитике. Юзабилити-тестирование доступности имеет смысл проводить только после того, как вы экспертно оцените свой сервис и исправите самые очевидные проблемы.  Подробнее про такие исследования мы рассказываем в отдельной главе нашего гайда по доступности. Там раскрываем все нюансы от поиска респондентов до этикета встреч. Тест пирата — если тестирование нужно «вот прямо сейчас». О нём расскажу подробнее. Сразу предупрежу: тест несёт шуточный образовательный характер и не является попыткой кого-то оскорбить. Все совпадения случайны, а герои вымышлены. Можно ли взглянуть на сервис и сразу найти в нём грубые ошибки доступности? Получится ли сразу понять, кто не сможет воспользоваться вашим приложением или зарегистрироваться на сайте? Это довольно легко — проведите тест пирата. Как это работает. Когда рисуете новый сервис, задайте себе вопрос — сможет ли им пользоваться пират? Не Джек Воробей, а тот самый, каноничный: с деревянной ногой, крюком вместо руки, повязкой на глазу, крикливым попугаем на плече. Например, мы на Госуслугах смотрим, сможет ли такой пират оформить заявку на получение нового протеза или получить выписку из пенсионного счёта? Пират тут будет выступать как собирательный образ человека со всеми возможными ограничениями: деревянная нога обозначает ограниченную мобильность, поэтому ему нужен удобный вход в отделение неподалёку; крюк вместо руки даёт ограничение мелкой моторики, такому человеку будет неудобно нажимать на мелкие кнопки и работать мышью; повязка на глазу — символ ограничения зрения, как минимум у пирата нарушено стереозрение; крикливый попугай на плече вызывает ограничения слуха и речи, своими криками он мешает разговаривать, слушать музыку или смотреть видео; пират с таким количеством боевых ранений, скорее всего, пожилой, у него могут быть проблемы с координацией; проведя всю жизнь на море, наш пират слабо разбирается в технологиях и не понимает, что такое VPN и прочие модные штучки. Что нельзя протестировать «пиратом». Тест пирата предназначен только для поверхностной оценки и поиска самых грубых ошибок вроде мелких кнопок, неконтрастного текста и прочих заметных вещей. Также этот тест не охватывает взаимодействие пользователя с помощью программ экранного доступа — это всегда нужно тестировать вдумчиво и вручную.  После тестирования все найденные проблемы нужно оценить и описать, ориентируясь на справочник типичных проблем доступности. Проблемам присваивается один из трёх уровней критичности: высокий — пользователь не может выполнить задачу; средний — пользователю трудно выполнить задачу, он тратит на неё много времени; низкий — пользователь просто недоволен интерфейсом, но может им пользоваться. Найденные проблемы направляются в бэклог команды. С этими проблемами далее работаем как с самыми обычными багами: правим, тестируем и публикуем изменения. Во время работы разработчики иногда приходят к исследователям за консультациями. Так родились наши правила озвучки сокращений, цифр и дат. Например, программа экранного доступа аббревиатуру ГУ ГИБДД озвучивает как «гу гибэдэдэ», а должна «госуправление гибэдэдэ», а «двлд.» должна озвучивать как «домовладение», а не просто произносить набор букв. Это первая статья из цикла о доступности сервисов Госуслуг. Дальше будем подробно рассказывать про: наш опыт, типичные проблемы доступности и способы их решения; наши артефакты, подробно расскажем про гайды и методические материалы; обучения, которые мы проводим внутри компании; развитие направления доступности на Госуслугах. Уже запланировано несколько статей о доступности сервисов: «ограничения», а не «нарушения» выгода экспресс-тестирование оценка по чек-листам с примерами встраивание в существующие процессы недоступные интерфейсы Ссылки будут обновляться по мере выхода статей. Если у вас есть замечания или предложения по доступности Госуслуг, пишите в комментариях или мне в личку, с удовольствием рассмотрим всё.