必须使用<main>标记页面主体内容，因其是屏幕阅读器识别正文的唯一可信锚点；缺失时系统退查role="main"或从首个<section>起算，易致用户多次下拉才触达正文。

为什么

缺失会让屏幕阅读器“瞎找正文”

几乎所有主流屏幕阅读器（NVDA、VoiceOver、TalkBack）都把 <main></main> 当作页面主体内容的唯一可信锚点。没它，系统只能退而求其次：先查 role="main"，再找不到就从第一个 <h1></h1> 开始算正文——但页眉里常有 <h1></h1>，结果用户下拉7–12次才摸到真正要读的内容。

硬约束必须遵守：<main></main> 每页只能出现一次；不能嵌套在 <header></header>、<footer></footer>、<nav></nav> 内；JS 动态替换内容时，记得同步加 aria-live="polite"，否则更新不播报。

用

代替

不是可选，是必须

屏幕阅读器不解析 CSS 类名，也不猜测你“想表达什么”。<nav></nav> 自带 role="navigation"，且被固化为地标（landmark），支持 N 键跳入；<div class="nav"> 的 computed role 是 <code>generic，读屏器只当它是普通容器，连“导航”两个字都不会提。

常见踩坑点：

立即学习“前端免费学习笔记（深入）”；

• 多个 <nav></nav> 都没加 aria-label，全部朗读为“导航”，用户无法区分主导航、页脚导航或面包屑
• 用 <div role="navigation"> 替代 <code><nav></nav>，但漏掉 tabindex="0"，键盘用户根本无法聚焦
• React 组件中用 <div id="app"> 包全局，子组件里却没放 <code><nav></nav>，导致整个导航区块不可跳转

  表格、表单、图片这些高频元素怎么补语义

  传统响应式模板常只顾视觉折叠，忽略结构语义迁移。比如移动端把表格改成卡片视图，若只靠 CSS display: block 和伪元素，屏幕阅读器仍按原始表格结构朗读，用户听到的是一串无上下文的单元格值。

  

  html-to-pptx-converter

  使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

  下载

  实操建议：

  • 表格行转卡片时，用 role="region" + aria-labelledby 关联动态生成的标题，确保每张卡片有独立语义边界
  • 表单控件必须显式绑定 <label for="id"></label>，禁用嵌套写法；多选组务必用 <fieldset></fieldset>+<legend></legend>，否则读屏器无法识别分组意图
  • <img alt="HTML响应式模板如何优化屏幕阅读体验" > 的 alt 要具体，如“作者在2025年数字出版峰会上发言”，不能写“图片1”；<picture></picture> 里每个 <source></source> 不需重复 alt，只在最内层 <img alt="HTML响应式模板如何优化屏幕阅读体验" > 上写一次

  响应式断点切换时，DOM顺序和焦点流容易断掉

  很多模板用媒体查询隐藏/显示导航菜单，但 DOM 顺序仍是桌面版结构：主菜单在 HTML 里靠后，却被 CSS position: absolute 拉到顶部。键盘用户 tab 到隐藏项时卡死，或直接跳过关键链接。

  真正有效的做法是：

  • 保持语义结构不变：主导航始终放在 <header></header> 内，且 DOM 位置早于 <main></main>
  • 用 display: none 或 visibility: hidden 控制可见性，避免 position: absolute + z-index 打乱焦点流
  • 汉堡菜单展开时，用 focusable 属性或 JS 主动 .focus() 把焦点移到第一个菜单项

  复杂点在于：语义结构不能靠 JS 补救，必须在初始 HTML 里就写对。一旦 DOM 顺序错，后续所有 ARIA 补丁都像往漏水桶里灌水——灌得越勤，漏得越急。