Direct Touch Interaction Broken in iOS 14?

I have an app which requires the user to have direct interaction with a view when VoiceOver is enabled. In iOS 12 and 13 my code worked as expected. However, in iOS 14, whenever the user tries to interact with the view requiring direct interaction, the view responds with the audible message:

"Direct touch area. Use the rotor to enable direct touch for this app."

This is a bit of an awkward user experience for a visually impaired user. The user now has to enable something which was working just fine in previous versions. In addition, anytime the user navigates away from the app and then returns, they must re-enable direct touch again.

In my code I was able to enable direct interactions with the following code:

Code Block Swift
view.isUserInteractionEnabled = true
view.isAccessibilityElement = true
view.accessibilityTraits = UIAccessibilityTraits.allowsDirectInteraction

However, this no loner seems to be enough. How do I tell my app: "Yes, please use direct interaction all the time and don't bother the user?"
Up vote post of bb1999 Down vote post of bb1999
4.1k views
Posted by
bb1999
Reply

  • I have a similar problem. My app made with Unity uses direct touch to help visually impaired users use the app. When iOS says "Direct touch area. Use the rotor to enable direct touch for this app.", the rotor often is not coming up. And everytime you suspend the app, the setting is forgotten by iOS. This is not correct behaviour.

    —
    jlv
Add a Comment

Replies

In iOS 14, there's a new screen recognition feature. People can turn this on using the rotor, and it will try to detect the UI elements on the screen and make them accessible, even if the dev hasn't made the app accessible themself. If the entire area of your screen is a direct interaction area, then a user will not be able to use the rotor to enable screen recognition for the app, and will instead have to use the app in direct touch mode, which is often less desirable. Some apps simply set this trait so that their app is "usable," however in practice their app is not really usable at all by VoiceOver users with this pattern.

However, there are certainly cases where you might have a legitimate need to mark a view as requiring direct interaction that might take up your entire screen. I'd encourage you to file a bug through feedback assistant so we can consider your use case. At this time, there's nothing you can do to change the behavior in your app.
Posted by
danax
Post not yet marked as solved Up vote reply of danax Down vote reply of danax
Add a Comment
OK, thank you for the feedback. I'll submit a bug in feedback and explain how I'm using the direct touch feature to enhance a visually impaired persons' experience.
Posted by
bb1999
Post not yet marked as solved Up vote reply of bb1999 Down vote reply of bb1999
Add a Comment
@Frameworks Engineer Is there any way to detect when the user has direct touch turned on via the rotor or not?
Posted by
Blau Magier
Post not yet marked as solved Up vote reply of Blau Magier Down vote reply of Blau Magier
Add a Comment
No, information about whether or not the user has turned on direct touch is not available to the application.
Posted by
danax
Post not yet marked as solved Up vote reply of danax Down vote reply of danax
Add a Comment
@Frameworks Engineer what percentage of the screen must be covered in order for this new iOS14 behavior is triggered? Also, are the safe areas taken into consideration and if so, how? Finally, can you point me to documentation that covers this new behavior?
Posted by
bb1999
Up vote reply of bb1999 Down vote reply of bb1999
Add a Comment
We don't have this behavior documented anywhere with regards to the API, although it should not really matter to a developer. You are marking up your UI with the appropriate traits and attributes, and it's up to VoiceOver to figure out how to interpret those and design a good experience for people using the technology. The behavior is subject to change as feedback is received and features are added, etc.

If you are running into some friction with this design change, please file a bug so we can review this.
Posted by
danax
Up vote reply of danax Down vote reply of danax
Add a Comment
@Frameworks Engineer Has there been any update on whether this issue will be resolved in a future update or perhaps best practices you can share on how to best build for this issue?

Our team built our entire app on the iOS 14 beta with a robust menu for the visually impaired. In the beta everything worked perfectly, however since the public release version we were frankly devastated when the latest version of the OS presented this massive interaction change.

Could you please share any resources on how a developer can best create custom navigation menus with this new system? For example, our app has horizontal menus, we built an entire, voiceover based, menu system so visually impaired users can navigate the items in these menus in the correct order. With a standard vertical order menu system, one that is default in this new screen recognition feature, the order of the menu items are entirely incorrect, making the experience terrible for our visually impaired users. So much so that we’ve had to pull our app until this is figured out.

Is our only option to completely redesign our app to have vertical navigation? Please….any help or any documentation for best practices would be extremely appreciated. Our visually impaired users simply cannot use our app with the persistent “Direct Touch Area” message…which is incredibly disappointing considering how awesome the voiceover framework is.

Posted by
stupidsmartguy
Up vote reply of stupidsmartguy Down vote reply of stupidsmartguy
Add a Comment
You should notice some changes in the iOS 14.4 beta that should address some of these concerns. This setting is now configurable in Settings and is remembered on a per app basis.

I'm not sure what kind of custom menu you are referring to, could you provide more details on the issue and what you are experiencing difficulty with? The best practice is to use the UIAccessibility framework to make these menu items accessible. If you are doing your own custom drawing, you can use UIAccessibilityElements to create backing elements for VoiceOver to see that correspond to your custom drawn elements.

If VoiceOver is still navigating the menu incorrectly and you are using the native APIs, please file a bug using feedback assistant with some sample code.
Posted by
danax
Up vote reply of danax Down vote reply of danax
Add a Comment

I am facing the similar problem. Does anyone find any solution to avoid Direct Touch Area?

Posted by
JohnHarty
Up vote reply of JohnHarty Down vote reply of JohnHarty

  • Hi,

    I am also facing the same issue.

    —
    SinghAayushi
Add a Comment

Hi, I am also facing the same issue. This "Direct touch area, use the rotor to enable direct touch for this app" announcement is happening everytime user touches the direct interaction view area borders and whenever the focus shifts to the view, which is very annoying for the users. Is there a way we can disable this announcement ?

Posted by
SinghAayushi
Up vote reply of SinghAayushi Down vote reply of SinghAayushi
Add a Comment