响应式布局若未同步做语义增强，会导致屏幕阅读器用户“看得见却读不懂、点得着却跳不进”；必须用定义唯一主内容区，避免，禁止嵌套于内，js动态更新需加aria-live，导航结构须匹配键盘焦点顺序。
直接说结论：响应式布局若没同步做语义增强，对屏幕阅读器用户来说，就是“看得见却读不懂、点得着却跳不进”的断层体验。光靠 @media 切换样式远远不够，必须从 DOM 结构和语义标签入手。
为什么不能用替代
浏览器和辅助技术依赖语义标签识别内容层级与焦点流。<main></main> 是唯一被 WAI-ARIA 明确定义为主内容区的元素，而 <div id="main"> 在读屏软件眼里只是个普通容器，既不会被自动跳过导航栏、也不会被设为默认阅读起点。
<ul>
<li>每个页面只能有一个 <code><main></main>，重复使用会触发 W3C 验证警告，部分读屏软件（如 NVDA 2025+）会忽略第二个 <main></main>
<main></main> 不能嵌套在 <header></header>、<footer></footer>、<nav></nav> 或 <aside></aside> 内部——否则语义层级错乱，键盘 Tab 流会跳过主内容
JS 动态加载内容时，如果替换的是 <main></main> 内部 HTML，记得同步设置 aria-live="polite"，否则更新内容不会被播报
导航结构必须匹配键盘焦点顺序
响应式菜单常把 <nav></nav> 折叠成汉堡按钮，但很多实现只改了视觉，DOM 顺序和焦点流仍按桌面版排列，导致键盘用户 tab 到隐藏菜单项时卡死或跳过关键链接。
- 用
display: none 隐藏菜单项时，它会同时从可访问树中移除——应改用 visibility: hidden + position: absolute + clip-path 组合，保留语义与焦点可达性
- 移动端
<nav></nav> 中的 <a></a> 必须保持逻辑顺序与视觉顺序一致；避免用 flex-direction: column-reverse 或 order 打乱 DOM 顺序，部分安卓 WebView 和旧版 JAWS 无法正确映射
- 面包屑导航必须用
<nav aria-label="面包屑"><ol>...</ol></nav>，不能用 <div> + CSS 伪元素生成箭头——读屏软件不读伪元素，且 <code><ol></ol> 能提供层级计数信息
图片与媒体内容的语义占位必须提前声明
响应式图片加载抖动不只是体验问题，更是可访问性断裂点：当 <picture></picture> 或 <img> 没设 width 和 height 属性，加载前无占位，屏幕阅读器会先读“图片”，再等加载完成才补读 alt——中间存在不可预测的延迟，用户可能误判内容缺失。
- 必须用 HTML 属性
width 和 height（不是 CSS），浏览器才能在解析阶段预留空间，保证可访问树稳定
-
<picture></picture> 内每个 <source></source> 不需要单独设尺寸，但外层 <img> 必须有 width/height，且建议按最大视口下的实际渲染尺寸设置（例如 width="1200" style="max-width:90%"）
- 装饰性图片用
role="presentation" 或空 alt=""，但绝不能省略 alt 属性——否则会被读作“图片”，引发歧义
最容易被忽略的点是：语义优化不是“加完标签就完事”。比如 <article></article> 套 <section></section> 再套 <header></header>，如果内部没有 <h2></h2> 或更高级别标题，读屏软件会把它当作无结构内容块跳过。语义标签必须配合正确的嵌套层级和标题体系，才能真正生效。
替代
JS 动态加载内容时，如果替换的是
浏览器和辅助技术依赖语义标签识别内容层级与焦点流。<main></main> 是唯一被 WAI-ARIA 明确定义为主内容区的元素，而 <div id="main"> 在读屏软件眼里只是个普通容器，既不会被自动跳过导航栏、也不会被设为默认阅读起点。
<ul>
<li>每个页面只能有一个 <code><main></main>，重复使用会触发 W3C 验证警告，部分读屏软件（如 NVDA 2025+）会忽略第二个 <main></main>
<main></main> 不能嵌套在 <header></header>、<footer></footer>、<nav></nav> 或 <aside></aside> 内部——否则语义层级错乱，键盘 Tab 流会跳过主内容<main></main> 内部 HTML，记得同步设置 aria-live="polite"，否则更新内容不会被播报导航结构必须匹配键盘焦点顺序
响应式菜单常把 <nav></nav> 折叠成汉堡按钮，但很多实现只改了视觉，DOM 顺序和焦点流仍按桌面版排列，导致键盘用户 tab 到隐藏菜单项时卡死或跳过关键链接。
- 用
display: none隐藏菜单项时，它会同时从可访问树中移除——应改用visibility: hidden+position: absolute+clip-path组合，保留语义与焦点可达性 - 移动端
<nav></nav>中的<a></a>必须保持逻辑顺序与视觉顺序一致；避免用flex-direction: column-reverse或order打乱 DOM 顺序，部分安卓 WebView 和旧版 JAWS 无法正确映射 - 面包屑导航必须用
<nav aria-label="面包屑"><ol>...</ol></nav>，不能用<div> + CSS 伪元素生成箭头——读屏软件不读伪元素，且 <code><ol></ol>能提供层级计数信息图片与媒体内容的语义占位必须提前声明
响应式图片加载抖动不只是体验问题，更是可访问性断裂点：当
<picture></picture>或<img>没设width和height属性，加载前无占位，屏幕阅读器会先读“图片”，再等加载完成才补读alt——中间存在不可预测的延迟，用户可能误判内容缺失。- 必须用 HTML 属性
width和height（不是 CSS），浏览器才能在解析阶段预留空间，保证可访问树稳定 -
<picture></picture>内每个<source></source>不需要单独设尺寸，但外层<img>必须有width/height，且建议按最大视口下的实际渲染尺寸设置（例如width="1200" style="max-width:90%"） - 装饰性图片用
role="presentation"或空alt=""，但绝不能省略alt属性——否则会被读作“图片”，引发歧义
最容易被忽略的点是：语义优化不是“加完标签就完事”。比如
<article></article>套<section></section>再套<header></header>，如果内部没有<h2></h2>或更高级别标题，读屏软件会把它当作无结构内容块跳过。语义标签必须配合正确的嵌套层级和标题体系，才能真正生效。 - 必须用 HTML 属性
