HTML 的 `<abbr>` 和 title 属性怎么提升可读性

结论：<abbr> 负责「这是缩写」的语义，title 负责给出展开全称，两者合起来只是「辅助」；真正把可读性提上去的动作只有一个——**每个缩写在同一篇文档中首次出现时，直接在正文里写出全称，后面再用缩写**。工具提示是锦上添花，不是主力。

<abbr> 和 title 分别解决什么问题？

结论：<abbr> 是语义标签，告诉浏览器、搜索引擎和辅助技术「这里是一个缩写」；title 是这个标签的属性，用来存缩写的展开形式。

abbr 是 abbreviation（缩写）的缩写，属于 HTML 行内语义元素。标准写法是：

<abbr title="Application Programming Interface">API</abbr>

注意 HTML5 已经废弃了老的 <acronym> 标签，虽然浏览器还认，但新代码一律用 <abbr>。两者对包裹纯大写缩略词（API、CSS）和省略式缩写（Mr.、HTML 里的 Jan.）都适用。

title 里的展开文本，浏览器什么时候会显示？

结论：只有鼠标悬停（hover）时才弹出系统级 tooltip，键盘、触屏、屏幕阅读器都拿不到它。

桌面端 Chrome、Firefox、Safari 在鼠标停在带 title 的元素上约 1 秒后会显示提示条。但这意味着三条失效路径：

1. 手机和平板上没有 hover——iOS Safari 和 Android Chrome 都不会因为长按而显示 title tooltip；
2. 纯键盘用户无法聚焦到一个非交互的 <abbr> 上，因此看不到提示；
3. tooltip 出现位置、字号由操作系统决定，不受 CSS 控制。

所以「把关键解释塞进 title」这种做法，在移动端流量占比超过一半的站点上等于没写。

屏幕阅读器会读 title 吗？

结论：支持情况不一致，不能当作可靠的信息通道，而且它只在某些朗读模式下才生效。

NVDA 在默认设置下对 <abbr> 的 title 支持不稳定，JAWS 需要特定配置，VoiceOver（macOS/iOS）默认不朗读 abbr 的 title。WCAG 2.1 的成功标准 3.1.4「缩写」（AAA 级）明确要求提供展开形式或解释，可接受的实现就是正文中首次出现时给全称，而不是依赖属性。

稳妥做法是「双保险」：写全称 + 保留 abbr[title]。

<p>本页使用 <abbr title="Application Programming Interface">API</abbr>（应用程序接口）统一指代服务端数据接口。</p>

带 title 的 <abbr> 样式怎么写？

结论：给 abbr[title] 加一条点状下划线，用户才知道「这里可以悬停」，同时不要用 cursor: help 掩盖它是文本的事实。

各浏览器默认表现不一致：Chrome 和 Firefox 会给 abbr[title] 加虚线/点状下划线，Safari 不加。统一写法：

abbr[title] {
  text-decoration: underline dotted;
  text-underline-offset: 0.15em;
  cursor: help;
}

text-underline-offset 用来避免下划线和字母底部粘连，0.1em~0.2em 是常用值。如果缩写属于非中文本语言，加 lang 属性，语音合成才能读对：

<abbr title="World Wide Web Consortium" lang="en">W3C</abbr>

什么情况该用，什么情况不该用？

结论：全文只出现一两次的专业名词，直接写全称；反复出现的术语，用「首次全称 + 括号缩写 + <abbr> 标记」；年份、月份这类数字缩写，<abbr> 比 title 更值得用。

不该用的场景也很明确：不要为了塞关键词而给普通词加 title；不要把导航、按钮的可访问名称放在 title 里（键盘与触屏用户读不到）；不要用 title 承载必要信息，因为它不可点击、不可复制、移动端不可见。

如果某个解释确实很长，正确做法是旁边放脚注或 <details> 折叠块，而不是吊在 tooltip 里。经验值：解释超过 20 个字就该落到正文或脚注。

用一句话收尾

<abbr> + title 的组合价值在于语义标注和「悬停补充」，但可读性和可访问性的底线永远是把全称写进正文：首次出现给全称，之后用缩写，跨语言加 lang，样式加一条点状下划线。工具提示是加分项，不是及格线。