html语义化为国际化提供可访问性基础，必须动态同步更新lang属性、保持标题层级与区域标签一致、确保表单和图片的语义绑定随语言实时更新，否则多语言切换将破坏屏幕阅读器体验。
HTML语义化本身不直接处理翻译或语言切换，但它为国际化（i18n）后的可访问性打下不可替代的基础——关键在于：语义结构稳定，辅助技术才能可靠地配合语言内容工作。一旦结构混乱，多语言切换后屏幕阅读器反而更难理解上下文。
lang 属性必须随语言动态更新
只在 标签写死 lang="zh-CN" 是常见错误。当页面切换为英文或日文时，若没同步更新该属性，屏幕阅读器仍按中文语音引擎朗读英文文本，导致音调错乱、停顿失准、甚至跳过部分词。
- 服务端渲染（如 Next.js）：确保每个语言版本的 HTML 响应中，
或动态匹配当前 locale - 客户端切换语言：用 JS 修改
document.documentElement.lang，不要只改文字内容 - 避免
lang=""或缺失值——空 lang 会被当作“未知语言”，多数读屏直接降级为默认语音，不可控
标题层级与区域标签不能因翻译而断裂
多语言文案长度差异大（比如中文“联系我们” vs 英文“Get in Touch with Our Customer Support Team”），容易诱使开发者用 CSS 隐藏/显示不同语言的标题，或把 <h2></h2> 拆成多个 <span></span> 拼接。结果是文档大纲（outline）在不同语言下完全不一致，屏幕阅读器 M 键跳转时找不到主标题，或误把副标题当主干。
如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更
- 所有语言版本必须保持相同的标题层级结构：从
<h1></h1>开始，严格递进，禁止跳级或降级 -
<main></main>、<nav></nav>、<aside></aside>等区域标签不能因语言切换而增删——它们定义的是结构角色，不是视觉容器 - 翻译文案要适配语义容器宽度，宁可换行或调整布局，也不要破坏
<section></section>内必须含<h2></h2>这类基本约束
表单和按钮的语义绑定不能依赖文案内容
很多团队用 aria-label 或 title 存储翻译后的按钮文字，却忽略原生语义已被削弱。例如：<button aria-label="搜索"></button> 在中文环境可用，但切换为法语后若没同步更新 aria-label，读屏仍报“搜索”，用户完全不知当前界面语言已变。
- 优先使用内联文案：
<button>Rechercher</button>，让innerText和可访问性树一致 - 若必须用图标按钮（无可见文字），则
aria-label必须随 locale 实时重设，且不能 fallback 到硬编码字符串 -
<label for="email"></label>的关联必须存在，且其文本内容参与翻译——不能靠 JS 动态插入aria-describedby替代<label></label>的语义绑定
图片 alt 和 figcaption 的本地化必须完整
alt 文本不是装饰性说明，而是图像信息的等价替代。未翻译的 alt（如 alt="Product photo"）在日文页面里被读作英文，对视障用户毫无意义；更糟的是，有些系统直接留空或复用占位符，导致读屏跳过整张图。
- 所有
<img>的alt属性必须作为翻译资源键（key）纳入 i18n 管理流程，不能靠 JS 拼接或条件渲染绕过 -
<figure><figcaption></figcaption></figure>同样需本地化，且必须与<img>同级、同容器——拆到组件外或用绝对定位脱离 DOM 结构，会切断语义关联 - 装饰性图片也要显式写
alt=""，不能省略；否则多语言构建工具可能注入默认占位值，反而破坏无障碍
最易被忽略的点是：语义结构一旦写死，就不再随语言变化而“自适应”。它不像样式或文案可以热替换——结构错了，所有后续的翻译、ARIA 补充、焦点管理都建立在流沙之上。国际化不是把文字翻出来就完事，而是让每种语言都在同一套语义骨架上准确呼吸。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
