Accessible Nested Active Elements in Android Apps

accessible nested active elements in android apps

Let’s deep dive into talkback accessibility and a common violation around nested active elements in Android Apps. We’ll talk about best practices and discuss how Deque has developed a rule to automatically analyze and scan for this issue. One of the cool things about the Android accessibility ecosystem is when we see emulators, they work essentially exactly like devices.

Now let’s discuss why nesting active elements are bad. When nesting of the element together, it becomes very unclear what type of thing we’re trying to accomplish as a screen reader user.

Picture that we’re blind and we are going through this app in the different way we can navigate. Let see the example if you touch the explore user, you will finding elements that are nested within other elements. This is confusing because if you drag your finger across the screen you can end up hitting multiple touch targets within the same touch target. And the other problem you get with this is when a user is navigating via tabs.

My swipe navigation vs my tab navigation actually ends up being different because sometimes things are focusable and sometimes things are accessibility focusable. My keyboard and my swipe navigation are ending up being the different type of touch targets. we just hit the right arrow button and we do different things than if we hit the tab key.

To fix the issue we need to follow the following steps:-

  1. Be able to identify the issue
  2. We should understand exactly why it’s happening.

Source [ ]

Fixing inaccessible nested active elements
Now let’s see how to use accessibility tools to find this problem. In the source link, we can see the screen where we can focus and as scroll over the screenshot we’ll see the different areas of accessibility focus. If we open the developer tools we can start to analyze these controls. Let’s check into the accessibility property of one of these controls, there are a couple of switches within a linear layout. When we’re scrolling over the switches.

  • importantForAccessibility = true
  • clickable = true

We have two views here that are clickable, both of these switches are clickable and also the linear layout. They all are clickable and focusable and that is actually why they are being accessibility-focused. When we look at the text we get null text blocking off, text blocking off but focussed true and clickable true. This is confusing based on what we discussed above because not only we going to try and activate one of these controls but when we focus this bigger rectangle we activate it.

Implications of Nested Active Elements
The first question comes in mind what does activating a collection of elements even mean? That’s a confusing thing and we can see we’ve marked up this demo here simulating this inaccessible situation, but we can actually end up seeing this in a lot of different things. One of the places we can see this is coming from some hybrid libraries that are potentially reliant on web view. When the review ends up being clickable and also containing other clickable elements, it’s a very confusing situation to be a talkback user who’s hearing that and they can take action with some element which is also composed of other actionable elements.

Another place where we can see this create accessibility problems is for switch control. If we’re a switch control user and we’re cycling through the active elements on the screen we end up at minimum having an unnecessary target, which if we have a one second delay on scanning is frustrating. At the same time, we can end up activating something that don’t intend to activate or that has an undefined behavior. In this case, the solution would be to make this outline but not focusable.

Now it’s time to the conclusion as we see the nesting elements together can provide a more seamless user experience. It limits the overall number of on-screen focusable targets for Screen Reader users, which is really good. However, if two elements provide for an action, they must be separate. Even if individual targets do eventually get their own focus, nesting active elements into one target are confusing and create undefined behavior if a user should attempt to activate such a target. Also, nesting overly nesting informative controls can lead to long announcements and a lack of structural feel to our application. Let separate controls and nest elements together when we need to create relationships amongst groups of controls.

Leave a Reply

Your email address will not be published. Required fields are marked *

we accept payment through

Social Media Auto Publish Powered By :