为什么你的 HTML 结构对屏幕阅读器不友好以及如何修复

屏幕阅读器读不懂你的页面，90% 的情况不是缺 ARIA，而是原生 HTML 语义用错了：拿 <div> 当按钮、标题层级乱跳、图片没有 alt、表单控件没有 <label>、页面缺地标（landmark）。修复顺序应该是先改语义标签，再补名称和替代文本，最后才动 ARIA——原生 HTML 能解决的，永远不要用 ARIA 顶上去。

屏幕阅读器到底是怎么"看"页面的？

结论：屏幕阅读器不读你的 CSS，它读的是浏览器生成的可访问性树（accessibility tree），每个节点由「角色 + 名称 + 状态」三部分组成。

你用 <div onclick="...">提交</div>，在可访问性树里它的角色是 generic（通用容器），名称是空的，屏幕阅读器会把它念成一句普通的"提交"文本，用户根本不知道这是个能按的按钮。而 <button>提交</button> 的角色是 button，键盘 Tab 能聚焦，Enter 和空格都能触发。

主流组合是 Windows 上的 NVDA（免费开源）和 JAWS、macOS/iOS 的 VoiceOver、Android 的 TalkBack。它们都依赖同一套语义，所以修语义等于一次修好四个平台。

为什么 <div> 和 <span> 满天飞的页面最难用？

结论：非语义标签拿不到键盘焦点，也无法被快捷键导航，等于把功能对键盘和屏幕阅读器用户直接关闭。

常见的三类错误和对应写法：

• 假按钮：<div class="btn" onclick="submit()"> → 改成 <button type="button">。
• 假链接：<a href="#" onclick="..."> → 跳转用 <a href="/real-url">，触发操作用 <button>。
• 假标题：<p class="title-big"> → 改成 <h2>，字号大小交给 CSS 控制。

如果确实绕不开，最低补救是 role="button" tabindex="0" 再加 keydown 里监听 Enter 和空格——但这只补了角色和焦点，键盘事件、禁用状态、表单提交行为还得自己写一遍，成本远高于直接用 <button>。

标题层级和地标为什么决定用户能不能"跳读"？

结论：屏幕阅读器用户靠标题和地标跳转，而不是靠鼠标滚动，层级混乱就等于让他们一屏一屏硬读。

NVDA 里按 H 跳下一个标题、按 1 到 6 跳到指定级别标题；VoiceOver 用转子（Rotor，Control+Option+U）列出所有标题和地标。所以：

1. 一个页面只保留一个 <h1>，从 h1 到 h6 不跳级（h2 下面直接出现 h4 就是错的）。
2. 用 <header>、<nav>、<main>、<aside>、<footer> 划分区域，它们会自动映射成 banner、navigation、main、complementary、contentinfo 五个地标，<main> 每页只能有一个。
3. 页首第一个可聚焦元素放跳过导航链接：<a href="#main" class="skip">跳到主内容</a>，并给它 CSS :focus 时可见的样式，否则键盘用户看不到它。

图片、表单、表格这三类要具体怎么写？

结论：图片看用途决定 alt，表单靠 <label> 而非 placeholder，表格必须标出表头。

• 装饰性图片写 alt=""（空值，屏幕阅读器直接跳过）；信息性图片写实际内容，例如 alt="2024 年 Q3 营收增长 18%"；不要写 alt="图片" 这类无信息文本。
• 表单：<label for="email">邮箱</label><input id="email" type="email">。placeholder 在输入后消失，不能替代 label。错误提示用 aria-live="polite" 让屏幕阅读器自动播报。
• 表格：加 <caption> 说明用途，表头用 <th scope="col"> 或 scope="row"，屏幕阅读器会在读每个单元格时播报对应表头。
• 页面根元素写对语言：<html lang="zh-CN">，这直接影响语音合成用哪种发音规则。

改完怎么验证有没有真的修好？

结论：三分钟就能自测——拔掉鼠标只用键盘，再开一次屏幕阅读器。

1. 只用 Tab 走一遍：焦点顺序是否和视觉顺序一致？有没有任何地方"卡住"或丢失焦点？焦点框是否可见（不要写 outline: none 而不给替代样式）？
2. 开 NVDA 或 VoiceOver 听一遍：按钮是否念成"按钮"、图片是否念出有意义内容、标题列表是否层次清晰。
3. 用工具扫：Chrome DevTools 的 Elements → Accessibility 面板可以直接看可访问性树；Lighthouse 的无障碍评分和 axe DevTools 扩展能列出缺 label、对比度不足等问题。注意自动化工具只能查出约三成的无障碍问题，键盘实测不可省。

一句话收束：屏幕阅读器友好度不是加几个 aria- 属性，而是把 <div> 换回 <button>、把层级理顺、把 alt 和 <label> 补全，再用键盘和屏幕阅读器各走一遍。