Details
-
Bug
-
Resolution: Unresolved
-
P2: Important
-
None
-
6.6.0
-
None
-
Tested on a Nokia 8.1 with Android 11 and Samsung A53 with Android 13.
Description
When exploring a Qt app on android with the talkback screenreader, none of the widget's roles are being announced. Whilst any Qt app seems to show the issue, for the purposes of this bug report I will take the hello_speak example from the standard Qt examples.
In that example I would expect talkback to identify the speak button as a button, however it does not identify any standard type for that widget. However talkback does correctly identify the widget has the clickable action available. The hello_speak example has a edit box where text may be entered, again I would expect talkback to identify it as a edit control but again it identifies no control type. The edit type not being recognised is even more of an issue as talkback does not report information correctly when attempting to edit the text and so makes it difficult to impossible for a talkback user to use Qt edit widgets. There are similar issues for the sliders and comboboxes in the hello_speak example.
I have not found any official Android documentation describing how widgets should expose their role, but I have found some information online which indicates that for a standard role the AccessibleNodeInfo className property should be set to the class name of the standard Android widget you want your control to be recognised as. So for example if you want it to be recognised as a button one would use the following kotlin code:
ViewCompat.setAccessibilityDelegate(view, object : AccessibilityDelegateCompat() {
override fun onInitializeAccessibilityNodeInfo(
host: View,
info: AccessibilityNodeInfoCompat
) {
super.onInitializeAccessibilityNodeInfo(host, info)
info.className = Button::class.java.name
{{ }}}
})
If needing to set the role to something not covered by the standard types then in the AccessibleNodeInfoCompat the roleDescription property can be set to a string describing the role:
override fun onInitializeAccessibilityNodeInfo(
host: View?,
info: AccessibilityNodeInfoCompat?
)
Here is an article which seems to discuss this and where I got the code snippets https://medium.com/@gulshansutey/overcome-android-talkbacks-disabilities-9e51030518d7 although I have found stackoverflow questions on this where the asker seems to think these solutions answer their question.
To me this issue is significant enough that where Android accessibility is needed I would not be able to use or recommend Qt as the apps at best give a poor user experience and with some widgets (eg. edit boxes) it would be unusable with a screen reader.