不能靠“自动化注入HTML属性”来补可访问性空缺，反而会放大问题；因可访问性树在HTML解析阶段构建，JS动态添加的aria-label、alt等属性不会触发辅助技术重新计算语义节点，必须从模板层或服务端源头修复。
直接说结论：不能靠“自动化注入HTML属性”来补可访问性空缺，反而会放大问题。浏览器不认你后加的aria-label或alt，屏幕阅读器读不到，JS注入的属性在无障碍树里根本不存在。
为什么动态加aria-属性基本无效
可访问性树（Accessibility Tree）是在HTML解析阶段一次性构建的，不是运行时实时同步DOM的。用JS给input补aria-labelledby，或者给img塞alt，这些属性虽然出现在DOM里，但不会触发AT（辅助技术）重新计算语义节点。
- Chrome/Edge 的 Accessibility Inspector 里看不到 JS 后加的
aria-属性生效痕迹 - NVDA/JAWS 在页面加载完成后才初始化可访问性树，后续JS修改不触发重载
-
document.querySelector('img').alt = '描述'这种赋值，对已挂载的img毫无意义——必须是初始HTML里就带alt
真正要修的是HTML生成源头，不是DOM操作
老旧系统里可访问性空缺，90%来自模板层或服务端渲染逻辑漏掉语义输出。比如：include header.inc里没nav包裹导航，contact.html里input没label绑定，login.php输出的密码框缺autocomplete="current-password"。
- 优先改模板：在
header.inc里补<nav aria-label="主导航">，比JS遍历所有ul加role="navigation"靠谱十倍 - 表单字段必须原生带
for/id配对，或用<label><input></label>结构——JS模拟aria-describedby关联错误提示，屏幕阅读器根本不会朗读 - 图片
alt必须由CMS或后端逻辑决定内容，前端JS查数据库再填alt既慢又不可靠，且无法被爬虫和离线阅读器识别
哪些场景下JS补属性“勉强能用”
极少数情况可以靠JS兜底，但必须满足两个硬条件：页面首次加载时立即执行、且只用于修复**非关键语义缺失**。
立即学习“前端免费学习笔记（深入）”；
-
img[alt=""]→ 立即设el.alt = "占位图"（仅限无意义装饰图，业务图必须服务端出alt） - 动态生成的
tablist组件，用el.setAttribute('role', 'tablist')+el.setAttribute('aria-orientation', 'horizontal')（因为这类组件本就依赖JS驱动，AT会监听其role变更） - 富文本编辑器输出的
table缺scope，可在DOMContentLoaded后批量补——但前提是表格结构本身合规，否则补了也白补
最易被忽略的点：很多团队花半天写脚本给所有button加aria-label，却没发现原始HTML里已经有title属性，而title在多数AT中优先级低于aria-label，结果反而覆盖了本可用的信息。修可访问性，先看源码有没有，再看要不要动，最后才考虑怎么动——顺序错了，全白干。
