应使用 aria-label + 自定义浮层替代原生 title：aria-label 保障可访问性，data-tooltip 配合 CSS/JS 实现可控提示；注意避免 overflow/transform 裁切、用 visibility: hidden 替代 display: none，并确保 aria-describedby 指向真实 ID 元素。
title 属性提示太简陋，怎么换更可控的方案
原生 title 属性只能显示纯文本、无法样式定制、延迟触发且移动端基本失效——这不是“不够美观”的问题，是功能缺失。真正要替代它，得用 aria-label + 自定义浮层组合。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 对图标、按钮等无文本元素，优先用
aria-label保证读屏器可访问，例如<button aria-label="删除这条记录"></button> - 需要视觉提示时，用
data-tooltip自定义属性配合 CSS + JS 控制显隐，避免污染语义结构 - 不要把提示内容塞进
title里再试图用 JS 覆盖——浏览器对title的渲染逻辑不开放，强行劫持会破坏焦点管理与键盘导航
用 CSS 实现 tooltip 时 hover 不生效的常见原因
最常踩的坑是父容器设置了 overflow: hidden 或 transform，导致 tooltip 被裁切或脱离文档流后定位失效。另一个隐形陷阱是使用 display: none 切换状态，让屏幕阅读器完全忽略该元素。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- tooltip 元素必须和触发元素处于同一 stacking context，避免被
z-index隔离；检查父级是否意外创建了新层叠上下文（比如有opacity < 1或filter） - 用
visibility: hidden+opacity: 0替代display: none，确保可访问性 API 仍能感知元素存在 - 移动端没有 hover，必须补充
focus和touchstart事件监听，否则键盘用户和触屏用户都看不到提示
aria-describedby 怎么和 tooltip DOM 正确绑定
aria-describedby 不是“指向 tooltip 文本”，而是指向一个**真实存在的、带 ID 的元素节点**。如果只写 aria-describedby="tip-1" 却没在页面里放 <div id="tip-1">...，辅助技术就查不到内容。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- tooltip 内容容器必须有唯一
id，且该id与aria-describedby值严格一致（区分大小写） - 内容容器建议用
role="tooltip"显式声明角色，并添加aria-hidden="true"防止重复朗读（除非它是焦点目标） - 动态生成 tooltip 时，务必等 DOM 插入完成后再设置
aria-describedby，否则 NVDA 或 VoiceOver 可能读取失败
Tooltip 悬停时焦点丢失导致键盘操作中断
用户用 Tab 进入按钮，悬停触发 tooltip，再按 Tab 时焦点直接跳到下一个可聚焦元素——tooltip 本身不可聚焦，但又遮挡了原本的 tab 顺序，这是 WCAG 2.1 2.4.7（焦点可见性）和 2.1.1（键盘）的双重风险点。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- tooltip 出现时，把焦点临时移入 tooltip 内部的关闭按钮（如果有）或首个可聚焦子元素，用
element.focus()主动控制 - 用户按 Esc 键应关闭 tooltip 并将焦点还原回原触发元素，不能靠
blur()简单处理 - 避免在 tooltip 中放表单控件（如输入框），否则 tab 顺序会彻底失控；真有交互需求，改用模态对话框（
role="dialog"）更稳妥
tooltip 表面是 UI 小细节，实际牵扯 DOM 结构、ARIA 流程、焦点管理、响应式行为四条线，任一环断掉都会让部分用户完全失能。别把它当装饰，得当交互入口来设计。
