可访问性是页面结构的默认状态，而非附加功能；正确使用语义化标签（如、、）可解决80%基础无障碍问题，因其天然具备焦点管理、角色声明、键盘支持与屏幕阅读器兼容能力。
可访问性不是附加功能，而是页面结构的默认状态。用对语义化标签，80% 的基础无障碍问题就不存在了。
为什么 <button></button> 不能换成 <div> onclick
<p>视觉上看起来一样，但屏幕阅读器完全不知道这个 <code><div> 是按钮；键盘用户按 Tab 键时它根本不会被聚焦，回车或空格也无法触发操作。
<ul>
<li>
<code><button></button> 自带 tabindex="0"、role="button"、键盘事件支持（Enter/Space）、焦点样式和禁用态（disabled）
<div> 模拟，必须手动补全：<code>tabindex="0"、role="button"、onkeydown 监听、aria-pressed 状态管理、CSS 焦点轮廓 —— 漏一项，就断链
<div> 导致视障用户无法完成关键操作
<h3>
<code><label></label> 和 for 属性不配对，表单就废了一半
没关联的 <input>，屏幕阅读器只会读“编辑框”，不读“邮箱”或“密码”，用户根本不知道该填什么。
- 显式关联：给
<input id="email">配<label for="email">邮箱地址</label> - 隐式关联更稳：直接把
<input>套进<label></label>里，for和id就不用管了 - 注意：
<input type="radio">或<input type="checkbox">必须每个都配独立<label></label>，共用一个会导致点击错位或状态不同步
<caption></caption> 不是装饰，是表格的「说明书」
没有 <caption></caption> 的表格，对屏幕阅读器来说就像一本没目录的书 —— 用户得一行行听，直到猜出这是价格表还是人员名单。
-
<caption></caption>必须紧贴<table> 开始标签后，不能放 <code><thead> 里，也不能用 CSS 移到别处 <li>内容要具体：“2026 年 Q2 销售数据”比“销售数据”好，“用户注册信息表”比“信息表”明确</li> <li>如果表格有多个逻辑块（如汇总+明细），优先拆成两个独立 <code><table> + 各自 <code><caption></caption>，别靠<th colspan> 强撑 <h3>键盘焦点顺序乱，等于把用户扔进迷宫</h3> <p>Tab 键跳转顺序和视觉流不一致时，键盘用户会反复迷失 —— 比如先聚焦页脚的“回到顶部”，再跳到导航栏，最后才到主标题。</p> <ul> <li>HTML 源码顺序就是默认焦点流，别靠 <code>tabindex="1"之类强行干预（tabindex大于 0 会破坏自然流） - 模态框打开时，焦点必须锁在内部：第一个可聚焦元素自动获得焦点，
Tab循环只在模态内，Esc关闭后焦点回归触发按钮 - 动态插入的内容（如搜索建议列表）要主动
.focus()到第一个选项，否则键盘用户卡在输入框出不来
真正难的不是写 <caption></caption> 或 <label></label>，而是习惯性地问自己：如果我看不见、不能用鼠标、或者读屏软件正在读，这段 HTML 能说清它是什么、在哪、怎么用吗？
