VSCode无障碍功能需系统级高对比度、编辑器语义高亮、正确语言模式、屏幕阅读器模式四者联动生效，缺一不可；仅改VSCode设置或装插件无效。
VSCode 的无障碍辅助功能不能靠单点配置打开——它由系统级开关、编辑器模式、语言支持三者联动生效，缺一不可。
为什么开了高对比度主题，代码还是看不清
VSCode 本身不提供独立的“高对比度开关”，它只响应操作系统层面的高对比度状态。Windows/macOS/Linux 必须先在系统设置里启用高对比度（不是 VSCode 设置里的 Workbench > Appearance: High Contrast Theme），VSCode 才会自动加载 Default High Contrast 主题并激活配套语法着色规则。
- Windows：设置 → 辅助功能 → 高对比度 → 开启（选任意方案）
- macOS：系统设置 → 辅助功能 → 显示 → 启用“高对比度”
- Linux（GNOME）：设置 → 辅助功能 → 高对比度 → 打开
- 启用后必须重启 VSCode 窗口（不是重载），右下角语言模式旁会出现黄色感叹号图标，表示已进入高对比度模式
editor.contrastBorder 是唯一能绕过系统强制加粗边框的方式
即使没开系统高对比度，你也能用 editor.contrastBorder 给关键 UI 区域加粗边框，这对低视力用户比改背景色更有效——括号匹配、选中行、活动标签页都会立刻变清晰。
- 在
settings.json中添加："editor.contrastBorder": "#000000" - 值必须是纯黑（
#000000）或纯白（#ffffff），灰阶色在高对比场景下易失效 - 可搭配：
"editor.inactiveSelectionBackground": "#3a3a3a"和"editorWidget.border": "#000000" - 不要动
editor.foreground设浅灰，它会被系统高对比主题覆盖；优先调editor.selectionBackground和editor.lineHighlightBackground
语义高亮（semanticHighlighting）关了，屏幕阅读器就听不懂代码
如果 VoiceOver 或 NVDA 把函数名读成“f-u-n-c-t-i-o-n”，大概率是 editor.semanticHighlighting 被关了，或者语言模式不对。
- 确认
"editor.semanticHighlighting": true已启用（默认开启，但某些插件或旧配置会关掉） - 右下角语言模式必须是真实语言（如
TypeScript），不能是Plain Text—— 否则 LSP 不启动，语义信息为空 - 按
Ctrl+Shift+P运行Developer: Inspect Editor Tokens and Scopes，光标停在函数名上，看semantic token type是否显示function；若为空，说明语义层未就绪 - 禁用所有带 “highlight”、“rainbow”、“colorize” 的第三方高亮插件，它们常劫持 token provider，导致语义信息被丢弃
Toggle Screen Reader Support 不只是“开个模式”
这个命令不只是让屏幕阅读器开始说话，它会禁用动画、强化 ARIA 标签、强制语义化 DOM 结构，并让编辑器状态（保存、报错、搜索数量）实时播报。
- 快捷键：
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），输入Toggle Screen Reader Support - 启用后状态栏右下角出现
Screen Reader Optimized提示 - 该模式下，
Alt+F2可打开“可访问视图”，支持逐字符/逐行检查内容；Alt+F1打开上下文相关辅助功能帮助 - 键盘导航能力在此模式下全面激活：用
Ctrl+Tab切编辑器，Ctrl+Shift+E聚焦资源管理器，方向键操作侧边栏文件
最常被忽略的是系统级高对比度与语义高亮的依赖关系——只改 VSCode 设置或只装插件，基本无效。真正起效的组合永远是：系统开了高对比 + 编辑器启用语义高亮 + 语言模式正确 + 屏幕阅读器模式开启。四者少一个，无障碍体验就断链。
