Scrolling to error with accessibility on Android

Question

I have a form with accessibility. When the user clicks on the button at the bottom of the form and there is an invalid EditText field (e.g. it is empty), I would like the error to be announced and for the view to scroll to that EditText field. I have attempted several methods, but I encounter the issue that when I scroll to that part of the form, Talkback drags the focus with the scrolling and announces the last view.

Here is what I have tried:

XML:

android:importantForAccessibility="yes"
android:accessibilityLiveRegion="assertive"

Programmatically:

field.requestFocus()
field.sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_FOCUSED)
//scrollView.smoothScrollTo(0, field.bottom) - older try

I have also tried to clear the focus from other views (which didn't work), disable Talkback before scrolling and enable it after (which I couldn't), and scroll to the point that the field is at the bottom of the screen so that Talkback will announce it (if the field is at the top of the screen, you can't scroll there). How does it work in your apps?

Answer 1

This is a simple answer with many implications - I'm separating the two so you can decide how much depth you'd like to go into.

Answer

1. Do not ever under any circumstances turn off anyone's assistive tech for them. Ever.
2. Don't change a users focus (WCAG 3.2.1 "On Input")
3. The more "standard" error notifiers you use, the easier it will be for you and the user
   1. Use the built in ones that come with EditText

   // automatically gets announced by screen reader and has a built in image
   view.error = "Descriptive error"
   

   2. If you must use a LiveRegion:

   <!-- every time the text property is changed it will be announced by TalkBack -->
   <!-- You will need to add your own styling and remember you can only give one -->
   <!-- element of feedback at a time -->
   <TextView
       android:id="@+id/error"
       android:accessibilityLiveRegion="assertive"
       android:layout_width="match_parent"
       android:layout_height="wrap_content"/>
   

Explanation

1. There are many types of assistive technologies on Android, not just TalkBack. Users may have custom services running and if we as developers start messing with them, we interfere with those users. Additionally, the assitive tech they are using is the very thing giving them independence. Don't take that away from people, even for a second.
2. Changing focus on behalf of users causes confusion and frustration. The Web Content Accessibility Guidelines specifically state you should not so this:

Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

A change of context being defined as such:

Changes in context include changes of:

1. user agent;
2. viewport;
3. focus;
4. content that changes the meaning of the Web page

There may be times where we have to adjust focus because the system is consistently behaving strangely (normally because we're loading components in a strange way - e.g. dynamically from some web call - but even here careful consideration should be taken)

3. Google has done a lot of work to make sure this is easy for developers by providing standardized API's (Error fields and LiveRegions) - inform the user, but let the user navigate to where they need to fix any errors. Remember that there are many assistive technologies other than Screen Readers - Magnification, Switch Access, Voice Access, etc.

Final words

1. Test your app with TalkBack - when you turn it on for the first time there is a tutorial. I have also made a cheat sheet to help you and I have made a desktop tool and an Android Studio plugin for checking different accessibility aspects on Android.

2. Less is more, as long as you remember: Consistency (standard API's), Configurability (Giving users multiple means) and Consent (give the user the choice)

3. Test your app with real users. There is a great company called Fable that do accessibility testing of apps with users who have different disabilities. This is the best feedback you can get.

4. Just check your styles in dark and light mode.