"The same door that lets a screen reader speak your screen lets Flint read your selection. That door only opens when you unlock it."
What Accessibility Actually Is
macOS has a whole system, the Accessibility API (everyone calls it AX), built so assistive tools — screen readers, switch controls, voice control — can read and operate the interface of other apps. That's a remarkable power: one app inspecting and driving another app's UI. Flint is not a screen reader, but it needs exactly that power for a narrow purpose — to read the text you selected in whatever app is frontmost. So it uses the same API, through the same permission, that assistive technology does.
The Tree of Elements
Every app exposes its interface to AX as a tree of AXUIElement nodes — windows, buttons, text fields, each with attributes you can query: its role, its value, whether it's focused, what text is selected inside it. You start from a system-wide element, walk to the focused element, and ask that element questions. Reading a selection is just querying one attribute of one node in that tree. The elegance is that it's uniform: the same handful of attribute queries work across native apps that implement them properly.
AXUIElementCreateSystemWide()
-> kAXFocusedUIElementAttribute (whatever has focus, in any app)
-> kAXSelectedTextAttribute (the highlighted text)
-> kAXSelectedTextRangeAttribute
-> kAXRoleAttribute / kAXSubroleAttribute (what kind of field)
One tree, a few attribute queries. That's the whole read.
Permission Is the Whole Point
Because AX can read and control any app, macOS gates it hard: Flint can do none of this until the user explicitly grants it Accessibility permission in System Settings. AXIsProcessTrusted() tells you whether you have it; you check that before you ever try to read. Until the user opens that door, every AX read fails — and that's correct. The permission is not an obstacle to route around; it is the trust the whole feature stands on.