HTML步骤条仅为视觉容器，无流程引导能力；是否需要JS控制取决于业务逻辑需求，如多步表单必须校验、同步状态、维护aria属性并处理前后导航逻辑。
HTML 步骤条本身不自带流程引导能力，它只是视觉容器；是否需要流程引导，取决于你是否要控制用户操作顺序、校验状态或同步 UI 与业务逻辑。
步骤条不等于流程控制
用 <ol> 或 <div class="step"> 渲染的步骤条，本质是静态结构。点击第 3 步不会自动跳转、不会阻止未完成第 2 步就提交、也不会高亮“已完成”状态——这些都得靠 JS 主动实现。
- 纯 HTML/CSS 步骤条只负责展示，
aria-current和aria-disabled等属性需手动维护 - 浏览器不会因步骤条存在而限制表单提交或路由跳转
- 无障碍支持（如屏幕阅读器播报进度）必须配合语义化标签 + 动态
aria-valuenow更新
什么时候必须加流程引导
当步骤之间有强依赖关系时，比如注册多步表单、安装向导、支付流程，就必须用 JS 控制步骤流转逻辑，否则用户可能跳过必填项或触发非法状态。
- 用户点击未完成步骤时，应
preventDefault()并提示“请先完成上一步” - 每步离开前需调用校验函数（如
validateStep2()），仅当返回true才允许进入下一步 - URL 路径（如
/setup/step3）和步骤条高亮状态需双向同步，避免刷新后丢失上下文
aria- 属性不是摆设，但不能替代逻辑
aria-disabled="true" 可让屏幕阅读器知道某步不可点，但它不会禁用 DOM 事件——你仍需在 click 处理中判断并拦截。
立即学习“前端免费学习笔记（深入）”；
- 错误写法：
<button aria-disabled="true">下一步</button>却没绑定onclick拦截 - 正确做法：用
disabled属性（对原生按钮生效）或pointer-events: none+aria-disabled双保险 -
aria-label建议包含当前步骤状态，例如"步骤2：填写信息，已完成"，而非静态文本
最常被忽略的是「后退」逻辑：用户点上一步时，是否该清空后续步骤数据？是否要重新校验？这些细节不写进 JS，步骤条再好看也只是个装饰画。
