Accessibility API

原生API方案通过Accessibility API直接读取应用程序的UI结构化数据，定位精度不受屏幕分辨率、主题样式或窗口遮挡的影响

KiwiDesk 只使用 macOS 公开的 Accessibility API 来控制窗口，无需关闭 SIP 也不依赖私有系统调用

Mac 刘海工具生态的形成有赖于 macOS 对辅助功能（Accessibility API）和屏幕绘制层的开放，开发者可在系统层面绘制刘海周围内容而无需突破沙盒限制

许多第三方应用（尤其是游戏或基于 Electron 构建的跨平台应用）对 Accessibility API 的支持参差不齐

Spotit 跨应用界面识别的技术路径很可能依赖苹果的 Accessibility API 与视觉大模型的结合

Prequel的自动缩放功能通过macOS辅助功能API(Accessibility API)获取界面元素位置和层级关系实现UI元素识别

macOS 的 AX API 通过 Core Foundation 框架提供，Windows 使用 UI Automation，Linux 使用基于 D-Bus 的 AT-SPI 作为无障碍接口

各平台 Accessibility API 实现差异大，部分应用（自定义渲染引擎的游戏、Electron 应用某些组件、Canvas 绑定的 Web 应用）可能不暴露完整文本信息，导致抓取覆盖率不稳定

使用 Canvas、GPU 直接渲染或自绘 UI 的应用，其屏幕内容无法通过 Accessibility API 或 DOM 解析获取，只能退回到截图加 OCR 路径，这是纯文本屏幕记忆方案最根本的覆盖盲区

Accessibility API 是操作系统为辅助技术提供的编程接口，允许程序读取 UI 元素的文本内容、层级结构和状态信息，macOS 的 AX API、Windows 的 UI Automation 和 Linux 的 AT-SPI 是三大主流实现

macOS的Accessibility API通过Mach端口消息传递机制与WindowServer通信获取窗口结构化元数据，该通道在设计上隔离于帧缓冲区访问路径之外

全局语音输入通常通过Hook系统输入焦点事件或利用操作系统辅助功能API（如Windows的UI Automation、macOS的Accessibility API）将识别结果注入活跃窗口