CSUN Recap – Testing Mobile Apps: Tools, Techniques, and Best Practices – Part 2 (Android)

This article is based on a talk delivered at CSUN 2025, by accessibility experts Laurie Pagano, Carolina Crespo, and John Lilly.

Testing mobile apps can be difficult because we can’t just inspect the HTML like we can with websites. We do have a few techniques to share with you below in our tests. We will start with testing with a screen reader, move to using a keyboard for navigation, a color contrast tool, and finally inspector applications. We will first go over some common testing techniques. At the end, we will validate some of the issues that we encountered using an accessibility inspector tool. These tools can be used to validate certain issues like missing name, role, and values, as well as some other issues dealing with resizing text and target size.

For the CSUN Assistive Technology Conference (CSUN 2025), we developed an iOS app and an Android app to demo some accessibility issues commonly found on mobile apps and show some testing techniques for identifying those issues. There are a few software and hardware tools at your disposal for identifying accessibility issues, all of which can be used on any app installed on the device.

Before we dive into some testing and testing techniques, it’s important to understand the purpose of the demo app and the layout. The iOS and Android apps that we developed are essentially the same, with each one following its respective platform design philosophies.

Today’s article is focused on the Android app and how to test it.

The app consists of the following elements from top to bottom:

• Logo with the “Demo app” text
• “Sign in” heading
• Email address and password fields
• “Forgot password” control
• “Remember me” control
• “Sign in” button
• Text containing terms and conditions
• “Contact Us” and “Careers” link

Before starting the test cases, let’s get the captions displayed in Android: Settings > Accessibility > TalkBack > Settings > Advanced settings > Developer settings, then turning on the Display speech output setting.

Testing With a Screen Reader

Listening to the app content can help you understand the experience of a blind or low-vision person. Using the screen reader, we can evaluate the presence of each image’s alternative text and its quality, the names of controls, the semantics of views, and the relationship between them.

Test for Images

The objective of this test is to find if the logo image has alternative text and, if so, the quality of the alternative text.

• Test:
  • Enable TalkBack
  • Swipe right or explore by touch to reach logo image
• Expected: TalkBack announces “Demo App, Image”
• Actual: TalkBack announces “Unlabelled. Image.”
• Related WCAG SC: 1.1.1 Non-text Content (Level A)

Test for Headings

The objective of this test is to evaluate the structure of the screen to know if the structural information that is communicated visually is also communicated to screen reader users.

• Test:
  • Enable TalkBack
  • Swipe right or explore by touch to reach “Sign In” text
• Expected: TalkBack announces “Sign In, Heading”
• Actual: TalkBack announces only “Sign In”
• Related WCAG SC: 1.3.1 Info and Relationships (Level A)

Test for Accessible Names

The objective of the test is to evaluate whether the accessible names of controls match their visual labels, which ensures that users who use speech to interact with their devices will recognize the controls.

• Test:
  • Enable TalkBack
  • Swipe right or explore by touch to reach “Remember me”
• Expected: TalkBack announces “Remember me” to match the visible label
• Actual: TalkBack announces “Save my information”
• Related WCAG SC: 2.5.3 Label in Name (Level A)

Test for Button Roles

The objective of this test is to confirm that a button, which is visually communicated as an interactive element, is also communicated as such to screen readers users. In this case, screen reader users expect to hear the name, role, and value of the interactive element.

• Test:
  • Enable TalkBack
  • Swipe right or explore to reach “Sign In” control
  • Change the navigation mode to “word” to determine if the “BUTTON” announcement is part of the accessible name
• Expected: TalkBack announces “Sign In, Button” with the B capitalized
• Actual: TalkBack announces “Sign In BUTTON” with BUTTON in all caps
• Related WCAG SC: 4.1.2 Name, Role, Value (Level A)

Testing With a Keyboard

Testing your application with a keyboard ensures that all interactive elements are usable without a pointer or touchscreen. This approach not only meets accessibility standards set by WCAG but also enhances the overall user experience for everyone.

Test for Elements Not in the Focus Order

The objective of this test is to evaluate whether all the interactive elements of the screen can be reached using a keyboard or alternate input.

• Test:
  • Connect a keyboard
  • Use TAB and/or arrows to reach “Forgot password”
• Expected: Keyboard can reach and activate “Forgot Password?”
• Actual: Keyboard skips over “Forgot Password?”
• Related WCAG SC: 2.1.1 Keyboard (Level A)

