无障碍与输入法是最先出现裂缝的地方
别名: 无障碍裂缝 · IME 裂缝 · framework accessibility gap
概念解释
跨平台框架与系统之间，裂得最早的不是圆角，而是辅助功能树和输入法。屏幕阅读器要的是角色、标签、焦点顺序；输入法要的是组成窗口、候选栏、未上屏字符与插入点的契约。自绘控件和包装控件都把这两份契约放在构件 API 底下，默认很容易漏接。这个先行失败叫无障碍与输入法裂缝（a11y-IME fracture）。不依赖旁白和组成输入的人可能永远看不见；依赖的人第一次就会撞墙。
它不是「自绘丢掉滚动物理」，也不是「包装层在长按菜单上漂移」。那两处是一般用户也能摸到的行为差。这里是更深的平台合同：辅助功能与输入法先裂，因为它们不走普通命中测试。
机制
系统把可访问性暴露成一棵与视图平行的树，把输入法暴露成与文本控件绑定的会话。框架要嘛把自家节点桥接到这棵树（Flutter 的 Semantics、RN 的 accessibility 属性），要嘛让包装后的原生控件自己说话。桥接是手工维护的第二份 UI：漏一个角色，旁白就读成「按钮」或什么都不读；焦点顺序按绘制顺序而不是阅读顺序，跳读就乱。输入法的组成态（拼音还没上屏）要求控件理解「这段字暂时不是提交」。自绘编辑器若把每次按键当成最终字符，组成会被撕开，候选栏位置也会漂。
裂缝先出现，是因为普通功能测试用手指点、用西文键盘敲，两条合同都不被行使。CI 绿着，旁白和中文输入已经坏了。它们是金丝雀：先死的不是产品的面子，是平台合同里最深的两层。
边界
完全不接受文本输入、且所有内容都是系统文本控件读出来的只读工具，输入法裂缝不出现，无障碍裂缝仍可能在自定义绘图上出现。把每个可操作对象都做成真正的系统控件、不经自绘树，裂缝会回到系统自己的质量，框架不再是主因。游戏若走自己的旁白和输入，是另一份合同，不要用系统树去衡量。仅内部使用、已知用户不开启辅助功能也不用组成输入的工具，风险低，但仍会在第一次需要时爆发。
怎么落地
- 自绘可操作对象必须带上角色、名字、可聚焦；不能靠视觉长得像按钮来代替语义。
- 文本编辑走系统或框架提供的正式输入控件，不要自己接收按键再拼字符串。
- 把旁白走查和中文 / 日文组成输入列入每一版回归，与点击测试并列，而不是发布后等反馈。
- 验证：用屏幕阅读器只听不看，走完核心任务；任何「未标记」或焦点乱跳都是无障碍裂缝。再用组成输入在搜索框和评论框打一段未上屏的拼音，确认候选栏贴着插入点、退格先消组成再消已上屏字。两处任坏，都不要当成个例文案问题。