ol仅负责语义化编号展示，不可交互；实现工作流程需外层容器+JS控制状态、校验、显隐及焦点，ol只作视觉步骤条且须保障可访问性。
ol 本身不能直接“制作工作流程清单”——它只负责编号语义，不处理状态、跳转、校验或 DOM 显隐。真要实现可交互的工作流程（比如“填写信息 → 上传文件 → 确认提交”），必须用 ol 仅作视觉步骤条，外层加容器和 JS 控制逻辑。
为什么不能只靠 ol 实现工作流程
浏览器把 ol 当成纯静态内容流：它不会响应点击、不保存当前步、不阻止非法跳转、也不校验字段。常见错误包括：
- 用 CSS 隐藏非当前
li，但没同步设aria-hidden="true"和tabindex="-1"，导致键盘焦点仍落入隐藏项 - 用户点“第三步”按钮后，
ol不拦截行为，直接跳转，前两步的必填字段可能为空 - 屏幕阅读器读出全部
li内容，不管哪步是当前激活态
ol 在工作流程中该承担什么角色
它只做一件事：在顶部展示带编号的步骤名称，且必须保持语义完整。实操要点：
- 用
<ol class="steps"></ol>包裹每个步骤名，每个li带data-step="1"作映射，不放交互逻辑 - 步骤名称文字要简短明确，如“填写基本信息”“上传资质文件”，避免动词堆砌
- 禁用
start或type属性做“伪流程控制”，比如用start="2"表示从第二步开始——这会让语义断裂，且无法与 JS 状态变量对齐 - 若流程跨页面（如分步表单提交后跳转），不要依赖
ol的编号连续性，改由后端或路由参数决定当前步
怎么让 ol 步骤条和真实流程联动
核心是「DOM 切换 + 状态变量 + 校验前置」，ol 只是视觉反馈层。关键动作：
立即学习“前端免费学习笔记（深入）”；
- 外层用
<div class="workflow"> 包住整个流程，不依赖原生 <code>form提交 - 每步内容放在独立
<section data-step="1" aria-hidden="false"></section>中，显隐靠 JS 切换aria-hidden和tabindex - 所有导航按钮统一用
type="button"，最后一步的提交按钮才用type="submit"并配event.preventDefault() - 切换前必须调用对应校验函数，例如：
if (currentStep === 2 && validateStep2()) { updateStep(3); }，updateStep()负责更新data-step类、aria-hidden和焦点管理 -
ol下每个li必须是<li><span>步骤名</span></li>结构，不能直接放按钮或链接——否则屏幕阅读器会把按钮名和步骤名混读 - 当前激活步骤的
li要加aria-current="step"，不是aria-selected或自定义data-属性 - 当用户用键盘 Tab 进入某步内容区时，焦点应自动落到该步第一个可聚焦元素（如第一个
input），而不是卡在section上 - 如果某步校验失败，错误消息要通过
aria-live="polite"区域播报，且不能只靠颜色变化提示
容易被忽略的可访问性细节
多数人只关注视觉效果，但工作流程清单面向所有用户。真正影响体验的是这些：
工作流程清单最难的不是写 ol，而是让编号、状态、校验、焦点、语音反馈五者严格同步。少一个环节，就可能让键盘用户卡死、屏幕阅读器误读、或后端收到不完整数据。
