Люди и интерфейсы. Рассказ незрячего тестировщика о том, как сервисы Яндекса становятся доступнее

Привет, меня зовут Анатолий Попко. Последние 15 лет (или около того) я работаю над тем, чтобы технологии становились доступнее для пользователей с различными ограничениями. Участвовал и продолжаю участвовать в работе разных групп и организаций, которые объясняют разработчикам технологий реальные потребности людей, пишут гайды, стандарты и так далее.

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

Как смотрят мультфильмы

Однажды, ещё задолго до того, как я начал сотрудничать с Яндексом, мы с коллегами организовывали показ мультфильма «Шрек» для незрячих ребят из школы-интерната. Наверное вы слышали, что на таких показах мультфильмы сопровождают тифлокомментариями — закадровыми описаниями того, что происходит на экране. Комментарии звучат в промежутках между диалогами и описывают действия, предметы и даже внешность героев. Но нам такого описания показалось недостаточно — захотелось действительно показать юным зрителям главного героя, этого забавного великана со странными ушами. Ведь у многих незрячих детей ничего со словом «Шрек» не ассоциировалось. 

Я подумал — дать пощупать его, что ли? И мы позвали ростовых кукол. Живые и настоящие, Шрек с Ослом подверглись, скажем так, тщательному тактильному изучению и произвели фурор. Мы (будучи организаторами) расщупали Шрека раньше, поэтому за детьми просто наблюдали, радуясь их ажиотажу.

А я в этот момент обратил внимание на воспитательницу, которая приехала вместе с ребятами. Обратил внимание потому, что она всхлипнула, стоя рядом со мной. Спросил, что случилось. Оказалось, она воспринимала ситуацию совсем не так, как я, и жалела детей. Хотя в этот момент ребята изучали окружающий мир. Не привычным для воспитателя способом (глазами), а ощупывая Шрека.

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

А теперь давайте поговорим о том, что такое цифровая доступность и как с ней «борются» в Яндексе. :)

Доступность — это для всех

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

Когда мы говорим о цифровой доступности, первыми на ум приходят именно незрячие пользователи, потому что:

• Полное отсутствие зрения — очень понятное и однозначное ограничение. Оно не вызывает вопросов о квалификации пользователя, не зависит от внешних факторов (освещённости), а главное, его никак нельзя преодолеть (хоть надевай очки, хоть нет).
• Программы экранного доступа (англ. screen reader), которыми пользуются незрячие люди — наглядный инструмент для тестирования на доступность: бесплатный, не такой сложный, как айтрекеры, и не зависящий от индивидуальных ограничений, как, например, система Стивена Хокинга. 

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

Но давайте сначала поймём, как незрячий человек пользуется графическими интерфейсами.

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

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

Программа экранного доступа зачитывает не только названия элементов интерфейса, но и другую информацию, которая лежит в коде. Например, если на экране есть текст «Купить» и это кнопка, незрячий пользователь услышит: «Купить, кнопка». 

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

Теперь давайте для примера возьмём элемент интерфейса, который открывает меню настроек и часто выглядит как шестерёнка. Как понять, что этот элемент доступен? Всё просто — с ним могут взаимодействовать разные пользователи:

1. Незрячий пользователь устанавливает на шестерёнку курсор программы экранного доступа и слышит: «Настройки, кнопка» или читает «Настройки КНП» на брайлевском дисплее.
2. Пользователь клавиатуры может переместить системный фокус на шестерёнку и убедиться, что фокус установлен именно на ней, увидев рамку (синюю обводку).
3. Пользователь с нарушениями мелкой моторики также может без труда открыть настройки, так как шестерёнка занимает достаточно места на экране и по ней легко попасть пальцем.
4. Слабовидящий пользователь замечает её, потому что есть необходимый уровень контраста.
5. А условно здоровый пользователь (без каких-либо ограничений жизнедеятельности, которые мешают воспринимать цифровой контент и управлять им) видит всё ту же шестерёнку и также успешно заходит в настройки.

Как сделать интерфейс доступным для незрячих

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

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

Если у элемента есть название, но отсутствует роль (или тип), то приходится догадываться, а можно ли вообще сюда нажать или это просто текст. В самых проблемных случаях может отсутствовать и подпись, и тип. В таких случаях использование цифрового сервиса без визуального контроля становится похожим на сказку: «Нажми то, не знаю что». 

Уровни погружения в проблему

Чтобы понять, что такое доступный цифровой контент, стоит заглянуть в стандарты доступности. В России это ГОСТ-Р 52872-2019, основанный на созданном W3C руководстве по обеспечению доступности веб-контента (WCAG 2.1).

Чтобы сделать доступными конкретные элементы интерфейса, нужно следовать техническим спецификациям: HTML, CSS, WAI-ARIA (описывает цифровой контент для программы экранного доступа).

