Location: Native Android Registration form
Description: The form elements on the Register screen are not properly labelled except for the Password field. If components are not properly labeled, the label will not be rendered properly in assistive technology or the association may not be visually discernible to users with cognitive or visual disabilities. In addition, the text below the edit fields are additional information that users may need to hear when landing on the edit fields. But currently, Talkback users have to swipe out of the field to even realize that there's text associated with it.
Auditor Note: Developers must ensure all form fields are properly labelled. To do this, developers must use the android:labelFor property. To programmatically associate the visual label and input field the setLabelFor() method should be set on the associated TextView element and the id of the input field (EditText). For the hint or additional information found below the edit fields, including error messages when they are displayed, developers must use the contentDescription property for the controls.
Internal Note: None
Before I start my review on this ticket, it would be better if we place a build on HockeyApp for to test/verify the changes you have made and also share his thoughts on 's queries.
I have uploaded the android build (2.11.0-a11y) on Hockey app having all the a11y changes which we have done for this year audit. I have also sent you a Hockey app invitation, you can access the build once you accept the invitation.
Mark is out on PTO we will need to wait until he returns
, cc: , ,
For a single input like email, VO focusing it two times. One time it says "Email, this is what you will use to login" and for the second time, it says "Email edit box". It would be good if can give focus once for an input and compile a comprehensive message for VO. Mark Sadecki Thoughts?
It's the native behavior of android's TextInputLayout control. If we try to customize it here it ought be customize on all other places of app where we are using TextInputLayout. We shall not do that.
There is no identification either VO is reading an instruction message or an error. It would be good we can add an identification for the error in VO. Mark Sadecki Thoughts?
Its a good improvement, as per discussed in DS we are going to cater that.
What will happen if there was an error on screen for any required field like email or full name, but the user did add some text and focus came back to the errored field by swiping up or down. Will VO include the error again or it will ignore it? If it will include error again then it would be super confusing for the VO user.
It will happen as you predict, It will read out old error which might be resolved. But it's not specific to a11y, first it needs to add error updation feature on registration page.
Dev Update: After spending quite a lot of time on adding proper a11y behavior on the Register screen following are our (mine & 's) findings:
The points mentioned in the comment above have all been implemented in the PR for this ticket.
After we implemented what was required, during regression we started to encounter some weird behavior due to the EditText fields on our screen.
The accessibility flow worked just fine if we didn't double tap on an EditText field and kept changing the focus on any view on the screen.
The problem came, when we had double tapped on atleast one of the EditText fields e.g. Password and then we moved the focus to the Country select box.
Upon selecting a country from the dropdown, the native behavior of Android system tells us to reset all the focuses on screen and upon right swipe, screen's title should be focused. But in our case when the dropdown dismissed, the system started to focus on whatever EditText field it felt was focused last time.
Last night, we tried quite a lot of workarounds; pair-programming the whole time to get this issue fixed. But for now this issue is still there and we are actively working to fix it.
cc , ,