В этой статье не будет ни строчки кода, ни единого сложного термина. Постараюсь изложить так, чтобы даже далёкий от разработки человек понял.
Речь пойдёт о реализации accessibility (специальных возможностей) в мобильном приложении.
Недавно я от имени проекта «Доступная жизнь» начал помогать Яндексу в реализации accessibility их навигационных приложений.
Я столкнулся с тем, что многим не приходят на ум очевидные с моей точки зрения вещи: невидимые элементы на экране, прямой вывод речевых сообщений с помощью API программы экранного доступа и так далее.
Поэтому я решил всё это изложить в отдельной статье.
В общем, поехали.
В процессе работы над картами мы столкнулись с проблемой:
При нажатии на область экрана с картой приложение должно переключать режимы (точно уже не вспомню подробностей).
Для незрячего пользователя с программой экранного доступа это казалось бы простейшее действие становится невозможным.
Дело в том, что программы экранного доступа «видят» только конкретные объекты на экране: кнопки, текстовые блоки, поля ввода, регуляторы и списки. А в приложении Яндекс.Карты, нажатия на карту обрабатывались не как выбор объекта, а как касание определённой области экрана.
Решение довольно простое: сделать на экране кнопку без рамки, с прозрачным фоном и без видимого текста (нулевой шрифт, что не так эстетично с точки зрения программиста, или специальные атрибуты, отображающие текст только для программ экранного доступа, не выводя его на экран).
Этот подход шокировал и удивил программистов, однако на практике всё получилось, идея сработала и активно внедряется везде, где нужно обрабатывать прямые нажатия на область экрана.
Ещё одной проблемой стало то, что иногда требуется вывести дополнительную информацию только для незрячего пользователя. Всплывающие сообщения в этом случае испортят дизайн и будут мешать остальным, а реализовывать отдельный режим приложения, в котором будут выводиться подобные сообщения, громоздко и нелогично.
Решение не столь очевидно, как в случае с невидимыми кнопками, но тоже лежит на поверхности.
Нужно использовать API самой программы экранного доступа для вывода сообщений. Это менее громоздко выглядит в коде программы, это не заставляет разработчика прилагать дополнительные усилия по созданию отдельных режимов, дополнительных настроек и т д.
Кстати, в случае использования API скрин-ридера даже не требуется проверять, включен ли он. Если программа запущена, она выведет сообщение с помощью синтезатора речи, выбранного пользователем. А если программа выключена, просто ничего не произойдёт, и обычный пользователь ничего не заметит.
Это скорее рекомендация, а не лайфхак, но упомянуть об этом я обязан.
Помните, что для программы экранного доступа на экране есть только объекты?
Так вот, тип объекта тоже имеет значение. На текст нельзя нажать, по её мнению, а кнопку нельзя скопировать. То есть, если таблица с настройками реализована как большой текстовый блок, который «ловит» нажатия на разные части себя, то такая таблица недоступна для программы экранного доступа. Читаться будет, а вот взаимодействовать не позволит.
Решение довольно простое: использовать элементы по назначению.
Если это должен быть список, нужно использовать в коде элемент, описывающий список;
если это кнопка, то это должна быть именно кнопка; если это ползунок, регулятор чего-либо, то это должен быть элемент ползунка, а не текст с анимацией при перетягивании.
В заключение хочу сказать, что разработка для Windows хоть и не существенно, но отличается от разработки для мобильных платформ, поэтому и особенности accessibility для Windows отличаются от особенностей для Android / Ios.
Речь пойдёт о реализации accessibility (специальных возможностей) в мобильном приложении.
Краткая предыстория
Недавно я от имени проекта «Доступная жизнь» начал помогать Яндексу в реализации accessibility их навигационных приложений.
Я столкнулся с тем, что многим не приходят на ум очевидные с моей точки зрения вещи: невидимые элементы на экране, прямой вывод речевых сообщений с помощью API программы экранного доступа и так далее.
Поэтому я решил всё это изложить в отдельной статье.
В общем, поехали.
Невидимые элементы
Проблема
В процессе работы над картами мы столкнулись с проблемой:
При нажатии на область экрана с картой приложение должно переключать режимы (точно уже не вспомню подробностей).
Для незрячего пользователя с программой экранного доступа это казалось бы простейшее действие становится невозможным.
Дело в том, что программы экранного доступа «видят» только конкретные объекты на экране: кнопки, текстовые блоки, поля ввода, регуляторы и списки. А в приложении Яндекс.Карты, нажатия на карту обрабатывались не как выбор объекта, а как касание определённой области экрана.
Решение
Решение довольно простое: сделать на экране кнопку без рамки, с прозрачным фоном и без видимого текста (нулевой шрифт, что не так эстетично с точки зрения программиста, или специальные атрибуты, отображающие текст только для программ экранного доступа, не выводя его на экран).
Этот подход шокировал и удивил программистов, однако на практике всё получилось, идея сработала и активно внедряется везде, где нужно обрабатывать прямые нажатия на область экрана.
П��ямой вывод речевых сообщений средствами самой програмы экранного доступа
Проблема
Ещё одной проблемой стало то, что иногда требуется вывести дополнительную информацию только для незрячего пользователя. Всплывающие сообщения в этом случае испортят дизайн и будут мешать остальным, а реализовывать отдельный режим приложения, в котором будут выводиться подобные сообщения, громоздко и нелогично.
Решение
Решение не столь очевидно, как в случае с невидимыми кнопками, но тоже лежит на поверхности.
Нужно использовать API самой программы экранного доступа для вывода сообщений. Это менее громоздко выглядит в коде программы, это не заставляет разработчика прилагать дополнительные усилия по созданию отдельных режимов, дополнительных настроек и т д.
Кстати, в случае использования API скрин-ридера даже не требуется проверять, включен ли он. Если программа запущена, она выведет сообщение с помощью синтезатора речи, выбранного пользователем. А если программа выключена, просто ничего не произойдёт, и обычный пользователь ничего не заметит.
Разделяй!
Проблема
Это скорее рекомендация, а не лайфхак, но упомянуть об этом я обязан.
Помните, что для программы экранного доступа на экране есть только объекты?
Так вот, тип объекта тоже имеет значение. На текст нельзя нажать, по её мнению, а кнопку нельзя скопировать. То есть, если таблица с настройками реализована как большой текстовый блок, который «ловит» нажатия на разные части себя, то такая таблица недоступна для программы экранного доступа. Читаться будет, а вот взаимодействовать не позволит.
Решение
Решение довольно простое: использовать элементы по назначению.
Если это должен быть список, нужно использовать в коде элемент, описывающий список;
если это кнопка, то это должна быть именно кнопка; если это ползунок, регулятор чего-либо, то это должен быть элемент ползунка, а не текст с анимацией при перетягивании.
Заключение
В заключение хочу сказать, что разработка для Windows хоть и не существенно, но отличается от разработки для мобильных платформ, поэтому и особенности accessibility для Windows отличаются от особенностей для Android / Ios.