Есть такой феномен — случайной доступности. Приложение может быть доступным не потому, что разработчик специально об этом думал. А потому, что он использовал те инструменты, которые ему предоставляет операционная система. Например, на ранних стадиях развития iOS и macOS разработчики активно использовали системные компоненты, доступность которых обеспечила Apple. Приложения, по слухам, были внешне похожи, но отличались большей доступностью. Затем разработчики стали создавать собственные компоненты, зачастую пренебрегая требованиями доступности.

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

Для интерактивных элементов важно, чтобы программа экранного доступа понимала, какие у элемента:

• Тип или роль («кнопка»).
• Название («настройки»).
• Состояние. Например, у флажка (check box) это: «отмечен» и «не отмечен».
• Значение. Пример — уровень громкости.

Для неинтерактивных элементов важны корректно размеченные заголовки, которые не только передают структуру контента, но и обеспечивают навигацию. Любая программа экранного доступа понимает команду: «Перейти к следующему заголовку». Проблемы появляются, когда разработчики отказываются от разметки текста тегами <h1>, <h2> или, наоборот, используют заголовочные теги для его визуального оформления.

Чтобы проверить интерфейс на доступность, тестировщикам нужно будет использовать специализированный софт. Я обычно советую тестировать в таком порядке:

1. Начать с клавиатуры. Если вы разрабатываете веб-приложение или сайт, попробуйте пройти базовые кейсы без мыши. Клавиатурный доступ отлично работает и без программы экранного доступа.
2. Использовать инструменты автоматизированного выявления дефектов доступности (например, Lighthouse, AXE, Wave). Они помогают найти до 40 процентов всех проблем и существенно облегчают последующее ручное тестирование.
3. Провести ручное тестирование с профессиональным пользователем программы экранного доступа. Историю про ручное тестирование я расскажу чуть позже.

Чтобы доступность не страдала

История 1. Применяйте стандарты

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

Если в процессе разработки опираться на системные компоненты, многие проблемы доступности решаются сами собой. В спецификации HTML для кнопки предусмотрен тег <button>. 

Если всё-таки нужно использовать <div>, то как минимум потребуются следующие атрибуты:

1. Роль кнопки <role="button">.
2. Состояние «нажата» и «не нажата» <aria-pressed="true">, если кнопка — переключатель.
3. Клавиатурный фокус <tabindex="0"> (иначе она не примет фокус).
4. Обработчик событий клавиатуры keyDown (чтобы кнопку можно было нажать при помощи пробела или клавиши Enter).
5. Состояние «недоступна» [aria-disabled], если применимо, иначе кнопка будет нажиматься даже тогда, когда не должна.

HTML

<div role="button" aria-pressed="false" tabindex="0"> toggle</div>

CSS

[aria-disabled] {
    pointer-events: none;
    opacity: 0.5;
}

JavaScript

wrapper.addEventListener("keydown", e => {
    if (e.key === " " || e.key === "Enter" || e.key === "Spacebar") {
        toggleBtn(e.target);
    }
});

Поэтому

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

История 2. Применяйте стандарты и тестируйте

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

Но ведь коллеги честно следовали стандартам:
— Контент на странице обновляется, так?
— Так.
— Мы должны показывать это обновление всем пользователям, так?
— Так.
— С помощью live-region мы передаём эти сведения программе экранного доступа. В чём же тут проблема?

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

Почему обязательно на весь экран? Если вы зрячий пользователь, вы очень часто пользуетесь периферийным зрением. И можете позволить себе выбор: переводить ли взгляд на рекламные блоки и отвлекаться на них или продолжить смотреть, куда смотрели. Незрячий пользователь фокусирует всё своё внимание на речевом выводе — и только на нём. Всё, что попадает в речевой вывод, сразу (одномоментно) занимает весь экран.

Поэтому

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

История 3. Что бывает, если не применять стандарты и не тестировать

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

Несколько лет назад, когда я ещё не сотрудничал с Яндексом, я заказал такси, чтобы доехать до работы. Обычно я пользовался iOS-приложением, но тут под рукой оказался Android — решил поэкспериментировать. Указал адрес подачи и пункт назначения, а потом (для большей надёжности) решил не искать кнопку «Заказать» внизу экрана, а последовательно до неё дойти, смахивая одним пальцем вправо. 

Такси приехало. Социального проекта «Помощь рядом» тогда ещё не было, поэтому я немало удивился, когда ко мне подошёл мужчина, поздоровался и представился водителем. Затем он так же вежливо спросил, открыть ли мне дверь и предложил подержать трость, пока я буду садиться. Вы знаете, салон дорогого автомобиля имеет свой особый запах. То ли дорогой кожаной обивки, то ли просто финансового благополучия. В общем, я, на всякий случай, переспросил адрес — всё правильно. В тот же день добродушный замдиректора похлопал меня по плечу и поделился, что он пока не может позволить себе ездить на работу на «Майбахе», но за меня очень рад. Я залез в приложение и… тоже порадовался, что вместо привычного эконома ехал бизнес-классом.

