可访问性标签必须由人基于上下文明确赋予，不能自动植入；因HTML结构不携带语义意图，自动方案易导致aria-label冗余、aria-labelledby失效或label错配，仅能通过ESLint检测、组件props约束和测试断言等手段防遗漏。
不能自动植入可访问性标签——所有“自动”方案都会漏掉语义判断，最终导致 aria-label 冗余、aria-labelledby 指向失效，或 label 与控件错配。可访问性标签必须由人基于上下文明确赋予。
为什么没有真正的“自动植入”方案
可访问性标签的本质是传达意图和关系，而 HTML 结构本身不携带这些信息：
-
input元素无法自行知道它代表“收货地址”还是“账单地址”，即使 name="address" -
div包裹的图标按钮不会主动声明自己是“关闭模态框”，除非你写aria-label="Close dialog" - 屏幕阅读器依赖的是 DOM 中显式存在的语义（如
for、aria-labelledby、role），而不是推断出来的“合理猜测”
所谓“自动注入”工具（比如某些构建时插件或 Linter 规则）最多只能做机械补全：给无 label 的 input 加 aria-label="input"，这反而会触发 WCAG 错误——因为标签必须是具体、有意义的。
哪些场景容易被误认为可以“自动处理”
开发者常想让工具代劳的地方，恰恰是语义最敏感的区域：
立即学习“前端免费学习笔记（深入）”；
-
汉堡菜单按钮：仅靠
for="nav-toggle"不够，必须配aria-label="Toggle navigation menu"或嵌套可见文本；自动加aria-label="menu"是无效的 -
搜索框：placeholder="Search..." 不能替代
label或aria-label；自动移除 placeholder 并塞一个空aria-label会让屏幕阅读器读不出任何内容 -
步骤向导中的当前步：
aria-current="step"必须由逻辑层动态设置，不能靠 class 名“active”自动推导——因为 class 可能被复用、误标或未更新 -
自定义下拉/多选组件：原生
select自带语义，但用div+button+ul实现时，role="combobox"、aria-haspopup、aria-expanded全部需手写，且状态必须与 JS 逻辑严格同步
真正能“半自动化”的边界在哪里
可以在开发流程中设防，但不是生成标签，而是防止遗漏：
- 用 ESLint 插件
eslint-plugin-jsx-a11y检测缺失的label、alt、role必填属性，报错而非静默补全 - 在组件库中把
aria-label或label设为 required prop，强制调用方传值（例如：<Button aria-label="Submit form">） - 用测试断言检查 DOM 是否包含必要属性：
expect(screen.getByRole('button')).toHaveAttribute('aria-label') - 对表单控件统一封装 hook，比如
useAccessibleInput({ label: 'Email', required: true })，内部返回带id和绑定逻辑的label+input，但 label 文本仍由调用方传入
最后一点最容易被忽略：所有 ARIA 属性都依赖真实状态。比如 aria-expanded="true" 必须和实际展开行为一致——如果 JS 没更新这个值，或者用了 CSS visibility: hidden 而非 aria-hidden="true"，辅助技术就会得到完全错误的反馈。
