必须用 ol 标签，因其提供强顺序语义，保障屏幕阅读器朗读“第1步”、js 可定位、seo 可识别；ul 或 div 模拟会导致无障碍失效、逻辑错乱。
ol 标签必须用，不能用 ul 或 div 模拟，否则语义错误、无障碍失效、JS 定位困难。
为什么必须用 ol 而不是 ul 或 div
购物结算步骤是强顺序行为（选地址 → 选支付 → 确认 → 支付），浏览器和屏幕阅读器依赖 ol 的隐含序号语义来朗读“第1步”“第2步”。用 ul 加手动编号（如“1. 选择收货地址”）会导致：
- 屏幕阅读器读作“项目符号、1. 选择收货地址”，失去步骤感
- start 和 type 属性在 ul 上无效
- JS 通过 document.querySelector('ol') 批量操作时取不到节点
- 搜索引擎无法识别该区块为流程性内容，影响 SEO 结构化数据提取
ol 的 type 和 start 怎么配才合理
电商结算页常见三类步骤场景，对应不同属性组合：
- 基础四步流程（地址→支付→核对→提交）：用默认 type="1"，不加 start
- 接续前页（比如“支付方式”是上一页的第3步，本页从第4步开始）：加 start="4"
- 多级嵌套步骤（如“微信支付”展开后有3个子步骤）：外层 ol type="A"，内层 ol type="1"，但注意 li 内必须包裹完整子 ol，不能跨级
- 避免用 type="i"（小写罗马数字）：iOS Safari 对 i 渲染不稳定，可能显示为字母而非序号
实际写法中容易漏掉的关键细节
- ol 内部只能直接放 li，不能放 p、div 或文本；所有描述文字必须包在 li 里
- 每个 li 应包含可交互元素（如 select、radio）时，需确保其 name 属性唯一且与后端约定一致，例如：<li>选择收货地址：<select name="shipping_address_id"></select>
</li>
- 不要给 ol 设 style="list-style: none" 再用伪元素重绘序号——这会让序号脱离语义流，屏幕阅读器完全忽略
- 如果某步需条件跳过（如“余额充足则跳过支付方式选择”），不要删 DOM，而是用 aria-hidden="true" + tabindex="-1" 控制可访问性，保持 DOM 结构稳定
真正难的不是写出编号，而是让编号在语音、键盘、爬虫、JS 逻辑里都“算数”。一旦用错标签，后续所有自动化处理（比如表单校验脚本、无障碍测试工具、SEO 结构化标记提取）都会出偏。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
