屏幕阅读器依赖lang属性而非自动识别语言，因其仅依据该值加载对应TTS引擎和语法规则；不设或错设会导致中文读成英文音、法文停顿错误、缩写逐字母念等信息失真问题。
lang 属性不设置或设错，屏幕阅读器大概率会把中文读成英文音、把法文标点停顿读错——这不是“体验差”，而是直接导致信息无法被理解。
为什么屏幕阅读器依赖 lang 而不是自动识别语言
屏幕阅读器（如 NVDA、VoiceOver）不会实时分析文本内容去猜语言。它只看 lang 属性值，然后加载对应语言的 TTS 引擎和语法规则库。没有 lang，就默认用系统主语言引擎硬读，结果就是：
- 中文“北京”被读成 “Bei Jing”（英语发音），而非标准拼音 “Běijīng”
- 嵌入的
<p lang="fr">Merci</p>若没标注，句末的 “i” 可能被拖长或重音错位 - 中英混排术语如 “API 接口”，若整段只有
lang="zh-CN"，英文缩写会被汉语引擎逐字母念成 “A-P-I”
lang 设置错误的典型表现
这些现象基本可反向定位 lang 问题：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- NVDA 在 Firefox 中朗读整页时突然变调、卡顿或跳过段落
- VoiceOver 在 Safari 中对中文引号（“”）不加停顿，但对英文引号（""）有明显停顿
- Chrome 浏览器右键菜单里“翻译成中文”选项灰掉或不可见（即使页面明显是英文）
- 拼写检查在
<input>中对中文输入无反应，但系统已装简体中文词典
lang 值怎么写才真正生效
不是所有看似合理的值都能被辅助技术识别。关键看是否符合 BCP 47 标准，且被主流引擎支持：
立即学习“前端免费学习笔记（深入）”；
- ✅ 推荐：
lang="zh-Hans-CN"（简体中文/中国大陆）——Safari、NVDA、Chrome 全部稳定识别 - ⚠️ 风险：
lang="zh-CN"在 Safari 的:lang(zh)CSS 选择器中偶发不匹配 - ❌ 无效：
lang="chinese"、lang="cn"、lang="zh"（太泛，TTS 引擎无法确定汉字脚本或区域变体） - 嵌套必须显式写：
<blockquote><p lang="ja">こんにちは</p></blockquote>，不能只靠父级继承
容易被忽略的三个执行细节
很多团队设了 lang 却仍出问题，往往卡在这几步：
- 服务端渲染（SSR）框架（如 Next.js、Nuxt）中，
lang值必须随用户语言偏好动态注入，硬编码成lang="zh-CN"会破坏多语言切换逻辑 - Web Components 或 Shadow DOM 内部，
lang不自动继承，需手动透传或在内部根节点重新声明 - 用 Lighthouse 或 Axe 扫描时，“
html has valid lang attribute” 通过 ≠ 真正可用；必须实测 NVDA + Firefox 组合朗读混合语言段落，观察停顿、重音、缩写处理是否自然