Test for Visual Focus Indication

The objective of this test is to have a visual focus indicator for each interactive element on the screen. This helps users with mobility disabilities or those who rely on keyboard navigation; clear and visible focus indicators are essential. They provide a visual confirmation of the active element, enhancing navigation and interaction within a website or application.

• Test:
  • Connect a keyboard
  • Use TAB and/or arrows to reach “Sign in”
• Expected: Visible indication of when “Sign in” has focus
• Actual: Not clear when “Sign in” has focus
• Related WCAG SC: 2.4.7 Focus Visible (Level AA)

Testing Color Contrast

The intent of this test is to provide enough contrast between text and its background, so that it can be read by people with moderately low vision or impaired contrast perception, without the use of contrast-enhancing assistive technology.

Tests for color contrast are very similar to those on web. We use TPGi’s free Colour Contrast Analyser (CCA) to evaluate that content—including text and visual elements—is perceivable for individuals with color-blindness or low vision impairments.

The color contrast checker can be used on websites, during app development, when designing social media graphics, PowerPoint slides, PDFs, InDesign files, and almost anything!

Both the Foreground and Background display include an eye dropper icon that lets the user select a color on a page or screen and display the value of the color in HEX format by default.

CCA currently displays contrast ratio results according to WCAG 2.0, 2.1, and 2.2.

You can move from color failure to conformance with the color sliders control. Add RGB, HSV and HSL formats to the display. Easily manipulate the sliders to adjust the color values of both the Foreground and Background to achieve a contrast level that satisfies your target level WCAG Success Criteria.

Colour Contrast Analyser is available as a free download.

Capturing the Screen Output

• Take a screenshot
• There’s a handy tool for Android called scrcpy. This requires USB debugging to be enabled, but it mirrors the phone on the computer and allows the user to interact with the device through the computer.

Test for Focus Contrast

The objective of the test is to evaluate if the contrast between a custom visual focus indicator and its background is enough for low-vision and colorblind users without using extra contrast-enhancing assistive technology.

• Test:
  • Connect a keyboard
  • Use TAB and/or arrows to reach “Remember me”
  • Use CCA to evaluate colors
• Expected: Uses the default indicator or one with a 3:1 contrast ratio
• Actual: Custom focus indicator has a 1.3:1 contrast ratio
• Related WCAG SC: 1.4.11 Non-text Contrast (Level AA)

Testing Text Resize

Testing with larger text, or increasing font size, is important for accessibility and readability, ensuring that content is easily accessible to a wider audience, including those with visual impairments, elderly people, or people who simply prefer larger text.

Test with Larger Text

The objective of this test is to confirm that all text resizes and remains readable.

• Test:
  • Set Font size setting to the largest size
• Expected: All text resizes and remains available
• Actual: Content is cut off and unable to be viewed
• Related WCAG SC: 1.4.4 Resize Text (Level AA)

Validate Issues With the Android Accessibility Inspector

During our session on mobile testing techniques at CSUN, we showed off a new open-source application called the Android Accessibility Inspector. This application was developed by TPGi’s John Lilly and is similar to the Xcode Accessibility Inspector for iOS, except that it’s for Android, and is available for both Windows and macOS.

The Android Accessibility Inspector goes a little bit above and beyond the features of Xcode, in that it allows you to see the full accessibility tree of any app, as well as select views to inspect. It is accessing the accessibility tree using the AccessibilityService API, which is the same API that TalkBack uses to announce information. You can think of it as “seeing” the same thing that TalkBack “sees”, except maybe a little more. It can also see views that are hidden from TalkBack, in case you want to review information for certain views that aren’t being announced by TalkBack. It can also detect possible issues with 2.5.8 Target Size (Minimum).

Now that you have a little background on the Android Accessibility Inspector, let’s go over some of the tests that we performed.

2.5.8 Target Size (Minimum)

The Android Accessibility Inspector can detect potential target size issues. When the setting is enabled (is it on by default), it will show a red circle around an element that might be failing this success criteria. First, it is checking to see which views are smaller than 24x24dp. Second, for any views that are smaller than 24x24dp, it is checking to see if the center of the clickable area overlaps with the center of other clickable areas in a 12dp radius. If it does, then it draws a circle on the view in the screenshot. It will also include a badge next to the item in the view hierarchy. If you are a screen reader user, you can navigate by image to find the badge icons indicating a potential issue.

