最有效、成本最低的方式是写对语义化标签，而非堆砌ARIA属性；90%以上的无障碍问题可通过正确使用<button>、<nav>、<main>、<label>等原生标签解决，因其自带隐式ARIA语义、键盘可访问性及屏幕阅读器兼容性，而滥用<div>配合ARIA不仅增加维护成本，更易引发解析错误。
直接说结论：提升HTML无障碍访问性，最有效、成本最低的方式是写对语义化标签，而不是堆砌ARIA属性。90%以上的可访问性问题，靠正确使用原生HTML就能解决。
怎么选对语义化标签而不是
很多页面一打开就全是
、，这是无障碍的头号隐患。屏幕阅读器不认class，只认标签本身携带的语义。
-
<button>必须用于所有可点击操作，哪怕它看起来像文字链接——<a href="#">只用于跳转，<button>用于触发行为
-
<nav>只能包裹导航链接，不能塞搜索框或登录入口；多个导航区要加aria-label区分，比如<nav aria-label="主导航">
-
<main>在整个页面中只能出现一次，且必须包含核心内容；<section>不是“分块容器”，它得有独立主题和标题（<h2>及以上）
- 表格结构里，
<th>必须带scope属性，<caption>必须紧贴<table>开头，否则读屏器根本不知道这是一张什么表
表单控件为什么总被读成“编辑框”而不是“邮箱”
因为没用<label>关联，或者用了aria-label但覆盖了真实字段名。屏幕阅读器优先读label文本，其次才 fallback 到aria-label，而aria-label会完全屏蔽label内容。
- 首选显式关联：
<label for="email">邮箱地址</label><input type="email" id="email">
- 嵌套写法也行：
<label>手机号<input type="tel" name="phone"></label>，但注意不要嵌套多个交互元素
- 密码强度提示这类辅助说明，用
aria-describedby指向<div id="pwd-hint">，别塞进label里
- 必填字段加
required属性，同时视觉上用星号，再配合aria-required="true"——三者缺一不可
键盘焦点为什么总卡在某个地方出不来
常见原因是tabindex值设错，或自定义组件没处理Enter/Space事件。屏幕阅读器用户95%靠Tab键导航，焦点跳失等于功能不可达。
立即学习“前端免费学习笔记（深入）”；
- 永远不要用
tabindex="1"或更大值——它会打乱自然顺序，导致焦点先跳到页脚再回顶部
- 只有需要键盘聚焦的非交互元素才加
tabindex="0"，比如<div role="button">（但更推荐直接改用<button>）
- 所有
role="button"、role="link"等都必须监听keydown，响应Enter和Space，否则键盘用户点不动
- 模态框打开后，焦点必须移到第一个可聚焦元素；关闭时，焦点要回到触发按钮——否则用户会“掉进空白”
ARIA属性什么时候该用、什么时候不该用
ARIA不是补丁，而是“不得已的说明书”。浏览器和读屏器已经知道<button>是按钮、<input type="checkbox">是复选框，你再加role="button"反而干扰解析。
- 仅当原生标签无法表达意图时才用ARIA：比如用
<div>实现的滑块，必须加role="slider" + aria-valuenow等一整套状态属性
-
aria-live="polite"适合表单提交成功提示，但别用在每输入一个字就播报的场景——会打断用户思考
- 禁用
aria-hidden="true"在交互元素上，比如<button aria-hidden="true">会让按钮彻底消失在可访问性树里
- 复杂表格用
headers属性绑定<td>和多个<th>，而不是靠视觉对齐猜测归属关系
真正难的不是查文档配齐所有属性，而是在敲下<div>前，本能地停顿半秒，问自己：“有没有一个原生标签能干这事？”这个条件反射，比任何自动化检测工具都管用。
很多页面一打开就全是
、
，这是无障碍的头号隐患。屏幕阅读器不认class，只认标签本身携带的语义。
-
<button>必须用于所有可点击操作，哪怕它看起来像文字链接——<a href="#">只用于跳转，<button>用于触发行为 -
<nav>只能包裹导航链接，不能塞搜索框或登录入口；多个导航区要加aria-label区分，比如<nav aria-label="主导航"> -
<main>在整个页面中只能出现一次，且必须包含核心内容；<section>不是“分块容器”，它得有独立主题和标题（<h2>及以上） - 表格结构里，
<th>必须带scope属性，<caption>必须紧贴<table>开头，否则读屏器根本不知道这是一张什么表
表单控件为什么总被读成“编辑框”而不是“邮箱”
因为没用<label>关联，或者用了aria-label但覆盖了真实字段名。屏幕阅读器优先读label文本，其次才 fallback 到aria-label，而aria-label会完全屏蔽label内容。
- 首选显式关联：
<label for="email">邮箱地址</label><input type="email" id="email"> - 嵌套写法也行：
<label>手机号<input type="tel" name="phone"></label>，但注意不要嵌套多个交互元素 - 密码强度提示这类辅助说明，用
aria-describedby指向<div id="pwd-hint">，别塞进label里 - 必填字段加
required属性，同时视觉上用星号，再配合aria-required="true"——三者缺一不可
键盘焦点为什么总卡在某个地方出不来
常见原因是tabindex值设错，或自定义组件没处理Enter/Space事件。屏幕阅读器用户95%靠Tab键导航，焦点跳失等于功能不可达。
立即学习“前端免费学习笔记（深入）”；
- 永远不要用
tabindex="1"或更大值——它会打乱自然顺序，导致焦点先跳到页脚再回顶部 - 只有需要键盘聚焦的非交互元素才加
tabindex="0"，比如<div role="button">（但更推荐直接改用<button>） - 所有
role="button"、role="link"等都必须监听keydown，响应Enter和Space，否则键盘用户点不动 - 模态框打开后，焦点必须移到第一个可聚焦元素；关闭时，焦点要回到触发按钮——否则用户会“掉进空白”
ARIA属性什么时候该用、什么时候不该用
ARIA不是补丁，而是“不得已的说明书”。浏览器和读屏器已经知道<button>是按钮、<input type="checkbox">是复选框，你再加role="button"反而干扰解析。
- 仅当原生标签无法表达意图时才用ARIA：比如用
<div>实现的滑块，必须加role="slider"+aria-valuenow等一整套状态属性 -
aria-live="polite"适合表单提交成功提示，但别用在每输入一个字就播报的场景——会打断用户思考 - 禁用
aria-hidden="true"在交互元素上，比如<button aria-hidden="true">会让按钮彻底消失在可访问性树里 - 复杂表格用
headers属性绑定<td>和多个<th>，而不是靠视觉对齐猜测归属关系
真正难的不是查文档配齐所有属性，而是在敲下<div>前，本能地停顿半秒，问自己：“有没有一个原生标签能干这事？”这个条件反射，比任何自动化检测工具都管用。
