应仅在存在明确时间流逝、有终点且具操作约束的倒计时（如考试倒计时、验证码倒计时）中使用 role="timer"，并必须配合 aria-live="polite" 和纯文本内容；库存变动、股价刷新等非时间过程场景不得使用。
role="timer" 什么时候该用，什么时候不该用
只有当页面上存在一个持续更新、且用户需要感知其变化的倒计时（比如考试剩余时间、验证码倒计时、会话自动登出提醒），才考虑用 role="timer"。它不是给所有数字变化的元素贴的“动态标签”——比如商品库存数变动、点赞数增加、实时股价刷新，这些都不属于 role="timer" 的语义范畴。
核心判断标准：是否代表一个明确的时间流逝过程，且该过程有终点、不可逆、对用户操作有约束力。满足这三点，再往下看怎么标。
必须配合 aria-live="polite" 才能被读屏识别
role="timer" 单独存在时，绝大多数读屏软件（NVDA、VoiceOver、JAWS）根本不会播报数值变化。它只是声明“这是一个计时器”，但不触发通告机制。
正确做法是：在包裹倒计时数值的容器上同时设置：
立即学习“前端免费学习笔记（深入）”；
role="timer"-
aria-live="polite"（不能用off或assertive；assertive会打断用户当前操作，倒计时频繁更新时极其干扰） - 确保该容器内只包含纯文本数字（如
"00:42"），不要混入图标、单位文字或额外 HTML 标签
示例结构：
<div role="timer" aria-live="polite">00:42</div>
如果用了 <span>秒</span> 或 <em>剩余</em>，读屏可能重复播报或跳过关键数字。
避免在 DOM 中高频重写 innerHTML
倒计时每秒更新一次，如果每次都用 element.innerHTML = newTime，会导致读屏反复中断并重新解析整个节点——尤其在 Safari + VoiceOver 组合下，可能出现跳读、重复读、甚至卡顿。
更稳妥的做法：
- 用
textContent替代innerHTML更新内容（避免 HTML 解析开销） - 确保容器是空的块级元素（如
<div>或<span>），不带子节点 - 不要在计时器容器上绑定 click 或 focus 事件——它只是信息载体，不是交互控件
错误写法：
<div role="timer" aria-live="polite"><strong>还剩</strong> <span id="countdown">00:42</span> <em>秒</em></div>
这种结构会让读屏把“还剩”“00:42”“秒”拆成三段读，且每次更新
textContent 到 <span> 时，外层 <div> 的 live 区域可能失效。
ChromeVox 和部分旧版 Android TalkBack 不支持 role="timer"
role="timer" 在 ARIA 1.1 中定义，但实际支持度参差不齐。ChromeVox 完全忽略该 role；Android 上低于 API 29 的 TalkBack 版本也不识别。
这意味着：仅靠 role="timer" + aria-live 无法覆盖全部辅助技术。必须做降级处理：
- 为倒计时区域提供明确的上下文文案，比如在计时器上方加一句
<p class="sr-only">考试剩余时间</p> - 确保数值格式清晰（统一用
MM:SS或SS，避免42秒这类带单位的写法） - 在 JS 更新逻辑里，主动触发
aria-label动态更新（虽然冗余，但对 ChromeVox 有效）：timerEl.setAttribute('aria-label', '考试剩余时间 00分42秒');
真正麻烦的不是写法，而是测试环节——你得真机连 NVDA、VoiceOver、TalkBack 各跑一遍，看它到底读了几遍、读得对不对、停不停顿。这点容易被跳过，但恰恰决定残障用户能不能及时退出考试或重发验证码。
