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

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’ll start with testing with a screen reader, move to using a keyboard for navigation, a color contrast tool, and finally inspector applications.

We’ll first go over some common testing techniques. At the end, we’ll 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 demonstrate 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 iOS app and how to test it.

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

• A logo with the “Demo app” text
• “Sign in” heading
• Username and password fields
• “Forgot password” control
• “Remember username” or “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 iOS. You can enable the setting by going to Settings > Accessibility > VoiceOver, then turning on the Caption Panel 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 reading order, the semantics of views, and the relationship between them.

Test for Images

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

• Test:
  • Enable VoiceOver
  • Swipe right or explore by touch to reach the logo image
• Expected: VoiceOver announces “Demo App, Image”
• Actual: VoiceOver announces a file name: “logo underscore 1 2 3 4 underscore png 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 VoiceOver
  • Swipe right or explore by touch to reach the “Sign In” text
• Expected: VoiceOver announces “Sign In, Heading”
• Actual: VoiceOver announces only “Sign In”
• Related WCAG SC: 1.3.1 Info and Relationships (Level A)

Test for Reading Order

The objective of this test is to evaluate the structure of the screen as well, ensuring that the visual or logical order of the elements is communicated in the same order to screen reader users. Sometimes it’s okay if the order is not exactly the same as the visual design, as long as the meaning of the content isn’t modified.

• Test:
  • Enable VoiceOver
  • Swipe right to move through the screen content
