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

Речь пойдёт о реализации accessibility (специальных возможностей) в мобильном приложении.

Краткая предыстория

Недавно я от имени проекта «Доступная жизнь» начал помогать Яндексу в реализации accessibility их навигационных приложений.

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

Поэтому я решил всё это изложить в отдельной статье.

В общем, поехали.

Невидимые элементы

Проблема

В процессе работы над картами мы столкнулись с проблемой:
При нажатии на область экрана с картой приложение должно переключать режимы (точно уже не вспомню подробностей).

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

Дело в том, что программы экранного доступа «видят» только конкретные объекты на экране: кнопки, текстовые блоки, поля ввода, регуляторы и списки. А в приложении Яндекс.Карты, нажатия на карту обрабатывались не как выбор объекта, а как касание определённой области экрана.

Решение

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

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

Прямой вывод речевых сообщений средствами самой програмы экранного доступа

Проблема

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

Решение

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

Кстати, в случае использования API скрин-ридера даже не требуется проверять, включен ли он. Если программа запущена, она выведет сообщение с помощью синтезатора речи, выбранного пользователем. А если программа выключена, просто ничего не произойдёт, и обычный пользователь ничего не заметит.

Разделяй!

Проблема

Это скорее рекомендация, а не лайфхак, но упомянуть об этом я обязан.

Помните, что для программы экранного доступа на экране есть только объекты?

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

Решение

Решение довольно простое: использовать элементы по назначению.

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

Заключение

В заключение хочу сказать, что разработка для Windows хоть и не существенно, но отличается от разработки для мобильных платформ, поэтому и особенности accessibility для Windows отличаются от особенностей для Android / Ios.

Реализуем поддержку accessibility, не меняя визуальную составляющую мобильного приложения