关掉 editor.accessibilitySupport 不影响 hover 提示；真正控制无障碍悬浮框的是 colorDecorators.enabled 和 terminal.integrated.showLinkHover；原生无无障碍 hover 功能，相关提示均来自第三方扩展；workbench.accessibility.announcer.enabled 仅控制语音播报，不控制浮窗显示。
关掉 editor.accessibilitySupport 不等于关 hover
很多人搜“无障碍悬浮提示”，第一反应是把 editor.accessibilitySupport 设为 off，但这只是禁用屏幕阅读器适配逻辑，对鼠标悬停弹窗完全没影响。它不控制任何 hover 行为，也不影响 editor.hover.enabled 或语言服务器的提示逻辑。
真正触发无障碍风格悬浮框的是 colorDecorators.enabled 和 terminal.integrated.showLinkHover
VSCode 在无障碍模式下并不会额外加 hover，但某些“伪 hover”在高对比度主题或启用了辅助功能后会更显眼、延迟更低，容易被误认为是无障碍专属提示：
-
colorDecorators.enabled：悬停颜色字面量（如#3b82f6）时弹出的色板——它本身无无障碍标记，但在高对比度主题下边框更粗、背景更硬，视觉上像“强制提示” -
terminal.integrated.showLinkHover：终端里悬停路径或 URL 时的下划线+tooltip，开启后即使没开无障碍也会响应更快，部分读屏软件会主动抓取这个 tooltip 内容 -
html.hover.enabled和css.hover.enabled：HTML/CSS 文件中悬停标签/属性时显示的 MDN 链接，这类内容常被读屏朗读，但开关本身和无障碍设置无关
检查是否真有无障碍 hover 插件在运行
VSCode 原生没有“无障碍 hover”功能，所有带朗读能力的悬浮提示都来自第三方扩展，比如：
-
Screen Reader Optimizer：会劫持 hover 事件并注入 aria-label 和朗读文本 -
Accessibility Checker：悬停 DOM 节点时显示可访问性评分浮层 - 某些企业定制版 VSCode 或内部插件可能封装了
vscode.window.showQuickPick+accessibilityInformation组合，在 hover 后手动唤出带朗读支持的面板
验证方法：禁用所有非官方扩展 → 重启 → 悬停测试。如果浮窗消失，再逐个启用，观察哪个插件触发了带 aria 属性或朗读反馈的提示。
唯一需要动 accessibility 相关配置的地方是 workbench.accessibility.announcer.enabled
这个设置控制的是“系统级语音播报”，比如快捷键错误、搜索无结果、文件保存成功等事件的语音反馈，和悬浮框本身无关。但它一旦开启，会在 hover 触发某些扩展提示时同步朗读内容，造成“hover 带声音”的错觉：
- 设为
false可停掉所有语音播报，包括 hover 关联的朗读 - 不影响任何浮窗显示，只切断语音通道
- 如果你只希望关声音、留提示，这是最精准的开关
真正难清理的是那些把 hover 和朗读耦合进同一扩展里的实现——它们不会暴露独立的 hover 开关，只能去插件设置页找类似 accessibility.hoverSpeak 或 announceOnHover 这样的隐藏项。
