abbr 的 title 属性仅提供语义信息，必须为非空纯文本全称；首次出现缩写需在正文中写出全称+缩写，并用 abbr 包裹缩写本身；依赖 title 悬停提示不可靠，应改用 data-full + JS 实现可访问 tooltip。
abbr 的 title 属性不是“悬停功能开关”，它只提供语义信号；写了不一定看到提示，不写则一定丧失可访问性。
abbr 的 title 值必须非空且纯文本全称
浏览器和屏幕阅读器只认 title 属性的值——不是标签内容，也不是 CSS 或 JS。空字符串 title=""、纯空格 title=" "、含括号或解释性文字（如 title="API (Application Programming Interface)"）都会被忽略，abbr 退化为普通 span。
正确写法只有一个要求：用标准、完整、无冗余的全称，例如：
-
title="Cascading Style Sheets"✅ -
title="JavaScript Object Notation"✅ -
title="World Health Organization"✅ -
title="CSS"❌（这是缩写本身，不是全称） -
title="i.e., Cascading Style Sheets"❌（含冗余词）
桌面端悬停提示已不可靠，别当 UI 功能依赖
Chrome 和 Edge 自 2025 年起默认禁用 title 的悬停渲染；Firefox 虽保留但延迟高、易消失；Safari macOS 版本会截断超 60 字符的内容；移动端 Safari 完全不触发，Android Chrome 在 WebView/PWA 中基本忽略。
更关键的是：title 提示无法被键盘用户聚焦，高对比度模式下常被隐藏，且不支持换行、样式、图标或动画。
换句话说：你写了正确的 title，Lighthouse 才不会报 abbr missing description，但用户能不能看到，得看运气。
首次出现缩写必须在正文中写出全称 + 缩写
WCAG 明确要求：对读者可能陌生的缩写，首次出现应自然写出全称 + 括号内缩写，并用 abbr 包裹缩写本身。这不是可选项，而是可访问性刚需。
例如：
<p>Application Programming Interface (API) enables communication between software systems.</p>
好处是三重保障：
- 所有用户第一眼看到含义，无需悬停或辅助技术
- 屏幕阅读器朗读顺序合理（先全称后缩写），避免重复感
- 搜索引擎更容易理解上下文，提升 SEO 相关性
后续再出现 API，才单独用 <abbr title="Application Programming Interface">API</abbr> 即可。
真要稳定控制提示样式和行为，必须绕开 title
想支持移动端、键盘焦点、自定义宽高/背景/箭头/动画？必须放弃原生 title，改用 data-full + JS 实现。
关键点：
- 不要用
onmouseover，优先用addEventListener('mouseenter', ...)避免事件冒泡重复触发 - 提示层
position推荐fixed，防止父级transform或overflow: hidden导致错位或裁剪 - 必须加
role="tooltip"和动态切换aria-hidden，否则屏幕阅读器读不到全称 - 给目标元素加
tabindex="0"，确保键盘可聚焦
最容易被忽略的是：提示层 DOM 必须在每次显示前重新创建，或至少清空内容并重置 aria-hidden——复用旧节点却忘了改属性，会导致屏幕阅读器读到上一个缩写的全称。
