Яндекс. Accessibility. Как мы делаем Яндекс доступным людям с ограниченными возможностями и почему считаем это важным [Яндекс] (docx) читать постранично, страница - 3

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

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

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

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

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

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

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


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

После получения статуса доступного нельзя