• Expected: VoiceOver follows a logical reading order
• Actual: VoiceOver moves erratically through the screen
• Related WCAG SC: 1.3.2 Meaningful Sequence (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 VoiceOver
  • Swipe right or explore by touch to reach the “Sign In” control
  • Change the navigation mode to “word” to determine if the “BUTTON” announcement is part of the accessible name
• Expected: VoiceOver announces “Sign In, Button” , button with only B capitalized
• Actual: VoiceOver announces “Sign In BUTTON” , 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 Focus Order

The objective of this test is to evaluate the order of the screen content as well, ensuring that the order of the interactive elements is communicated in a logical order to keyboard and screen reader users. Again, it’s okay if the order is not exactly the same as the visual design, as long as the meaning of the content is not adversely affected.

• Test:
  • Connect a keyboard and enable Full Keyboard Access
  • Use TAB, CTRL+TAB, and/or arrows to navigate
• Expected: Keyboard focus follows a logical order
• Actual: Keyboard focus moves erratically through the screen
• Related WCAG SC: 2.4.3 Focus Order (Level A)

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 an alternative input device.

• Test:
  • Connect a keyboard and enable Full Keyboard Access
  • Use TAB, CTRL+TAB, and/or arrows to navigate
• 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 Static Text Receiving Focus

The objective of this test is to confirm that only the interactive elements of the screen are in focus order.

• Test:
  • Connect a keyboard and enable Full Keyboard Access
  • Use TAB, CTRL+TAB, and/or arrows to reach Terms content
• Expected: Keyboard reaches only interactive or actionable elements
• Actual: Keyboard focus reaches “Please read this…” text
• Related WCAG SC: 2.4.3 Focus Order (Level A)

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:
  • Turn on Larger Accessibility Sizes
  • Set size setting to the third-largest size (AX3)
• Expected: All text resizes and remains available
• Actual: Content is truncated (…) and unable to be viewed
• Related WCAG SC: 1.4.4 Resize Text (Level AA)

Testing Color Contrast

The intent of this test is to ensure 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 the web. We use TPGi’s free Colour Contrast Analyser (CCA) to evaluate that content—including text and visual elements—is perceivable for individuals with a color vision deficiency (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
• Mirror your iPhone with QuickTime Player
  • A quick note about QuickTime player. QuickTime applies a color or gamma shift to the phone display. This can throw the colors off a little bit and make something like pure white (#FFFFFF), show up as slightly off (#FFFEFF). This doesn’t have a big impact on determining the color contrast ratio, but if you’re looking for colors as close as possible, keep this in mind and stick with screenshots.
  • macOS Sequoia allows you to mirror iPhones directly to the computer.

Test for Text Color Contrast Ratio

The objective of this test is to evaluate if the contrast between text and its background is enough for users with low vision and color vision deficiencies without using extra contrast-enhancing assistive technology.

• Test:
  • Open Colour Contrast Analyser
  • Enter color values or use dropper to select them
• Expected: Text has a contrast ratio of at least 4.5:1
• Actual: Text has a 3.7:1 contrast ratio against background
• Related WCAG SC: 1.4.3 Contrast (Minimum) (Level AA)

Testing Orientation

Ensuring that content can be used in both portrait and landscape modes makes it more accessible to a broader range of users, benefiting users with disabilities or personal preferences. For example, a user in a wheelchair may have their device mounted in a certain orientation and not be able to physically rotate it. If the app does not support the orientation that their device is mounted in, they will not be able to use the device.

Test for orientation

The goal of this test is to determine if the app can be used in both portrait and landscape modes.

• Test:
  • Rotate the phone to landscape orientation
• Expected: The app content displays properly in both portrait and landscape orientation
• Actual: The app content is now sideways
• Related WCAG SC: 1.3.4 Orientation (Level AA)

Validate Issues with the Xcode Accessibility Inspector for iOS

The Xcode Accessibility Inspector is an application made by Apple that is available on all macOS devices. It’s included as part of Xcode and can be used to inspect the accessibility properties of any app including apps on physical devices connected to the computer through USB. More information for setting up the Xcode Accessibility Inspector can be found in Apple’s developer documentation on the subject.

2.5.8 Target Size (Minimum)

The Xcode Accessibility Inspector has an audit function where it will scan the current screen for potential accessibility issues. This can include issues like the target size being too small or text not expanding correctly when text is resized. Clicking on the “audit” button to select the audit view and then selecting “Run audit” will start these checks. It can take a few seconds to complete.

After running the audit, the tool shows that there are some issues with the target size being too small. This is measuring for a minimum size of 48x48pt, which is larger than the 24x24pt requirements that 2.5.8 Target Size (Minimum) needs. It can be a good check to see what targets might also affect WCAG conformance but going above and beyond WCAG is never a bad thing if you just want to target 48×48.

Our audit is showing a few issues with “Hit area is too small.” These are issues with the target size. Expanding those will show you a screenshot of the view and highlight the view on the phone screen.

1.4.4 Resize Text

The Xcode Accessibility Inspector can also detect possible issues with 1.4.4 Resize Text. After running an audit, it may show “Text Clipped” issues. These appear when a view hasn’t been developed to expand to allow the text to resize properly. Our app lost content when the text was resized, and the inspector flagged this as three possible issues in the audit.

1.1.1 Non-text Content

During our manual test, we found that the “Demo App” image didn’t have a text alternative. It was announced as “logo_1234_png”, which isn’t particularly helpful. It should announce “Demo app”, which is the same information that the image provides visually. This was a failure of 1.1.1 Non-text Content. When using the “inspect a target” feature on the image, the label of the control shows as “logo_1234_png”. For this to be announced correctly, we would expect that value to be “Demo app”.

1.3.1 Info and Relationships

We noticed that the “Sign In” heading was not being announced as a heading by VoiceOver. Since this text is acting as a heading for the “Sign In” form, it should be identified as a heading. After inspecting the text, we see that it does not have a “header” trait under the “Traits” properties. This trait tells VoiceOver to announce the element as a heading. Since it is not, it’s failing 1.3.1 Info and Relationships.

4.1.2 Name, Role, Value

The “Sign In” button was being announced as “Sign In BUTTON”. Since “BUTTON” is in all caps, we knew that something was going on here. Inspecting the button shows us that the “BUTTON” text is being added as part of the “Label” property. It’s not correct to add the role as part of the accessible name, since that is not what assistive technology uses to identify the role. What we would expect to see for this one is that the “BUTTON” text would not be part of the label property, but rather that we would see “Button” in the traits. If you are looking for roles when inspecting iOS apps, they must always appear in the “trait” property in the inspector. This is a failure of 4.1.2 Name, Role, Value.

Conclusion

These are all the tricks and advice we have for iOS testing, at least today. We discussed some techniques for finding out if a role is applied to the accessible name by navigating using the word granularity. We also went over some techniques for testing with a Bluetooth keyboard, a color contrast tool, and the Xcode Accessibility Inspector. Next week we will continue with Android. Don’t miss out!