结构性问题无法在后期修补
别名: 结构性问题 · 补丁修不了 · overlay 无效
概念解释
整页画在一块画布里、任务只能靠拖拽完成、内容虚拟化到辅助技术永远读不到折叠外的节点——这类问题不是缺两行属性。结构性问题无法在后期修补（structural inaccessibility）指的是：名称、角色、焦点顺序、时限模型如果没进架构，叠加控件和样式补丁重建不出一棵真的无障碍树。看起来「加上了」，树上仍是空的。这和贵不贵不是同一句话：有些表面问题事后能补；结构问题事后补的是假象。
机制
辅助技术消费的是结构和行为契约，不是像素。契约缺失时，运行时补丁只能改可见层：高对比覆盖层、自动生成的替代文本、把焦点画成一个框。第二层是假修复会挡住真修复——扫描器开始报通过，管理层以为结构已经还上，真正的键盘模型和语义标题再也排不进档期。虚拟列表若根本不把屏幕外节点放进可访问树，加再多实时区域也变不出可跳转的标题大纲。拖拽作为唯一排序手段，没有等价的按钮或输入，补丁无法发明那条未设计的操作。
怎么研究
把失败分成表面（对比、文案、可见焦点样式）和结构（无角色、无焦点序、无键盘操作模型、时限写死在引擎里）。对号称「无障碍覆盖层」或后期 ARIA 喷雾的页面，对照无障碍树与键盘遍历，看补丁前后树是否真的多出名称和角色。
自变量：修补手段（样式 / 属性喷雾 / 覆盖层 / 重写结构）。 因变量：树上是否出现正确的角色与名称、键盘能否走完任务、覆盖层是否与原生控件冲突。
案例用「补丁失败」本身当证据，不要用成本数字代替结构判断。
边界
标签关联、对比度、字幕、可见焦点样式属于事后可以补上的层，不要扩成「什么都不能补」。有时「修补」就是重写那一块——结论不是禁止改，是承认小补丁不够。游戏、创作画布可以把结构做在工具层（菜单、属性面板）而不是像素里，前提是那层真有树。服务端渲染改成客户端虚拟化，会把已经成立的结构毁掉，属于后期引入的结构问题。
怎么落地
- 架构评审列出不可补清单：纯画布内容、唯一拖拽、无标题的信息结构、不可暂停的限时引擎。命中则必须改交互模型或补一条真正的结构通道，禁止只加覆盖层。
- 虚拟列表要保证正在交互和即将进入视口的节点存在于可访问树，不能等用户看见才生成语义。
- 禁止把覆盖层当结构修复的完成定义。
- 验证：对声称已修补的页面打开无障碍树，键盘走完主任务。树上没有对应角色与名称、或某步只能拖，就还没补上。再关覆盖层重测，行为若崩掉，说明结构从未进入产品。