iOS端Chrome中aria-live="polite"触发朗读不读元素role属性怎么办

iOS端Chrome上的VoiceOver存在固定的处理逻辑差异：

• 当遍历正常可访问树时，会对带完整role、aria-label的元素，自动拼合「可访问名称+角色」进行朗读，也就是测试场景2的预期效果
• 当通过aria-live通道触发内容更新时，只会提取对应元素的可访问名称（即aria-label的文本内容）朗读，不会关联读取元素自身绑定的role属性，这就是场景1里漏读按钮角色的根本原因，和JS修改属性的顺序没有关系。

之前给元素加/减aria-hidden、给父节点加aria-hidden的方案，本质都是让交互元素本身承担了live通知的载体角色，自然逃不过这个逻辑限制；仅修改aria-hidden值不触发live通道的方案，因为VoiceOver不会主动监听可访问树的节点隐藏状态变化，所以完全感知不到更新。

不要让交互元素自己当live区，把结构拆成两个独立模块，彻底绕开VoiceOver的逻辑缺陷：

• 目标交互元素保留完整的可访问性配置：带role="button"、匹配功能的aria-label，全程不要给这个元素加aria-hidden属性。初始状态用不影响可访问性树的视觉方式隐藏（比如position: absolute; width: 1px; height: 1px; overflow: hidden; clip-path: inset(50%)），不要用display:none，避免元素直接从可访问树移除。
• 在页面最外层（body的直接子节点末尾）设置一个专用的live通知容器，固定写死配置aria-live="polite"、aria-atomic="true"，这个容器做0尺寸透明处理，本身不承担任何交互功能，只负责触发朗读。
• 触发目标按钮显示的逻辑按顺序执行：
  1. 先把交互元素从视觉隐藏状态切回正常显示，匹配用户的视觉感知
  2. 往专用live容器里写入和预期朗读结果完全一致的文本，比如This is a label, Button，VoiceOver会通过live通道完整朗读这段内容，效果和自然遍历可访问树的朗读没有差异。

避坑提示：

• 不要给专用live容器加aria-hidden=true，也不要用display:none隐藏它，否则live通知会完全失效
• 要是担心用户滑动浏览时误把焦点移到这个无功能容器上，给它加tabindex="-1"就行，不会影响live功能
• 不要把交互元素和live容器叠在同一个位置，避免视觉交互冲突

内容的提问来源于stack exchange，提问作者yahms23