是唯一合理起点，必须配合aria-current="step"、可聚焦的及语义化结构才能实现高可访问性；仅作视觉辅助，不可替代步骤数值提示。
纯 HTML 标签本身无法实现“高可访问性”的步骤条——<ol></ol> 是必要基础，但必须配合 ARIA 属性和语义结构才能达标。只写 <ol><li>第一步</li></ol>，屏幕阅读器只会读“列表，1 项”，不会说明这是步骤流程、当前在哪步、是否完成。
为什么 <ol></ol> 是唯一合理起点
浏览器和辅助技术对 <ol></ol> 的原生支持远超 <ul></ul> 或 <div>：它自带顺序语义、默认编号（即使被 CSS 隐藏）、键盘导航天然按序跳转。用 <code><ul></ul> 或一堆 <div> 模拟步骤，等于主动放弃语义层，后续所有 ARIA 补救都事倍功半。
<ul><li>每个步骤必须是 <code><ol></ol> 的直接子元素 <li>，不能嵌套在 <div> 或 <code><span></span> 里
list-style: none 后再靠伪元素重绘编号——这会让编号从可访问树中消失；应保留计数逻辑，仅视觉隐藏counter-reset + counters()，不能依赖浏览器自动嵌套编号
aria-current="step" 必须加在当前 <li> 上
这是告诉屏幕阅读器“你现在正处在哪个环节”的最简有效方式。不加这个属性，用户根本不知道流程进行到哪了——尤其当步骤文字相似（如“填写信息”“确认信息”“提交信息”）时，仅靠视觉色块毫无意义。
- 只给当前活跃的
<li>加aria-current="step"，其他步骤不加；不要用aria-hidden="true"隐藏非当前项，那会切断导航流 - 避免和
role="tab"混用——步骤条不是标签页，aria-current比aria-selected更准确 - 服务端渲染时，该属性应由后端动态注入；前端 JS 切换步骤时，必须同步更新该属性，而非只改 class
进度数值不能只靠 <progress></progress> 标签
<progress></progress> 元素只表达“完成百分比”，不是“第几步 / 共几步”。它的 aria-valuenow 会被朗读为“进度 50%”，而非“步骤 2，共 4 步”，这对多步骤表单是误导。
- 若需数值提示，用
<span></span>包裹文本（如<span>步骤 2，共 4 步</span>），并用aria-live="polite"包裹整个提示区域，确保切换时自动播报 -
<progress value="2" max="4"></progress>可以存在，但仅作视觉辅助；value 必须是数字，不能是字符串 "2" - 别用
<progress></progress>控制步骤显隐或校验逻辑——JS 必须独立维护currentStep状态变量
键盘焦点必须可预测且不丢失
步骤条常被设计成“只读指示器”，但用户可能需要通过 Tab 键快速定位到当前步骤的表单字段。如果 <li> 不可聚焦、或焦点跳转后没落在对应内容区，就等于关闭了键盘用户的入口。
- 当前
<li>应设tabindex="0"，确保能被 Tab 到；非当前项保持tabindex="-1"或不设 - 步骤切换后，焦点必须自动移到该步骤容器内第一个可交互元素（如输入框、按钮），不能停在
<li>自身 - 避免用
display: none隐藏非当前步骤内容——这会让键盘焦点“掉进黑洞”；改用visibility: hidden+position: absolute或 ARIAaria-hidden="true"配合inert属性（需检查兼容性）
真正难的不是写出带圆点和连线的步骤条，而是让每个属性、每个 tabindex、每个 aria-live 的触发时机都严丝合缝。稍有疏忽，视觉上完美的步骤条对屏幕阅读器用户来说就是一堵墙。
