ol是展示菜单步骤最语义正确、可访问性最佳的选择，因其天然表达顺序依赖性，支持无障碍api，并确保seo与维护性；嵌套时需将ol直接置于li内，避免用div包裹或误删默认序号样式。

ol 是展示菜单步骤最语义正确、可访问性最好的选择，比用 div + 数字文本或 CSS 伪元素更可靠。

为什么必须用 ol 而不是 ul 或 div

菜单步骤天然具有顺序依赖性——“先点支付，再输密码，最后确认”不能调换。用 ul 会丢失语义，屏幕阅读器无法传达步骤关系；用 div 则完全放弃结构化标记，影响 SEO 和维护性。浏览器对 ol 的默认序号（1. 2. 3.）是可访问的，且支持无障碍 API 暴露 aria-posinset 和 aria-setsize。

ol 的 type 和 start 参数怎么选

多数菜单步骤用默认数字（type="1"）最稳妥，但某些场景需调整：

• 银行类流程常用大写字母：加 type="A"，如 <ol type="A"></ol>
• 中断后继续的步骤（比如“步骤 4–7”），用 start="4"，避免手动写编号
• type="i"（小写罗马数字）适合协议条款等正式文档，但菜单中极少用
• 不要混用 type 和 CSS counter-reset——前者是语义，后者是样式，覆盖会导致序号不可读

嵌套步骤怎么写才不破坏语义

真实菜单常有子步骤（例如“选择支付方式”下再列支付宝、微信），此时应嵌套 ol 或 ul，而非强行扁平化：

Doc To HTML

使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

下载

<ol>
<li>登录账户</li>
  <li>进入订单页</li>
  <li>选择支付方式
    <ol type="a">
<li>支付宝</li>
      <li>微信支付</li>
      <li>银联云闪付</li>
    </ol>
</li>
  <li>确认付款</li>
</ol>

注意：li 内容可以是纯文本、链接、甚至表单控件，但嵌套的 ol 必须直接放在 li 内部，不能包在 p 或 div 里，否则会破坏列表层级逻辑。

容易被忽略的兼容性和样式陷阱

老版本 Safari（iOS 15 之前）对 reversed 属性支持不稳定，但菜单步骤几乎不用它；真正要防的是：

• CSS 中误写 ol { list-style: none; } 后没补序号——必须用 counter 手动实现，否则视障用户完全看不到步骤数
• 用 display: flex 直接作用于 ol，会破坏内置计数器，序号消失且无法恢复
• 服务端渲染时若动态插入 li 却漏了父级 ol，整个结构就退化为无序段落
• 移动端 zoom 缩放时，极小字号下默认序号可能被截断，建议用 line-height 和 padding 预留空间

步骤类内容一旦脱离 ol 的语义容器，后续想加语音导航、打印样式或自动化测试断言，成本会指数级上升。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！