You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed within the Acceptance Criteria for Buttons within Android that "Double tap to activate" is enough to signify the role. However, this is a usage hint which can be turned off within Talkback settings by the user. I therefore propose an update to the guidance to reflect that setRoleDescription or setClassName as a way to provide a role to custom button elements to ensure Name, Role, Value is conformant.
Role
On Android, you can manually set a role via the setRoleDescription method of AccessibilityNodeInfoCompat. It is usually better to use the setClassName method to inherit the role of an existing element. For example, set Button::class.java.name if an element should behave like a button.
Hiya, firstly - awesome resource! It's really useful. 😀
I've noticed within the Acceptance Criteria for Buttons within Android that "Double tap to activate" is enough to signify the role. However, this is a usage hint which can be turned off within Talkback settings by the user. I therefore propose an update to the guidance to reflect that
setRoleDescription
orsetClassName
as a way to provide a role to custom button elements to ensure Name, Role, Value is conformant.Role
On Android, you can manually set a role via the setRoleDescription method of AccessibilityNodeInfoCompat. It is usually better to use the setClassName method to inherit the role of an existing element. For example, set Button::class.java.name if an element should behave like a button.
Credit for above: AAPT-ORG Code Examples
That is all. Keep up the great work.
The text was updated successfully, but these errors were encountered: