屏幕阅读器识别ruby需结构完整：必须显式使用rb标记基字、rt提供注音，一一紧邻；缺失rb会导致朗读错位或跳过，rp成对提供降级括号保障语义可读。
ruby标签如何被屏幕阅读器识别
绝大多数主流屏幕阅读器（VoiceOver、NVDA、JAWS）在遇到 ruby 结构时，会按语义优先朗读基字，再朗读对应的 rt 内容，前提是结构完整且符合规范。但若写成 <ruby>汉字<rt>hàn zì</rt></ruby>，阅读器可能把“汉字”当一个词、把“hàn zì”当一个音节串，导致“hàn”无法绑定到“汉”，“zì”无法绑定到“字”——最终朗读为“汉字 hàn zì”，失去逐字注音意义。
为什么rb标签不是可选项而是必要项
省略 rb 看似能简化代码，但在无障碍层面是高风险操作：
- 某些版本的 VoiceOver（尤其是 iOS 16+ Safari 中嵌入的）会跳过未显式标记的基字，只读
rt或完全忽略整个ruby - NVDA 在“焦点模式”下依赖 DOM 结构推断朗读顺序；没有
rb，它可能将文本节点与rt视为无关联的兄弟节点，打乱朗读流 -
rb明确声明“这是被注释的主体”，构成 ARIA 树中可访问名称（accessible name）的来源，对 WCAG 2.1 的 1.3.1 和 4.1.2 条款至关重要
rp标签不是为了美观，而是降级时的语义兜底
当用户使用不支持 ruby 的老旧辅助技术（如部分企业内网定制浏览器、旧版 Outlook 邮件阅读器），rp 是唯一能让注音信息仍可被感知的机制：
- 正确写法：
<ruby><rb>饕</rb><rt>tāo</rt><rp>(</rp><rp>)</rp></ruby>→ 降级后显示为“饕(tāo)”，语义保留 - 错误写法：
<ruby><rb>饕</rb><rt>tāo</rt></ruby>→ 降级后变成“饕tāo”，无分隔，易被误读为“饕tāo”是一个新字 -
rp内容必须是纯括号字符；写成<rp>（</rp>（中文括号）或<rp>[</rp>以外的字符，多数阅读器会直接丢弃该rp
常见无障碍失效场景与修复点
即使结构正确，以下细节仍会导致注音在辅助技术中“消失”或“错位”：
立即学习“前端免费学习笔记（深入）”；
- 在
ruby外层包裹span并设aria-hidden="true"—— 连带把内部rb和rt全部隐藏，阅读器彻底不可见 - 用 JavaScript 动态插入
ruby但未触发aria-live或未重置焦点，新内容不会被主动播报 - 给
rt设置display: none或visibility: hidden—— 现代浏览器虽仍渲染 ruby 布局，但阅读器会跳过该元素 - 多音字未按上下文拆分，例如统一标
<ruby><rb>长</rb><rt>cháng/zhǎng</rt></ruby>，语音引擎无法选择正确读音，应配合data-pinyin属性提供备用值
真正起作用的从来不是“用了 ruby”，而是“每个 rb 是否有唯一对应 rt”、“rp 是否成对且合规”、“是否避免任何覆盖语义的 CSS 或 ARIA 操作”。这些细节一旦松动，无障碍就从“支持”退化为“形同虚设”。
