HTML/JS实现无障碍Tooltip的正确方式：我的理解是否正确？

核心结论：你的理解完全正确 #

符合无障碍标准的Tooltip必须满足：

• Tooltip始终存在于DOM中，通过role="tooltip"标识其语义
• 触发元素通过aria-describedby属性与Tooltip的ID绑定
• 仅通过CSS控制Tooltip的显示/隐藏（如display: none ↔ block，或visibility: hidden ↔ visible）

这种设计能保证屏幕阅读器在初始扫描页面时，就能识别触发元素关联了额外提示信息，视障用户无需主动交互就能知晓Tooltip的存在，符合无障碍设计的"信息可得性"原则。

动态方案的无障碍缺陷 #

旧版tippy.js和Floating UI示例采用的动态创建方案，确实存在无障碍问题：

• 初始状态下，触发元素没有有效的aria-describedby关联（要么无该属性，要么关联的Tooltip元素不存在）
• 屏幕阅读器不会主动触发hover或焦点事件，因此无法自动加载Tooltip，视障用户只有主动聚焦触发元素时才能获取提示信息，体验存在明显短板

主流库采用动态方案的原因 #

这些库选择动态方案，主要是出于以下实际场景的考量：

• 性能优化：页面存在大量Tooltip时，静态挂载所有Tooltip会增加初始DOM节点数，拖慢页面加载和渲染速度。动态创建可以按需加载，减少初始性能开销。
• 动态内容适配：部分Tooltip的内容依赖实时数据（如接口返回、用户状态），提前挂载无法获取到有效内容，动态创建能在触发时渲染最新信息。
• 功能优先级：Floating UI作为底层定位库，核心能力是处理浮层的定位逻辑，无障碍实现属于上层业务需求，官方示例更侧重展示核心功能，完整的无障碍适配需要开发者自行补充；旧版库则可能受限于早期无障碍标准的普及程度，设计时未优先考虑该需求。

折中优化方案 #

如果要兼顾无障碍和性能，可以根据场景选择不同实现：

• 对于内容固定、数量较少的Tooltip：采用静态挂载的标准无障碍方案
• 对于大量或动态内容的Tooltip：页面初始化时先挂载空的Tooltip容器（带role="tooltip"和固定ID），触发时填充内容并为触发元素添加aria-describedby关联，避免完全动态添加DOM导致的无障碍问题

内容的提问来源于stack exchange，提问作者Paul Pepper