User Profile

Accessibility Inspector 5.0 (112) is working fine in Xcode 13.3.1 running on my M1 iMac under macOS 12.3.1. I do have to turn it on frequently by clicking its activation button, and I had to set it up to show advanced element values the first time. My similar UI Browser application is still working fine, too. https://pfiddlesoft.com/uibrowser

The Accessiblity authorization in the Privacy tab of the Security & Privacy pane of System Preferences thinks that an AppleScript applet has turned into a new and different application every time you edit, recompile and re-save the applet. Your Mac therefore thinks the revised applet is unauthorized and refuses to run it. You can quickly and easily solve this problem by unchecking and re-checking the applet's checkbox in the Accessibility authorization. The applet will then run correctly when you double-click it. Here's a simple script to test this: activate application "Finder" tell application "System Events" tell process "Finder" click menu item 1 of menu 1 of menu bar item "Apple" of menu bar 1 end tell end tell

That has been my conclusion. I first released my UI Browser application to explore the accessibility structure in 2002, and it has used the old API ever since. See https://pfiddlesoft.com/uibrowser.

Yes, I have explored Apple's Books application in depth with UI Browser. If you give it a try as I suggested, use UI Browser's browser view to traverse the Books UI element hierarchy down through several levels of "AXGroup" elements until you come to the "AXWebArea" element. Then look in UI Browser's Attributes drawer to see the details of how Books uses Apple's specialized AXWebArea accessibility API to parse text. AXWebArea is a very complex API, and it is not easy to use with GUI Scripting or code. UI Browser can track the attributes and help you write GUI Scripting scripts that will retrieve the text values, but UI Browser is not designed to retrieve AXWebArea text values directly. Apple's Accessibility Inspector utility does retrieve the text values directly.

Apple's Books application is known to contain some "mismatch" errors in its implementation of accessibililty. That means it portrays the UI element hierarchy differently in one direction (for example, in a screen reader that starts with a leaf element on the screen) than in the other direction (for example, in a browser that starts with the application UI element. Try the free trial of my UI Browser application to explore this possibility. https://pfiddlesoft.com/uibrowser

The AppleScript Utility application is still present at /System/Library/Core Services/AppleScript Utility.app, and you can still open its scripting dictionary by dropping its application icon on Script Editor.However, if you try to use Script Editor to run any script targeted at AppleScript Utility, it simply runs doing nothing until you get the "AppleEvent timed out" error. This is even true with a simple script that just asks AppleScript Utility for its 'properties'. The same error occurs if you change your script to begin with 'tell application "Script Utility"' instead of using its application id. Scripts addressed to other scriptable applications in the Core Services folder work just fine; for example, System Events and Database Events and, in the Applications subfolder, Folder Actions Setup.If you try to run the same simple script targeted at AppleScript Utility in Script Debugger, you get a "Connection is invalid" error. The path it is trying to use is given as "MP:System:Library:CoreServices:AppleScript Utility.app". This looks correct, but it doesn't work.If you use Script Debugger to script other scriptable applications in the Core Services folder, instead, such as Database Events, Script Debugger puts up a '"Script Debugger" wants access to control "Database Events"' dialog on the first attempt, and clicking OK adds Database Events to Script Debugger's list in the Automation pane of System Preferences' Security & Privacy pane Privacy tab, and that allows the script to run repeatedly thereafter. This is correct behavior on Catalina, but it doesn't happen with AppleScript Utility.My guess is that Apple simply forgot to make Script Utility available to script runners when it split the boot volume into two separate volumes in Catalina. This deserves a bug report to Apple.