应根据语义选择列表标签：无序用，有序用，术语解释用
用 <ul></ul> 和 <ol></ol> 区分语义，别只看样式
浏览器默认渲染下，<ul></ul> 和 <ol></ol> 看起来只是圆点和数字的区别，但语义完全不同。屏幕阅读器、SEO 抓取、甚至某些编辑器的结构导航都依赖这个区别。<ul></ul> 表示项目之间无顺序依赖（比如“支持的浏览器”），<ol></ol> 表示步骤或优先级（比如“安装步骤 1–3”）。用错会导致辅助技术误读，也增加后期维护成本。
实操建议：
- 先问自己：这些项调换顺序是否影响含义？是 → 用
<ol></ol>；否 → 用<ul></ul> - 不要为了省事全用
<ul></ul>再 CSS 改成数字，这绕过了语义层 -
<ol></ol>支持start、reversed、type属性，但仅在必要时用（如法律条文编号从 5 开始）
<dl></dl> 不是“列表替代品”，它专用于名词-解释对
<dl></dl> 常被误当成“更灵活的列表”，结果写成 <dt>项目1</dt>
<dd>说明</dd>
<dt>项目2</dt>
<dd>说明</dd> 这种松散结构。但它真正的场景是术语表、属性描述、API 参数文档——每个 <dt></dt> 应是一个明确的“名词/关键词”，<dd></dd> 是对其的直接解释，且允许一个 <dt></dt> 对应多个 <dd></dd>（比如同义词共用一个解释）。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 把导航菜单、商品列表硬塞进
<dl></dl>，导致语义混乱、键盘焦点逻辑异常 -
<dt></dt>里嵌套标题（<h3></h3>）或链接，破坏定义列表的扁平语义层级 - 忽略
<dl></dl>的可访问性特性：部分读屏软件会将<dt></dt>读作“术语”，<dd></dd>读作“定义”，乱用会让用户困惑
嵌套列表要控制深度，避免语义坍塌
HTML 允许 <ul></ul> 里嵌 <ol></ol>，再嵌 <dl></dl>，但超过两层就会让结构难以理解。特别是当 <li> 内部又出现 <ul></ul>，而父级没做视觉区分时，用户根本分不清哪级是主干、哪级是补充。
使用场景提示：
- 二级嵌套合理：比如菜单项（
<ul></ul>）→ 子菜单（<ul></ul>）→ 但第三级就该考虑是否该拆成独立区块或用其他交互方式（如折叠面板） - 嵌套时必须用 CSS 显式区分缩进、符号、间距，不能依赖默认样式——否则移动端可能完全看不出层级
- 避免在
<dl></dl>的<dd></dd>里直接嵌<ul></ul>来“罗列细节”，应优先判断这些细节是否属于同一解释范畴；如果不是，可能该拆成多个<dl></dl>
无障碍要点：别漏掉 role="list" 和 aria-labelledby
纯 CSS 生成的内容（比如伪元素 ::before 模拟的列表符号）或 JS 动态插入的列表，浏览器可能无法识别为真实列表，导致屏幕阅读器跳过或误读为普通段落。这时候需要补足语义钩子。
实操建议：
- 动态渲染的列表容器，加上
role="list"；每个条目加role="listitem"（注意：仅当原生<ul>/</ul> <ol>/<li> </ol>不可用时才用，优先用原生标签） - 给列表加
aria-labelledby="id"，指向一个<h2></h2>或<span id="id"></span>，让读屏软件能播报“菜单列表”“配置项列表”这类上下文 - 慎用
aria-hidden="true"在列表符号上——隐藏了视觉符号，却没提供替代文本，等于剥夺了所有用户对列表结构的感知
最常被忽略的是：以为用了 <ul></ul> 就自动无障碍，其实没有标题关联、没有焦点管理、嵌套过深，照样会让键盘用户迷失。语义只是起点，不是终点。
