能，但必须注意状态同步时机；DOM构建完成不等于辅助技术立即感知，aria-selected等属性需配合aria-live或焦点移动才能触发播报，初始化可直接设属性，交互反馈则需主动通知。
DOMContentLoaded 时能安全操作 ARIA 属性吗？
能，但必须注意状态同步时机。DOM 构建完成 ≠ 辅助技术已感知变化，aria-selected、aria-expanded 等属性写入后，屏幕阅读器不会立刻播报，除非配合 aria-live 或焦点移动。
常见错误现象：document.getElementById("tab-1").setAttribute("aria-selected", "true") 执行后，用户没听到“已选中”，因为仅改属性不触发语义更新。
- 若需立即反馈，加
<div aria-live="polite" aria-atomic="true"></div>，并在 JS 中写入文本（如liveRegion.textContent = "已切换到选项卡一"） - 若只是初始化状态（如默认选中第一个 tab），直接设属性即可，等用户手动 tab 进来时再由焦点触发播报
- 避免在
DOMContentLoaded中批量修改多个aria-hidden值却不移除旧焦点 —— 容易导致键盘用户陷入“不可聚焦区域”
load 事件里处理可访问性是否更稳妥？
不更稳妥，反而更容易出问题。等所有资源加载完才操作，既延迟又不可靠 —— 比如某张图标 404，load 就永远不触发，ARIA 初始化被卡住。
典型误用场景：把 role="dialog" 的模态框 aria-modal="true" 和焦点陷阱逻辑全塞进 load 回调里，结果用户点击按钮时模态框已渲染但无障碍属性未就位，屏幕阅读器读不出它是模态对话框。
立即学习“前端免费学习笔记（深入）”；
- 模态框这类交互组件，应在 DOM 插入后立即设置角色和属性，而不是等图片/CSS 加载完
-
load只适合依赖资源尺寸的操作，比如根据img.naturalWidth动态调整aria-label描述，但这类需求极少 - 如果必须等某资源（如 SVG sprite），用
img.addEventListener("load", ...)单独监听，别绑整个页面
beforeunload 能用来保存可访问性状态吗？
不能用于主动恢复或同步状态，它只允许弹确认框，且现代浏览器屏蔽自定义文案，无法传达“你的标签页顺序已被保存”之类信息。
常见错误做法：在 beforeunload 里调用 localStorage.setItem("tabOrder", JSON.stringify([...]))，以为能保留用户操作后的 ARIA 排序状态 —— 实际上，下次进入页面时仍需重新初始化，beforeunload 不负责还原。
- 真正该做的是：用户拖拽重排后，立刻存到
localStorage；页面加载时，在DOMContentLoaded阶段读取并同步 DOM + ARIA 状态 -
beforeunload唯一合规用途是防止未保存数据丢失，例如表单草稿，且必须有真实用户交互（如输入过内容）才生效 - 不要给
beforeunload绑定纯初始化逻辑，它不保证执行时机，也不参与可访问性生命周期
键盘焦点首次进入页面时，谁该获得焦点？
不是 document.body，也不是第一个 button，而是主内容起始点 —— 通常是 <main> 或跳转链接（skip link）。
很多页面在 DOMContentLoaded 后没做任何焦点控制，导致键盘用户 Tab 第一下就落在浏览器地址栏，第二次才进页面，体验断裂。
- 推荐模式：在
<body>开头放一个隐藏的<a href="#main-content" class="skip-link">跳至主内容</a>，CSS 设为position: absolute; left: -999px; ...，但:focus时显示 - 首次 Tab 时焦点落到该链接，按 Enter 直接跳到
<main id="main-content">并自动.focus() - SPA 路由切换时，也得手动
mainElement.focus()，不能依赖浏览器默认行为
DOMContentLoaded 是起点，但 ARIA 属性、焦点、aria-live 输出必须按用户实际交互节奏分阶段注入，而不是堆在一个回调里。 