In the screenshot below, the “Contact Us” and “Careers” controls in the demo app are failing the conditions for Target Size (Minimum). There are red circles that overlap each other in the screenshot view, a badge indicating the issue is on the “Contact Us” button in the view hierarchy, and the “scaled size” property of the view is 68.57×19.43dp, which is smaller than 24x24dp.

1.1.1 Non-text Content

The next test we performed was a validation of the 1.1.1 Non-text Content issue with the “Demo App” image. During our screen reader testing, we found that the image was announced as “Unlabelled. Image.”. If we inspect that image, the inspector shows that it has an empty “content description” property. You can think of a content description as the Android equivalent of an aria-label attribute in HTML. It provides a non-visible label or name to a view. Since this property is empty, TalkBack is announcing the image as “Unlabelled”.

1.3.1 Info and Relationships

We looked at the “Sign In” heading next. This text is acting as a visual heading to the form, but TalkBack is not announcing it as a heading. This is because the heading property is not set to true. This is a property that any view can have. If this property were set to true, TalkBack would announce “heading”, and in this case, it would announce “Sign In, heading”. Since it does not announce that the text is a heading, it is failing 1.3.1 Info and Relationships.

2.5.3 Label in Name

When we were testing with TalkBack, the “Remember me” checkbox was being announced as “Save my information”. Since the visible label is not contained in the accessible name, this is a failure of 2.5.3 Label in Name. We can verify this using the inspector by selecting one of the sibling views to the CheckBox view. Since this demo app was made using JetPack Compose, the accessibility tree can be a little confusing to follow, but a few views above the CheckBox view is a View that has a content description of “Save my information”. This is where TalkBack is getting the accessible name for the control. We would expect that View to not be there so that TalkBack can get the name from the visible text, or we would expect this content description to be “Remember me” or at least contain “Remember me”.

2.1.1 Keyboard

We noticed that the “Forgot password” control doesn’t receive keyboard focus. Keyboard users are unable to access this control, so it is a failure of 2.1.1 Keyboard. In the inspector, we can select the TextView that has a text property of “Forgot password”. We can see that this does not have a “focusable” property under the “properties” row. The “properties” can contain several different view properties such as focusable, clickable, and checkable, to name a few. Using the inspector to test for focusable controls can be a bit hit-or-miss due to the way Android handles focus. We’ve seen instances where a control is focusable, but it is skipped in the focus order due to a custom focus order. However, the inspector can be used to eliminate possible issues like “is this view even focusable?”

4.1.2 Name, Role, Value

The last item we needed to inspect was the “Sign In” button. TalkBack was announcing the button as “Sign In BUTTON” with “button” in all caps. This is not the normal behavior for TalkBack so we know that something is going on. When we inspect the button, it has a tooltip property of “BUTTON”. This is where TalkBack is getting the announcement from. The tooltip property is a property that you can set for any Android View. Since the role is not being applied as expected, assistive technologies like screen readers, Braille displays, and speech recognition may not recognize the control as an actual button. This is very important for Android since anyone can make their own accessibility service like a custom screen reader. Platform standards need to be followed so that a custom accessibility service behaves as expected. This is a failure of 4.1.2 Name, Role, Value.

If you set it using View.setTooltipText(), the view will have a traditional tooltip. But you can also set the tooltip property in the accessibility node for the view using AccessibilityNodeInfo.setTooltipText(). This will set the value of the tooltip so that it won’t visually appear, but it will be announced by TalkBack. Many cross-platform frameworks like React Native or Flutter use the tooltip property to provide additional information for TalkBack users. Instead of the tooltip property, we would expect to see “Button” under the role property (ideally) or the role description property. Keep in mind that when the role description property is used, TalkBack will announce whatever text is provided. For example, if you provide a value of “sandwich” to the property, TalkBack will announce the element with a “sandwich” role. If your app is using this property for custom roles, translations will also need to be considered since TalkBack will not automatically translate the role like it would if using the standard role property.

Wrapping up

Testing mobile apps is quite a bit different than websites because you can’t see the underlying HTML like you can for a web page. These are some tools and techniques that you can use to make it easier to find accessibility issues in mobile apps. This article completes our CSUN presentation recap for iOS and Android. We also have the presentation slides available for download. Don’t forget to visit the iOS article if you missed it!