Позже, тестируя Яндекс Go, я выяснил, что при последовательном перемещении фокуса по элементам экран прокручивался, а при прокрутке открывалась карточка произвольного тарифа. В нижней части карточки тоже была кнопка «Заказать». Тариф поменялся, визуально это было заметно, а программе экранного доступа эта информация не передавалась.

Поэтому

Поэтому нужно помнить, что проблемы доступности могут быть совершенно не очевидны. Если не применять стандарты и не тестировать, то тогда обнаруживать их придётся пользователям. Что касается Яндекс Go на Android, то эту и другие проблемы исправили в процессе масштабной адаптации интерфейса Такси в 2021 году. 

История 4. Сосредоточьтесь на стандартах и спецификациях

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

Современный скринридер — сложный программный продукт, который опирается на сотню-полторы клавиатурных сочетаний и использует совершенно неочевидные решения (тот же виртуальный курсор для навигации по странице). Невизуальное использование современных цифровых интерфейсов требует времени и сил, которые трудно представить условно здоровому пользователю. Например, для того, чтобы незрячий пользователь компьютера средней квалификации освоил гугл-календарь, нужно 4—6 часов обучения (желательно под руководством незрячего преподавателя). 

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

Представьте, разработчик включает программу экранного доступа и начинает перемещаться по элементам интерфейса с помощью клавиш Tab и Shift+Tab. В процессе он понимает, что какая-то надпись, хотя и размечена правильно, как заголовок, программой экранного доступа не озвучивается. Тогда разработчик решает, что проблема в текстовом элементе и помещает важную надпись в какой-нибудь подходящий интерактивный элемент. А дальше у нас может состояться примерно такой диалог. 

— А что это за элемент?
— Это кнопка, но ты её не нажимай, она нужна, чтобы программа экранного доступа тебе этот важный текст озвучила.

Так делать не нужно. Потому что клавиатурный фокус должны принимать только интерактивные элементы (ссылки, кнопки, поля), и если это кнопка, то она должна нажиматься и как-то реагировать на нажатие. Секрет в том, что у программы экранного доступа есть тот самый виртуальный фокус, который и используется для навигации по веб-странице и доступа к неинтерактивному контенту (заголовкам, спискам, таблицам, абзацам текста). Если нужно перемещаться по интерактивным элементам (например, чтобы заполнить форму), можно использовать клавиатурный фокус, то есть Tab и Shift+Tab. А если требуется прочитать текст, то для этого используется виртуальный курсор. Это основы просмотра веб-страниц при помощи программы экранного доступа для настольных операционных систем. 

А ещё при повышении доступности важно держать в голове некоторые различия в том, как цифровой контент обрабатывается программами экранного доступа на разных платформах. Например, на macOS есть VoiceOver. Нажимаешь Command+F5 и компьютер говорит с тобой псевдо-человеческим голосом. Представим, что разработчик разобрался с ARIA-атрибутами, подобрал нужное их сочетание: теперь live-region озвучивается, как положено. Но при тестировании выяснилось, что NVDA на Windows воспроизводит совсем не то же самое, что VoiceOver на macOS. А подавляющее большинство незрячих пользователей, естественно, работает на Windows.

Поэтому

Поэтому я советую разработчикам погружаться в стандарты, спецификации и лучшие практики, а не в особенности вспомогательных технологий. Как правило достаточно краткого руководства, например, Desktop screenreader survival guide от Deque University. 

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

История 5. Не упрощайте интерфейс, а делайте его доступным

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

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

Повышение доступности не предполагает кардинальных изменений интерфейса (уменьшения количества компонентов на странице, изменения структуры или пользовательской логики). Повышение доступности решает принципиально другую задачу: как дать человеку возможность использовать именно этот интерфейс? 

Всевозможные «специальные версии для незрячих» — это неистовое зло, которое никак не удаётся искоренить. Если интерфейс сложен и неудобен — это проблема эргономики. А смысл повышения доступности в том, чтобы в результате любой пользователь смог сам убедиться: «хм, а интерфейс-то сложен и неудобен» — и написать об этом в техподдержку или отказаться от него в пользу более удобных решений. Поэтому, например, если бы мы предложили незрячим пользователям заказывать такси не в Яндекс Go, а через Алису или колл-центр, мы бы не сделали лучше, мы бы забрали возможность выбрать тот способ заказа такси, который для них удобен и привычен.

