title仅在鼠标悬停或键盘聚焦时由浏览器原生显示纯文本提示，且仅对可交互元素（如img、button、input、a）生效；它不可样式化、不参与DOM渲染、移动端基本无效，不能替代aria-label或aria-describedby等可访问性属性。

title 属性只在鼠标悬停或键盘聚焦时，由浏览器原生弹出纯文本提示框；它不参与 DOM 渲染、不可样式化、移动端基本无效，也不能替代可访问性语义。

title 什么时候会显示？

它只对语义上“可交互”或“有明确含义”的元素生效，比如 、、、。不是所有加了 title 的标签都会弹出提示：

• 在多数浏览器中静默——它默认不可聚焦、无交互行为
• 或
  上加 title 可能触发，但超 120 字符会被截断，且换行失效

  父容器设了 pointer-events: none 或 overflow: hidden（导致实际悬停区域偏移），title 就不会出现

  iOS Safari 完全不支持 hover 触发，Android 各厂商行为不一致，长按也不保证有反馈

  title 和 aria-label / aria-describedby 的关系

  三者定位完全不同，混用反而破坏体验：

  

  htmlppt.skill

  把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。

  下载

  • title 是视觉层兜底提示，屏幕阅读器可能读、也可能跳过；aria-label 是语义层替代名称，优先级更高，且必读
  • 给图标按钮写 ? 是冗余的：读屏器只读 aria-label，桌面端却多一个重复提示
  • aria-describedby 必须指向真实 DOM 元素 ID（如 aria-describedby="hint-1" +
    删除后不可恢复
    ），比 title 更可控、更适配校验类场景
  • 表单中依赖 title 提示格式要求（如“请输入邮箱”）很危险——用户不悬停就看不到，焦点进入时多数浏览器也不显示

  哪些地方绝对不该用 title

  它不是轻量 tooltip 组件，也不是无障碍补丁，强行塞进不合适的地方只会埋坑：

  • 不要给 标签自身加 title 属性——语法合法但被浏览器忽略
  • 不要拿 title 替代 alt：给 加 title="公司Logo" 而漏掉 alt，直接导致 WCAG 审计失败
  • 不要在需要富文本、换行、图标或点击操作的场景硬用 title——它只接受纯文本， 会原样显示为字符串
  • 调试时写 title="debug: user.id=123" 很快，但上线前必须删掉；它不解决任何真实用户问题

  最容易被忽略的一点：title 的存在本身会掩盖真正的可访问性缺陷。当团队说“我们加了 title，提示有了”，往往意味着还没想清楚这个提示到底该服务谁、在什么设备上以什么方式触达。真要可靠提示，就得放弃 title 的幻想，老实用 aria-describedby + 真实 DOM + position: fixed 气泡容器来实现。