Accessibility API 不处理变量逻辑或数据状态管理，其核心是为 UI 元素提供可被辅助技术识别的语义信息（如标签、角色、状态），需手动同步状态变更而非自动监听变量。
Accessibility API 不是为“变量支持”设计的，它不处理编程语言中的变量逻辑或数据状态管理。它的核心作用是让界面元素具备可被辅助技术（如屏幕阅读器、开关控制、盲文设备）识别和交互的语义能力。所谓“支持”，指的是为 UI 组件提供可访问的标签、角色、状态、操作等元信息，而不是暴露或操控业务变量。
Accessibility API 管的是“谁”和“能做什么”
它描述的是界面对象本身——比如一个按钮，API 告诉屏幕阅读器：“这是一个‘提交’按钮，当前未禁用，点击后会跳转到下一步”。这些信息通过属性（如 accessibilityLabel、accessibilityRole、accessibilityState）声明，而非读取或绑定某个 JS 变量或 ViewModel 字段。
- 在 React Native 中，用 accessibilityLabel="搜索" 替代靠视觉猜意图
- 在 iOS/macOS 中，用 UIAccessibilityTraitButton 标明可点击性，配合 isAccessibilityElement = true
- 在 Android 中，通过 android:contentDescription 或 View.setAccessibilityDelegate() 提供定制化描述
状态同步靠主动更新，不是自动监听变量
如果界面上某个控件的状态随业务变量变化（例如：加载中 → 完成），你需要手动触发无障碍状态刷新，而不是指望 API 自动感知变量变更。
Web Accessibility (WCAG 2 AA))
下载
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
- iOS：调用 UIAccessibility.post(notification: .layoutChanged) 或 .screenChanged
- Android：调用 View.announceForAccessibility("已保存") 或发送 AccessibilityEvent.TYPE_ANNOUNCEMENT
- React Native：配合 accessibilityState prop 动态传入 { busy: true } 或 { disabled: isSubmitting }，但需确保该 prop 确实随变量重渲染
真正要避免的误区
开发者有时试图把 Accessibility API 当作调试工具或状态观察入口，比如想“监听按钮是否被读出”来反推变量值——这既不可靠，也不符合设计原则。辅助功能链路是单向输出：UI → 辅助服务 → 用户。它不提供回调、钩子或变量反射能力。
- 不要在 onAccessibilityEvent 里试图还原业务逻辑（它只反映系统级交互事件，如点击、滚动、焦点移动）
- 不要依赖 AXUIElement 的属性值去读取应用内部变量（macOS 上它只能获取公开的 UI 属性，如 AXTitle、AXValue，且受权限与沙盒限制）
- 不要用 Accessibility API 替代状态管理方案（如 Redux、MobX、@State）
它解决的是“怎么被正确说出、被正确理解、被正确操作”，而不是“怎么知道变量变了”。把语义描述写清楚，把状态变更时的无障碍提示发到位，就是最扎实的支持。
