ol仅负责语义化编号展示，不可交互；实现工作流程需外层容器+JS控制状态、校验、显隐及焦点，ol只作视觉步骤条且须保障可访问性。

ol 本身不能直接“制作工作流程清单”——它只负责编号语义，不处理状态、跳转、校验或 DOM 显隐。真要实现可交互的工作流程（比如“填写信息 → 上传文件 → 确认提交”），必须用 ol 仅作视觉步骤条，外层加容器和 JS 控制逻辑。

为什么不能只靠 ol 实现工作流程

浏览器把 ol 当成纯静态内容流：它不会响应点击、不保存当前步、不阻止非法跳转、也不校验字段。常见错误包括：

• 用 CSS 隐藏非当前 li，但没同步设 aria-hidden="true" 和 tabindex="-1"，导致键盘焦点仍落入隐藏项
• 用户点“第三步”按钮后，ol 不拦截行为，直接跳转，前两步的必填字段可能为空
• 屏幕阅读器读出全部 li 内容，不管哪步是当前激活态

ol 在工作流程中该承担什么角色

它只做一件事：在顶部展示带编号的步骤名称，且必须保持语义完整。实操要点：

• 用
  包裹每个步骤名，每个 li 带 data-step="1" 作映射，不放交互逻辑
• 步骤名称文字要简短明确，如“填写基本信息”“上传资质文件”，避免动词堆砌
• 禁用 start 或 type 属性做“伪流程控制”，比如用 start="2" 表示从第二步开始——这会让语义断裂，且无法与 JS 状态变量对齐
• 若流程跨页面（如分步表单提交后跳转），不要依赖 ol 的编号连续性，改由后端或路由参数决定当前步

怎么让 ol 步骤条和真实流程联动

核心是「DOM 切换 + 状态变量 + 校验前置」，ol 只是视觉反馈层。关键动作：

财经HTML高端海报生成

复杂得财经如何变成清晰，适合手机看的海报？如何加上你的IP

下载

• 外层用
  包住整个流程，不依赖原生 form 提交
• 每步内容放在独立
  中，显隐靠 JS 切换 aria-hidden 和 tabindex
• 所有导航按钮统一用 type="button"，最后一步的提交按钮才用 type="submit" 并配 event.preventDefault()
• 切换前必须调用对应校验函数，例如：if (currentStep === 2 && validateStep2()) { updateStep(3); }，updateStep() 负责更新 data-step 类、aria-hidden 和焦点管理

容易被忽略的可访问性细节

多数人只关注视觉效果，但工作流程清单面向所有用户。真正影响体验的是这些：

• ol 下每个 li 必须是
• 步骤名
结构，不能直接放按钮或链接——否则屏幕阅读器会把按钮名和步骤名混读
• 当前激活步骤的 li 要加 aria-current="step"，不是 aria-selected 或自定义 data- 属性
• 当用户用键盘 Tab 进入某步内容区时，焦点应自动落到该步第一个可聚焦元素（如第一个 input），而不是卡在 section 上
• 如果某步校验失败，错误消息要通过 aria-live="polite" 区域播报，且不能只靠颜色变化提示

工作流程清单最难的不是写 ol，而是让编号、状态、校验、焦点、语音反馈五者严格同步。少一个环节，就可能让键盘用户卡死、屏幕阅读器误读、或后端收到不完整数据。