Accessibility API

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

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

拦截 macOS 系统级快捷键需要借助 Accessibility API 或 CGEventTap 机制，后者允许应用在事件传递给目标程序前将其截获并丢弃

许多 Electron 应用、游戏界面和自绘控件对 Accessibility API 的支持参差不齐，这是视觉模型识别路线仍有必要的原因

工程实践中两种界面理解方式常结合使用：能用API读取的优先读取，无法解析的区域回退到截图加视觉推理

标注的准确性直接取决于底层界面理解的精度，智能体需要通过无障碍API或视觉模型理解屏幕内容

授予无障碍访问权限意味着助手可持续读取屏幕上任何内容，包括聊天记录、银行App界面等敏感信息

Alexa平板的读屏购物能力在技术上依赖无障碍访问权限（Accessibility API）来获取屏幕图像与文字内容

原生方案可通过 macOS 辅助功能权限（Accessibility API）监听输入事件，并利用 Metal 渲染管线保证动画帧率稳定

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 路径，这是纯文本屏幕记忆方案最根本的覆盖盲区

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

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

向任意应用输入文字的能力通常依赖macOS的Accessibility API或CGEvent（Core Graphics事件系统）