I did file a bug, FB21763493 I did try using the security scoped bookmark for creating the PDF Services directory but didn't think I needed to then create a new security scoped bookmark for the newly created directory. Once I implemented that suggestion, creating the directory and workflow did work with one user prompt. I also tried using the Save dialog to create the directory and workflow and, you are correct, it is a bit weird :-) but it worked. Now I have two working methods to achieve this, which means I don't need to mess with entitlements. Thanks for the help. Dave

Hi Quinn, We just started seeing this same issue, a new version of previously successful notarized was submitted and it fails to be notarized. The executable is an Install Anywhere installer that contains jar files and the jar files are the source of the notarization failure. To test, I used the same unmodified earlier file, that successfully notarized, and submitted it for notarization again and it failed to notarize. If acceptable, I can send the log files to your email as I'm prevented from letting the logs becoming public.

The problem I initially asked about is resolved but only for macOS 14 and higher, whereas I needed macOS 13 support. If anyone else has this issue, the key was making the call in the tab view controller before switching to the sub tab view. The announcement is made and "Text to read first" is read and the "Feature Name" is read but only on macOS 14+. I tried various UI elements for the the NSAccessibility.post() call, the sub tab view controller, the main tab view controller, the view containing both, the text field itself, and finally the main window, none resulted in the correct behavior. if #available(macOS 14.0, *) { AccessibilityNotification.ScreenChanged(self).post() AccessibilityNotification.Announcement(textField.stringValue).post() } else { // Fallback on earlier versions NSAccessibility.post(element: NSApp.mainWindow as Any, notification: .announcementRequested, userInfo: [.announcement: textField.stringValue, .priority: NSAccessibilityPriorityLevel.high]) NSAccessibility.post(element: textField as Any, notification: .titleChanged) }

Found some more information about .announcementRequested and I wasn't passing the string to read, so I hoped changing the code to the following would work, but it didn't, nothing is read except for the button "Feature Name" NSAccessibility.post(element: tabVC.textField as Any, notification: .announcementRequested, userInfo: [.announcement: textField.stringValue, .priority: NSAccessibilityPriorityLevel.high]) I've tried putting the above code in the parent tab view controller before the sub tab is displayed, no help. Moved the announcement code to viewDidLoad and viewWillAppear and neither worked. Is it really possible to achieve this behavior?

You are correct, I'm trying to read some additional information before reading the UI on the new tab. A concrete example is in System Settings, when you select an item on the left side (General), read the title (General) on the right side before reading the feature list (About). Using your suggestion, I tried adding the following code to the viewDidLoad, viewWillAppear functions of the sub tab, nothing was read. I added the code to the main tab handler when the sub tab was clicked and nothing happens. "Text to read first" is a NSTextField Tried both: NSAccessibility.post(element: textField as Any, notification: .announcementRequested) and NSAccessibility.post(element: textField as Any, notification: .announcementRequested, userInfo: [.priority: NSAccessibilityPriorityLevel.high]) VoiceOver is active and reading the screen but the announcement is never read and the "Feature Name" element is the first thing read when switching to the sub tab. Am I using the wrong approach? When should I post the notification? Is announcementRequested handled by VoiceOver? Thanks!