Отправляет email-рассылки с помощью сервиса Sendsay

[prg] Android. Следует ли стремиться к тому,чтобы кастомные кнопки определялись как кнопки.

kC7ayAwrV1IWas3sCWttfMefOMVhl2WcUoGm4cAGRVyo85roSYGSiUrz//pfjaQg0P9YbTWToiaG
a
WsFRiHInoAFMIK7JdxNo=;

Приветствую всех.

Вопрос состоит в том, следует ли заставить Talkback считать кастомную
кнопку обычной нативной кнопкой? То есть нужно ли подменить реальное
имя класса именем класса нативной кнопки, чтобы talkback называл её кнопкой?

Если бы мы говорили про HTML, я бы был уверен, что да, что для кастомной
кнопки нужно установить role="button", но с Android все как-то менее
очевидно.

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

Кроме того, в этом вопросе:

android - How to tell TalkBack a custom view is being used as a button -
Stack Overflow
<https://stackoverflow.com/questions/47716961/how-to-tell-talkback-a-custom-view-is-being-used-as-a-button>

Отвечающий утверждает, что обьявление кнопки, что она кнопка является
устаревшей функцией.

Ответы:

Приветствую всех!

В общем случае это сильно зависит от ...
1. пользователей, на которых рассчитано приложение: как часто они переходят
с Android на ПК, то есть меняют скринридеры; насколько сильно привязаны к
понятию "роль" или типам элементов UI, таким как "кнопка", "список",
"радиокнопка", "флажок" и т.п.;
2. функциональности, реализуемой кастомным элементом UI: существует ли в
списке "ролей" такая роль, которая достаточно хорошо отражает функциональные
возможности кастомного элемента.

Android Accessibility API не реализует понятие "роли" в явном виде.
Отчасти поэтому
TalkBack использует java-класс элемента, чтобы озвучить его тип в понятиях,
привычных для пользователей программ экранного доступа.
По крайней мере, так было, когда я ещё интересовался исходниками TalkBack.
В то же время TalkBack предоставляет доступ к меню "действий", которые
пользователь может выполнить при помощи элемента.
В Android Accessibility API явное предпочтение отдаётся понятию "действие"
(Action). Для пользователя спец. возможностей элемент UI характеризуется
набором действий, которые пользователь может выполнить при помощи этого
элемента. вВ api level 21 действия выделены в отдельный класс
AccessibilityNodeInfo.AccessibilityAction, что (imo) свидетельствует о
дальнейшем развитии концепции "действий".
Плюс к этому методы AccessibilityNodeInfo, позволяющие получить
представления о возможностях (свойствах) элемента UI, что позволяет
скринридеру предоставить пользователю более подробное представление о
назначении элемента, не ограничиваясь предопределённостью "ролей".
В итоге: "роли" (тип элемента UI) позволяют пользователю сразу понять
предопределённый функционал элемента, а "действия" требуют первоначально
больше времени на изучение возможностей всех элементов UI, присутствующих в
приложении, но не ограничивают их функциональность.
Если "кнопка" -- достаточная характеристика для кастомной кнопки, тогда есть
смысл сделать её озвучиваемой как "кнопка".

Успехов. Анатолий.

Исходное сообщение > следует ли заставить Talkback считать кастомную

кнопкой?

Ответить   "i_chay" Tue, 18 Aug 2020 15:19:26 +0300 (#3656454)