iOS app accessibility review
JustinGuitar: an app that never really opens itself to VoiceOver.
VoiceOver cannot meaningfully see anything in this app. Not the login screen, not the lessons, not even a usable set of buttons. The only way I could interact with it at all was through Apple’s Screen Recognition, which uses on-device ML to guess what is on screen. Even then, most of the app still felt fundamentally closed.
What this case study shows
This is a useful sample because the issue is much bigger than a missing label.
The important judgment here is recognizing that this is not a scattered collection of accessibility defects. VoiceOver receives no meaningful app interface, which points to a structural exposure failure rather than a handful of missing labels. That changes both the severity and the likely fix path.
What to notice
- User impact tied to the app's core purpose, not abstract compliance language
- Distinction between partial ML fallback and actual accessibility support
- Root-cause reasoning that points to implementation, not just symptoms
- Remediation guidance shaped by likely rendering architecture
Summary
VoiceOver sees nothing. Screen Recognition sees some things. The app is still unusable.
Without Screen Recognition
VoiceOver announces only the iOS status bar. Every button, text field, and control on every screen is invisible. You cannot even get to the login screen.
With Screen Recognition
Apple's ML fallback detects some visual elements and makes partial navigation possible. I was able to log in through "Continue with Google" and get through onboarding. But core features like the guitar tuner stayed broken.
Likely cause
The observed behavior is consistent with a custom or cross-platform rendering layer that is not exposing its interface through iOS accessibility APIs. Confirming the framework would require access to the source or build information.
Screen-by-screen findings
Here is what happened when I tried to use the app with VoiceOver.
Login screen
Blocked- Without Screen Recognition
- VoiceOver sees nothing. No login button, no email field, no "Continue with Google" option. The app is a blank wall.
- With Screen Recognition
- "Continue with Google" becomes tappable. Login works because the Google account picker uses native iOS UI, which is fully accessible on its own.
Onboarding
Partially navigable- Without Screen Recognition
- Nothing is announced. Cannot proceed.
- With Screen Recognition
- Screen Recognition picks up buttons and text on the skill level and music preference screens. Selection is possible but inconsistent. The microphone permission dialog works correctly because it is native iOS.
Guitar tuner
Blocked- Without Screen Recognition
- VoiceOver sees nothing.
- With Screen Recognition
- The string letters (D, B, G, E, A, E) show up as one long unbroken line of text. You cannot tap individual strings. The tuner is completely unusable even with the ML fallback running.
- Why this matters
- Tuning your guitar is the first thing any beginner needs to do. If the tuner does not work, the app does not work.
The key insight
Screen Recognition partially working confirms that visual content exists while the equivalent programmatic information is missing or unreachable.
The dominant failure is in accessibility architecture and implementation, although the final fix still needs product and design decisions about labels, grouping, state, and interaction.
Impact
What this means for blind users.
Cannot sign in
Without Screen Recognition, a blind user cannot even reach the login screen. The most basic action in the app is blocked.
Cannot learn
Lessons, practice features, and progress tracking were not reachable during testing. The reason someone downloads this app is the part that does not work.
The workaround is not reliable
Screen Recognition is a best-effort ML system. It guesses wrong, merges adjacent controls, and cannot handle complex interactive elements like the tuner. It is not a substitute for real accessibility.
Remediation
Because VoiceOver receives no meaningful application interface, the fix is not adding a few isolated labels. The team first needs to confirm the rendering architecture and expose the product's controls, content, state, and actions through iOS accessibility APIs.
If it uses a cross-platform framework
- Action
- Use the framework's semantics or accessibility APIs for every custom control, then verify the resulting iOS accessibility tree rather than assuming the framework supplies correct behavior automatically.
If it exposes native iOS accessibility objects
- Action
- Provide appropriate
UIAccessibilitylabels, traits, values, state, grouping, and actions for each meaningful element. Complex interactions such as the tuner need an operable nonvisual model, not labels alone.
If the app uses a custom canvas
- Action
- Use an accessibility container and
UIAccessibilityElementinstances to represent meaningful visual elements, including their labels, traits, frames, state, and actions.
Standards context
Relevant requirements
The observed failures relate most directly to WCAG 2.2 success criteria 1.3.1 Info and Relationships, 2.1.1 Keyboard, and 4.1.2 Name, Role, Value when WCAG is applied to mobile software through the appropriate policy or procurement framework.
Scope note
This was a focused VoiceOver usability review, not a complete WCAG, EN 301 549, or platform-conformance audit.
Verification criteria
What "fixed" looks like.
A VoiceOver user should be able to do everything a sighted user can do, without needing Screen Recognition.
Passing criteria
- Login works with VoiceOver alone
- Onboarding screens announce all options and allow selection
- Guitar tuner strings can be individually selected
- Lesson content is navigable and playable
- No screen requires Screen Recognition to function
Why the severity is critical
This is not just inconvenient. It blocks the product at the first meaningful steps.
Account access fails
If a user cannot reach login controls with VoiceOver alone, the product is inaccessible before any lesson content even begins.
Core task fails
The tuner is a foundational feature for beginners. When that interaction is unusable, the app's main promise breaks down.
Fallback is not a product strategy
Screen Recognition may occasionally reveal visual controls, but it is inconsistent by design and cannot stand in for a real accessibility implementation.
Need this kind of review for your app?
I test iOS apps, websites, and digital products with VoiceOver and keyboard navigation, then write findings your team can act on.