progress标签原生具备可访问性，无需添加role="progressbar"；必须设置value和max属性，用indeterminate表示不确定进度；需通过label、aria-labelledby或aria-label提供上下文；仅在必要时添加tabindex和aria-live实现键盘交互与状态反馈。
progress标签本身已具备可访问性，别乱套role="progressbar"
HTML5原生<progress></progress>标签自带语义和ARIA支持，浏览器会自动暴露aria-valuenow、aria-valuemin、aria-valuemax等状态，屏幕阅读器能直接读出“进度条，60%完成”。强行加role="progressbar"反而可能覆盖原生语义，导致重复播报或状态丢失。
只有两种情况才考虑手动用role="progressbar"：
- 你用
<div>模拟进度条（比如某些CSS-only方案），且无法改用<code><progress></progress> - 需要兼容极老环境（如IE9及以下），但此时也应优先降级为文本提示而非强行ARIA补救
- 始终提供
value和max属性，哪怕初始值为0 - 动态更新时，只改
value属性，不要只改style.width - 若进度不确定（如加载中），用
<progress indeterminate></progress>，而非设value=""或删掉value - 用
<label for="xxx"></label>显式关联：<label for="upload-progress">文件上传进度</label><progress id="upload-progress" value="45" max="100"></progress> - 用
aria-labelledby指向已有标题：<h3 id="step-title">第2步：正在处理数据</h3> <progress aria-labelledby="step-title" value="70" max="100"></progress> - 用
aria-label（仅当无合适文本节点时）：<progress aria-label="数据同步进度" value="25" max="100"></progress> - 加
tabindex="0"使其可被Tab键聚焦 - 监听
focus事件，用aria-live="polite"区域播报当前值（例如“当前进度：82%”），避免用户聚焦后听不到反馈 - 若支持手动调整（少见），需实现方向键（←→）微调，并同步更新
value和aria-valuenow
必须显式设置value和max，不能只靠CSS控制视觉进度
仅用CSS宽度模拟进度（如width: 60%）对辅助技术完全不可见——它没有数值含义，屏幕阅读器读不出任何进度信息。原生<progress></progress>的可访问性依赖真实属性值。
正确做法是：
错误示例：<progress max="100"></progress>（缺value） → 屏幕阅读器报“进度条，值未知”
label关联不能省，尤其当进度条无相邻文字时
单独一个<progress></progress>元素，即使有value，屏幕阅读器也可能只读“进度条，45%”，用户不知道这是“文件上传进度”还是“表单填写进度”。必须提供上下文。
推荐方案（按优先级）：
避免用title属性替代——它不被所有屏幕阅读器可靠支持，且无键盘焦点路径。
键盘交互和状态反馈容易被忽略
<progress></progress>默认不可聚焦，也不响应键盘操作。如果进度条需要被用户主动关注（比如在多步骤流程中作为导航锚点），就得让它可聚焦并提供状态反馈。
关键动作：
注意：绝大多数进度条是只读状态展示，无需键盘操作；强行加交互反而增加认知负担。是否支持键盘，取决于实际使用场景，不是“为了无障碍而无障碍”。