Ещё есть такой миф — незрячим нужно, чтобы дизайн был попроще. На самом деле не сложный дизайн непонятен, а недоступный дизайн непонятен. Простота и доступность — две принципиально разных характеристики интерфейса. Интерфейс может быть простой и доступный или сложный и доступный. В обоих случаях у незрячего человека есть все шансы стать полноценным пользователем цифрового сервиса. Если же интерфейс не соответствует требованиям доступности, то сложный он или простой — совершенно неважно. У цифрового сервиса с недоступным интерфейсом незрячих пользователей не бывает.

Если же вернуться к сложным интерфейсам, то для меня огромная страница вообще никакая не проблема. Дело в том, что я не знаю, много там контента или мало, пока по всему контенту не пройду. Когда зрячий пользователь открывает веб-страницу Яндекс Лавки, он сразу получает массу информации, а когда незрячий пользователь открывает ту же самую страницу, то он слышит: «Яндекс Лавка заголовок первого уровня». Потому что в Лавке правильно размечены заголовки первого уровня — ровно по одному на страницу. Это уже очень большое дело!

Ещё иногда спрашивают — а если сделать так, чтобы вместо бездушного металлического голоса скринридера всё озвучивала Алиса? Однажды мне предложили протестировать Алису, там был такой сексуальный женский голос. Вообще классная идея конечно, но работать невозможно. Разные настроения бывают у каждого человека, вы сами скорее всего не захотели бы слушать такой голос по 12 часов, каждый день.

Столь разные требования к голосовому ассистенту и синтезатору речи программы экранного доступа могут удивить стороннего наблюдателя, поскольку оказывается, что очевидные для одних людей преимущества (яркое интонирование, красивый тембр, сходство с человеческой речью) либо являются глубоко второстепенными, либо вообще становятся препятствием, а не преимуществом для других.

Поэтому

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

Как работа над доступностью устроена в Яндексе

Работа над доступностью сервисов в Яндексе началась не вчера. Главная страница, страница результатов поисковой выдачи (SERP), Погода отличались довольно высокой степенью доступности. Яндекс Диск на Windows и мобильных платформах всегда был очень популярен среди незрячих пользователей. Лёгкая версия Яндекс Почты, Метро и Электрички также были в значительной степени доступны. Отдельные задачи по доступности решала команда Яндекс Браузера. Были и адаптации и техническая экспертиза.

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

Рейтинг доступности

Рейтинг доступности — это большая исследовательская и просветительская работа, которую команда инклюзии начала в прошлом году (с 16 сервисов) и продолжила в этом (уже 21 сервис).

Рейтинг помогает:

1. Понимать, каков текущий уровень доступности сервисов Яндекса. 
2. Повышать приоритет инклюзии и цифровой доступности.
3. Мотивировать отдельные сервисы и компанию в целом.

Рейтинг формируется по итогам аудита, который проводит команда инклюзии.

В процессе аудита мы:

1. Формируем список сервисов и платформ присутствия. В 2022 году в список попал 21 сервис на разных окружениях.
2. Описываем целевой сценарий и целевые действия. Если коротко, сценарий — это ответ на вопрос, зачем нужен этот сервис (например, работать с электронной почтой). Целевые действия — это конкретные задачи пользователя (просмотреть список писем, написать сообщение, изменить настройки). Обычно, проводя аудит нового сервиса, мы запрашиваем пользовательские сценарии у команды сервиса.
3. Исследуем то, насколько полно и корректно интерфейс сервиса представляется программой экранного доступа. В работе участвует зрячий исследователь и незрячий эксперт (я).
4. Готовим отчёт с итогами аудита, то есть с очень подробным описанием проблем доступности.

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

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

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

Лиги доступности

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

Например, в первой лиге сейчас 10 сервисов. Среди них приложение Яндекс, Браузер, Почта и Лавка. У Поискового приложения и Браузера адаптированы базовые сценарии, а Почта и Лавка адаптировали интерфейс целиком, то есть весь их интерфейс покрыт доступностью. Яндекс Почта на iOS по уровню доступности сейчас сопоставима с почтовым клиентом от Apple.

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

При чём тут Шрек?

Работа над доступностью требует сил, времени и денег. Это определённые обязательства, которые взяли на себя команды разных сервисов. По итогам рейтинга доступности 2022 мы поблагодарили 202 коллег, которые вывели свои сервисы в первую лигу. Это люди, которые радикально меняют цифровую среду в России, делая её доступной для пользователей с различными ограничениями.

В каком-то смысле доступный интерфейс — это осознанный и осмысленный интерфейс. В нём правильно использованы элементы, разметка и клавиатурный фокус. Когда ты много внимания уделяешь интерфейсу, он становится лучше, окружающая среда — доступнее, а людям возвращается независимость. Впрочем, кажется, это я уже говорил… :)