必须在语义化文本标签(如、、)上显式设置符合BCP 47标准的lang属性,通用容器(如)无效;中英文混排需分层标注,外语词须用内嵌语义标签单独声明lang,且值须严格为zh-CN、en-US等合法格式。

必须逐词/逐短语显式标注,不能靠父容器继承,也不能用“看起来像”来猜语言。
lang 属性只在语义化文本标签上生效
浏览器和屏幕阅读器(如 NVDA、VoiceOver)只识别 常见错误现象: 调用 正确做法是用有语义的包裹:用 一个 实操要点: … 写错值浏览器不报错,但等同于没写: 必须用的写法: 表格单元格和 关键操作: 最常被跳过的点:动态渲染的表格或代码块,JS 插入 DOM 后没补 、、、 、 等承载自然语言文本的元素上的 lang 值。 或 这类通用容器即使加了 lang,也不会触发语音引擎切换或拼写检查——它们没有语言语义。
→ 读屏软件仍按页面默认语言朗读 → 英文部分被中文引擎硬读 或 useStateユーザー。中英文混排时,不能整个段落统一设 lang
里既有中文说明又有英文术语(比如“使用 fetch 发起请求”),若整段设 lang="zh-CN",fetch 会被读成“弗奇”;若设 lang="en",中文部分会被切成音节乱读。
lang:、fetchbonjour
包英文却漏掉 lang —— 没声明就等于没语言意图lang 值必须严格匹配 BCP 47 标准,大小写和分隔符都不能错
zh_CN、english、zh-hans(小写 h)、EN-US(大写 EN)都会导致降级为 und(未知语言),进而让屏幕阅读器、SEO、CSS :lang() 全部失效。
zh-CN(不是 zh_CN 或 zh-Hans,除非你明确区分简繁)en-US(不是 en-us 或 english)ja、ko、fr 单语言码足够,无需加地域后缀API、UI、HTTP 统一用 lang="en",不是因为“是缩写”,而是因其发音规则归属英语表格和代码块里的外语词最容易被忽略
/ 是高频混排场景,但也是 lang 遗漏重灾区。浏览器不会从 或
继承语言,哪怕你写了 ,里面的日文
仍被读成中文音节。東京 ✅ 直接写在 東京 上 ❌ curl -X POST
bash 不是合法语言标签,应改为 lang="en" 或留空 ❌ 同理,SELECT * FROM userssql 非 BCP 47,应为 lang="en"
2026-09-21、USD)不用加 lang,它们无发音规则lang 属性——读屏软件只看首屏 HTML 中已存在的声明,后期用 JS 改 el.lang = "ja" 不会触发语音引擎重载。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











