Яндекс - Яндекс. Accessibility. Как мы делаем Яндекс доступным людям с ограниченными возможностями и почему считаем это важным

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

Accessibility-технологии в России развиваются преимущественно на энтузиазме и социальной ответственности, а также в каком-то виде на формализованных требованиях к доступности, которые прописываются в технических заданиях для государственных сайтов. Очевидным образом это сказывается и на той экспертизе, которая присутствует на рынке. QA-инженеров (Quality Assurance, контроль качества), глубоко знающих специфику accessibility, на рынке мало.
Внедрение доступности в Яндексе

Для определения проблемных мест и получения данных о предпочтениях пользователей Яндекс проводит опросы целевой аудитории. Эти исследования помогают определить сервисы, которыми наиболее часто пользуются люди с ограниченными возможностями, и сервисы, которыми они хотели бы пользоваться. Основываясь на собранных данных, мы формируем и корректируем нашу работу по обеспечению accessibility. Важную роль играют исследования в usability-лаборатории, позволяющие выявить проблемы, которые пользователям трудно сформулировать в явной форме.

Значительный объём работ лежит на разработчиках и QA-специалистах (инженеры по тестированию, или просто тестировщики). Бо́льшая часть работ приходится на обеспечение невизуальной доступности, то есть доступности для людей с нарушениями зрения. Это наиболее сложная задача, именно здесь применяются принципиально иные способы взаимодействия с пользователем.

В общем случае процесс разработки и тестирования интерфейса с учётом доступности выглядит следующим образом.
• Первичный аудит. Интерфейс поступает на начальное тестирование к QA-инженеру, который формирует список проблем и конкретных технических рекомендаций по доработке. На этой стадии внимание уделяется базовым проблемам доступности.
• Разработка. На основе отчёта и технических рекомендаций QA-инженера разработчик проводит доработку интерфейса.
• Повторное тестирование. QA-инженер тестирует доработанный интерфейс, проверяя список изменений, список ошибок предыдущего отчёта, а также вновь проводя комплексное тестирование всего интерфейса. По итогам проверки он формирует новый отчёт и список технических рекомендаций, которые либо уточняют не до конца исправленные проблемы, либо формулируют новые задачи.
• Цикл работ. Происходит повторение шагов 2 и 3 до тех пор, пока QA-инженер не подтвердит отсутствие проблем или не признает оставшиеся проблемы приемлемыми. В ходе этого процесса могут происходить промежуточные релизы интерфейса, когда в продакшен выпускаются отдельные доработки доступности, представляющие собой более или менее законченные блоки.
• Официальный релиз. Когда решением QA-инженера по accessibility продукт признаётся доступным на достаточном уровне, происходит релиз с соответствующим статусом. Без такого заключения в релизе о доступности не заявляется.
• Количество повторений шагов 2 и 3 варьируется в зависимости от сложности работ. Например, интерфейс главной страницы Яндекса пережил четыре таких итерации, по итогам которых получил статус полностью доступного. С другой стороны, до сих пор на этапе цикла разработки находятся интерфейсы, которые пережили уже несколько итераций, но такого статуса все ещё не получили, например Поиск.

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

Насколько известно из открытых источников (и некоторой доступной внутренней информации), в крупных IT-компаниях команда accessibility, как правило, представляет собой единую группу тестировщиков и разработчиков, которые внедряются в проект и выполняют задачи по обеспечению доступности. В нашей компании применяется иной подход.

В Яндексе существует большое количество обособленных друг от друга сервисов и продуктов, у каждого из которых своя команда разработки. Создание единой команды по accessibility сочтено неэффективным. Отдельная команда, конечно, может --">