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
Is your feature request related to a problem? Please describe.
When a TextInputLayout has helperText enabled set to true and appropriate texts assigned to the attribute, Talkback reads aloud the helperText on each character input and deletion. When I have it showing, talkback highlights the entire textinputlayout, only reading the helperText but not reading the actual hint nor input of the textinputedittext until an additional swipe to navigate to the field is executed. I've tried making a custom AccessbilityDelegate to work around these default behavior, but I've come across scenario as well where I cannot make the helper text non-accessible like I would on a view element with View.importantForAccessibility attribute.
Describe the solution you'd like
I like the accessbilitydelegate idea I had so I'm keeping it; but to simulate a better talkback experience, I opted to removing helperText entirely when talkback is enabled and using a custom textview for similar effect, but I can switch off its accessibility and add its description to the custom accessibilitydelegate for the textinputlayout. Naturally, this created a few unsavory conditions I had to make to balance between non-talkback and talkback modes; same conditons if not more for error handling.
Is your feature request related to a problem? Please describe.
When a TextInputLayout has helperText enabled set to true and appropriate texts assigned to the attribute, Talkback reads aloud the helperText on each character input and deletion. When I have it showing, talkback highlights the entire textinputlayout, only reading the helperText but not reading the actual hint nor input of the textinputedittext until an additional swipe to navigate to the field is executed. I've tried making a custom AccessbilityDelegate to work around these default behavior, but I've come across scenario as well where I cannot make the helper text non-accessible like I would on a view element with View.importantForAccessibility attribute.
Describe the solution you'd like
I like the accessbilitydelegate idea I had so I'm keeping it; but to simulate a better talkback experience, I opted to removing helperText entirely when talkback is enabled and using a custom textview for similar effect, but I can switch off its accessibility and add its description to the custom accessibilitydelegate for the textinputlayout. Naturally, this created a few unsavory conditions I had to make to balance between non-talkback and talkback modes; same conditons if not more for error handling.
We also happily accept pull requests.
The text was updated successfully, but these errors were encountered: