You might want to take a look at my answers to one of the comments of @ivan.mobisystems for alternative solutions. I also filed a feedback as you might have read so hopefully this will be fixed at some point.

Intersting. I renamed this property for explanation purpose but I think your suggestion still apply 🤔

And the didEndOrCancel(_:) function @objc private func didEndOrCancel(_ sender: UISlider, event: UIEvent) { shouldForwardValue = false isInteracting = false didEnd() }

private var shouldForwardValue = false private var isInteracting = false @objc private func didBegin(_ sender: UISlider) { shouldForwardValue = true } @objc private func valueDidChange(_ sender: UISlider, for: UIControl.Event) { guard shouldForwardValue else { return } if !isInteracting { isInteracting = true didBegin() } // forward the updated value if needed here valueDidUpdate(to: sender.value) }

What I do is that in didBegin(_:) I set a flag to allow the value to be forwarded in valueDidChange(_:). If this boolean value is false, nothing happens in valueDidChange. There is then a second flag that register when the interaction started. It it set to true if it is false in valueDidChange(_:) and when that happens, the function to call when the interactions begin is called. Code in the next comment :

We use an alternative (which is a bit higher level and thus safer) with several events to get interaction start, change, end and cancel. addTarget(self, action: #selector(didBegin), for: .touchDown) addTarget(self, action: #selector(valueDidChange), for: .valueChanged) addTarget(self, action: #selector(didEndOrCancel), for: .touchUpInside) addTarget(self, action: #selector(didEndOrCancel), for: .touchUpOutside) addTarget(self, action: #selector(didEndOrCancel), for: .touchCancel)

Well I guess the feedback I filed should be enough then: FB18581605. During a workshop with folks from Apple last month, they acknowledged the issue and contacted the framework team. But it's been a month and I amass getting worried this would not be fixed before the final release.

You're right! Thank you. I wonder if it can still be regarded as a bug, or if it is intended, in which case nor the documentation mentioned by the DTS engineer, nor the WWDC videos mention it. I'll look for a way to still watch for the UIEvent phase in the eventuality this is intended and will not change.

In case of you miss the notification, it's still crashing with your recommendation. I attached some screenshot to demonstrate that.

Thanks for the confirmation!

To change shell, if someone as lazy as I am: chsh -s /bin/bash chsh -s /bin/zsh Close window to ensure it has changed to zsh or bash.

Thus, when the documentation refers to « dictated or user-typed input », it does not mean that the view which property accessibilityUserInputLabels is set should be a control that can receive user input. It rather means that the user will search for the view/control name and that we as developers can set this property to offer alternative names to accessibilityLabel when the latter will not be the best match to the user‘s input to make it easier for the user to find the view/control.

Thank you I read the documentation, which is why I shared the link to the property in the first place. I think you have a misconception about the property accessibilityUserInputLabels. Have you watched the WWDC I referenced? This is about adding names to a view/control so that when the user uses an accessibility search as offered by Full Keyboard Access or Voice Over search, they can find the view/control and activate it. It works with plain views, system buttons and so on.

What is a user input control? You mean a text field for instance? Then I don’t think this the topic as I mention in my second comment. I watched the WWDC session Support Full Keyboard Access in your iOS app where they use this API in a custom UI to make it easier to find a preferences button. This led me to think that it should be possible to use this API on UIBarButtonItem as it’s a common place to put a preferences button.

Also @MobileTen I think that the « user input » here refers to the fact that the user enters some input to find the control, using the search with Full Keyboard Access or Voice Over. It’s what I understand from the video I mention and from the documentation: « An array of localized labels the user provides to refer to the accessibility element. »