Android has a powerful built-in accessibility system that allows people to use applications through an alternative interaction mode called “focus navigation.” Rather than directly touching the screen to activate an element, focus navigation allows people who use accessibility services such as screen readers, physical switch devices, refreshable Braille displays, or voice control to focus on and activate different elements of an interface.
Although focus navigation is built into the Android platform, many engineers don’t consider it when designing, building, and testing their applications. This can lead to a variety of problems, such as the inability to activate buttons or content being announced in the wrong order, which can be difficult to debug.
Accessibility is important to our work at Facebook, so to help with the above challenges we’ve added support for accessibility properties toStetho, our open source Android debugging tool. Now engineers can easily find elements that aren’t accessible through focus navigation, understand the reasons behind the bug, and implement a fix.
Let’s go over an example of a UI with a focus navigation issue and show how Stetho makes the problem easier to debug.
Screenshot showing the currently focused element highlighted in green. Example problem
In this fairly simple UI, there are two TextView s and a Button inside a LinearLayout . The LinearLayout is found inside a ListView .
[/code] Which views would you expect to be focusable? If you answered "the TextView s and the Button ," you'd be wrong. The correct answer is the Button and the LinearLayout .
Since focus will first fall on the LinearLayout , screen reader users will hear the content of both TextView s before the Button that is between them. This could cause confusion if the context of the button's action depended on being preceded by the first heading. For example, if the button said “Buy Now,” and the headings were the names of two different products, a user may not understand which product they would be purchasing by clicking the button. So why is this the case, how can we fix it, and most importantly, how could we have predicted this would happen?
Well, you could run every view through this flow chart, and keep note of what is focusable and what isn't.
A flow chart showing exactly why a given view may or may not be focusable. Stetho
Or you could use Stetho! Stetho is an Android debugging platform that we open sourced last year . Since then, we've added a ton of new features, including accessibility inspection.