Hello,
I found an app that has an uncommon VoiceOver issue. I'd like to contact the devs about it, since the app is designed for people with disabilities and the team seems very open to feedback. However, I don't know how to word it. Here goes:
On some screens, all the text and controls are expressed as a single VoiceOver element. No matter where I touch, I find the same element, which appears to contain every item in the interface. Because of this, I can read everything, but I cannot use any onscreen controls. Swiping left and right reveals that this is the only item visible to VoiceOver.
That description makes sense to me, but would it be adequate for someone with no experience using VoiceOver? Also, does anyone know what might be causing this? I've seen it in two apps thus far.
The only workaround I have found is to use screen recognition for those pages, but not all parts of the app exhibit this problem, so I find myself repeatedly toggling screen recognition on and off.
Thanks for any input!
By Kelly, 25 August, 2025
Forum
iOS and iPadOS
Comments
Sounds find and a suggestion
Sounded perfectly fine to me what you said. Longshot but you could also point them to the accessibility team at Hive in the UK. They had exactly this issue earlier this year and fixed it so they must know what caused it. Assuming it is the same issue and your description seems to say it maybe. Also, there are devs on here so they may have suggestions as I'm not one.
Perfect
Only thing I would do is mention that you use VO and what it does for you and just ad your input. If the app is for disability, they should know about VO.
Probably
Hi Kelly
Voiceover allows devs to combine multiple elements into a single element.
For example, suppose I had to two fields for first name and last name. Let's suppose first name is Joe and last name is Brown.
We can either have VO read first name, swipe, read last name
Or I can tell VO to combine into one element and have it read Joe Brown without a swipe in between.
I suspect what's happened is someone has put a combine on a top level element and its scooped up everything into a single VO element.
Hope that makes sense
Scott
Using screen recording as a possible solution
I’m not sure I follow everything you’re saying, but it would probably help if you mentioned the actual name of the app. That way, if others are interested, they could check it out for themselves. Of course, only if you want to share it.
The reason I say that is because it’s hard to know exactly how to word the issue without seeing it in context. One thing you could try—just spitballing here—is making a quick screen recording. Walk through the steps with VoiceOver turned on, and narrate what’s happening as you go. Then you can send that recording along with your written explanation to the developer.
For example, you could say: “Here’s what I’m doing, here’s what happens, and here’s what should be happening instead.” If you also throw in some suggestions for how it could be fixed, I think developers tend to be more receptive. Clear explanation plus a possible solution usually gets their attention better than just describing the problem in text.
That’s my two cents, for whatever it’s worth.
Good Explanation and Thanks to Scott
Kelly, your explanation of the issue makes sense to me. At the end of the day, you can only do what you can do with the knowledge and resources you have.
Scott, your note about grouping elements with VoiceOver is really helpful and something that will help me in my own communications with developers about app accessibility. Thank you!
Technical reasons
Technically what you are experiencing sounds like someone decided to scale the bounding box of every accessibility element to fit the entire screen, as accessibility on both macOS and iOS is completely orthogonal to the graphical user interface, so there's never any guarantee that both infrastructures agree on anything because there's no single source of truth. Apple's default widgets do implement sane defaults, but third-party frameworks often don't build on top of Apple's native implementations and don't implement accessibility properly in their custom solutions, and that's when they even bother with accessibility at all, so unfortunately from a technical perspective this problem is completely normal, and if what I said is the root of the problem, nothing short of rewriting at least the whole user interface using a framework that actually does accessibility right will matter.
Another problem that might also cause that effect are views with some kind of transparency, as in this case screen recognition will also analyze whatever background content happen to be visible through them inside a foreground accessibility element's bounding box from the user's perspective.
Editing to acknowledge that Weather Gods (Scott)'s suggestion is more likely to be the actual root cause of the problem than either of mine, as it makes a lot of sense to me and I am aware of that possibility myself.
Bug or Feature?
Apple provides commands to developers for controlling the VoiceOver behavior, like
.accessibilityElement(children: .ignore), .accessibilityElement(children: .combine)
and others.
Sometimes it makes sense to use them, for instance when there are too many UI Elements and it would affect usability negatively for VoiceOver users. I am an iOS developer and I have been using such methods too, for instance in Lane Defender and also in HearLight .
Now the infamous question arises: Is it a bug or a feature in your case? :-)