abbr标签：缩写词全称悬停解释的语义化支持

在网页开发中，abbr 标签常被误解为能直接提供悬停解释。实际上，它只负责语义层面的标记，真正触发浏览器默认提示的是 title 属性。然而，这套原生机制并不可靠：样式不可控，移动端支持不佳，整体体验难以令人满意。

abbr 必须配非空 title 才算有效语义

一个没有 title 属性的 abbr 标签，在功能上和普通的 span 没有区别。屏幕阅读器会直接跳过它，Lighthouse 等审计工具会报出“缺少描述”的错误，搜索引擎也无法识别其语义价值。实践中，有几个高频错误值得警惕：

• 设置 title="" 或 title=" " —— 这些写法会被视为 title 属性缺失，等同于没写。
• title="JavaScript Object Notation (JSON)" —— title 属性应仅包含全称，括号和额外的缩写说明违反了规范，应简化为 title="JavaScript Object Notation"。
• 把全称写在标签内容里，例如 JSON (JavaScript Object Notation) —— 这种做法既破坏了可访问性（因为 title 为空），也混淆了标签的语义用途。

缩写首次出现时，别只靠 abbr+title

即便正确使用了 API，对于非母语读者或存在认知障碍的用户来说，理解上依然可能存在困难。根据 WCAG 的可访问性指南，更稳妥的做法是：

• 在缩写第一次出现时，先在正文中自然写出全称，随后在括号内给出缩写，例如：Application Programming Interface (API)。
• 在此之后，同一页面内再出现该缩写时，单独使用 标签即可。
• 如果内容跨越了不同章节或页面，出于上下文独立的考虑，建议保留 title 属性作为辅助。

想让悬停提示稳定可用？不能只依赖 title

依赖浏览器原生的 title 提示越来越不现实。Chrome 和 Firefox 已倾向于保守渲染（Chrome 甚至默认禁用了 hover 提示），Safari 在移动端仅支持长按短暂弹出，而 Android 版 Chrome 基本没有响应。要在真实项目中提供稳定、可样式化的视觉提示，需要一套组合方案：

• 使用 data-title 属性存储全称，配合 CSS 的 ::after 伪元素和 content: attr(data-title) 来实现完全可控的自定义 Tooltip。
• 同时，保留 abbr[title] 的写法，以确保语义完整性和屏幕阅读器的支持。
• 如果需要支持键盘导航访问，可以添加 tabindex="0" 并使用 aria-describedby 关联一个隐藏的详细解释段落。
• 特别注意：绝对不要同时为 abbr 设置 title 和 aria-label 属性，因为 aria-label 会覆盖 title，导致屏幕阅读器完全跳过缩写词本身，直接朗读 aria-label 的内容，这违背了标记缩写的初衷。

最后，还有一个根本性问题常被忽略：这个词真的需要用 abbr 标记吗？并非所有“看起来像缩写”的词汇都需要大动干戈。像 “vs”、“eg”、“etc” 这类源自拉丁语的缩写，通用程度极高，通常无需强制展开解释。而那些领域特定的技术术语，如 “JWT”、“SSR”、“CSR”，在首次出现时，才值得采用“正文写全称 + abbr 标签 + 准确的 title 属性”这三重保障，以确保信息的清晰度和可访问性。