ol被屏幕阅读器识别为“有序列表”，播报序号及顺序语义；ul仅报“无序列表”，不带序号，即使css加数字也无效；选错标签会导致步骤先后、名次高低等关键逻辑信息丢失。
ol 和 ul 在屏幕阅读器中播报逻辑完全不同：前者明确传达“顺序依赖”，后者只表示“并列集合”。选错标签，读屏用户会听不出步骤先后、名次高低，甚至跳过关键结构信息。
屏幕阅读器怎么读ol和ul
不是“读不读编号”的问题，而是语义层的播报差异：
-
ol会被识别为 “有序列表”，屏幕阅读器先报“列表，共4项”，再逐项播报时附带序号（如“1. 预热烤箱”、“2. 混合面粉”），且部分读屏器（如 NVDA）会额外提示“第1项，共4项” -
ul报“无序列表，共4项”，后续仅读内容，不带序号；即使你用 CSS 强行加了数字，读屏器也完全忽略——它只认ol的 DOM 语义 - 如果把排行榜写成
ul，用户听到的是“列表，共3项：金牌、银牌、铜牌”，但无法感知“谁是第一”；换成ol，就会听到“1. 金牌”“2. 银牌”
为什么ol里用start比CSS伪造更可靠
手动在文本里写“5. 设置代理”或用 CSS counter-increment 生成序号，对读屏软件无效。只有原生 start 属性才能被正确解析：
-
<ol start="5"><li>设置代理</li></ol>→ 读屏器播报“5. 设置代理”，且后续项自动递增 -
<ol reversed> <li>金牌</li> <li>银牌</li> </ol>→ 播报“1. 金牌”“2. 银牌”，但视觉上倒序显示（适用于实时更新的倒计时/倒排名） - 旧版安卓 WebView 对
reversed支持不稳定，但 Safari、Chrome、Edge 均已稳定支持；若需兼容极老环境，可降级为两个独立ol+aria-label说明
嵌套列表时，子列表语义必须重判，不能沿用父层
常见错误是看到父层是 ol，就默认子层也该是 ol。但子项之间是否真有顺序？这决定读屏体验：
- 安装指南（
ol）里的“配置选项”是并列开关（启用日志 / 选择语言 / 设置代理）→ 子层必须用ul，否则读屏器会误播“1. 启用日志”“2. 选择语言”，暗示执行顺序 - 面包屑导航必须用
ol，因为路径层级不可逆（首页 → 分类 → 商品），删掉序号后逻辑断裂 →ul会丢失导航意图 -
li内部可嵌套任意流内容，但禁止直接放div；浏览器虽会容错修正，但语义链断裂，读屏器可能跳过整个子列表
表单错误提示、商品列表、标签页这些高频场景该用哪个
别被视觉样式带偏，看逻辑关系：
- 表单校验错误提示（如“邮箱格式错误”“密码长度不足”）→ 项间无顺序，用
ul；若提示含步骤（如“请按以下三步重置密码”），才用ol - 电商商品列表 → 动态排序、筛选结果，顺序随时变化 → 一律
ul；用ol反而误导用户以为“第1个商品最重要” - 标签页（tab）的标题栏 → 必须用
ul包裹，每个li内放button并设role="tab"；这里不用ol，因为“首页/产品/关于我们”不是执行步骤，只是并列入口
最易被忽略的一点：当 ul 或 ol 被 CSS 设为 display: flex 或 float，部分读屏器（尤其旧版 JAWS）会彻底丢失列表角色，退化为普通容器。保持默认块级流，或显式加 role="list" 作为兜底。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
