搜索结果列表必须用<ol>而非<ul>或<div>，因其自带序号语义，支持屏幕阅读器播报“第1条结果”并实现快捷键跳转；每项需可聚焦、有上下文描述，分页须与列表语义关联，搜索框需用aria-controls指向结果ID。
搜索结果页面的列表结构必须是 <ol></ol>，不是 <ul></ul>，更不能用一堆 <div> 堆砌 —— 因为结果天然有序（相关性、时间、权重），屏幕阅读器依赖这个序号播报“第 1 条结果”“共 12 条”，跳过它等于砍掉辅助功能的第一道入口。
<h3>为什么必须用 <code><ol></ol> 而不是 <ul></ul>
搜索结果有明确排序逻辑：相关度得分、发布时间、广告标识优先级等。用 <ul></ul> 会丢失「顺序」语义，NVDA 或 VoiceOver 读出来就是“项目、项目、项目…”，用户无法判断当前在第几条，也无法用快捷键跳转到“第 5 条”。<ol></ol> 自带隐式计数，且支持 start、reversed 等属性应对分页或倒序场景。
- 不要手动加序号文字（如
<li>1. 标题</li>），那只是视觉模拟，对辅助技术无效 - 避免用 CSS 的
counter()替代原生序号，它不参与 ARIA 列表计数逻辑 - 如果结果含广告或推广标记，用
role="region"+aria-label单独包裹，别混进主<ol></ol>
<li> 内部结构要能独立聚焦与描述
每条结果本质是一个可操作单元：点击跳转、键盘回车触发、可能带收藏/分享按钮。这意味着每个 <li> 必须能被键盘 Tab 进入，且自带上下文说明。
- 给
<li>加tabindex="0"（仅当内部无焦点元素时）；更推荐把链接<a>设为第一个子元素并确保可聚焦 - 用
aria-labelledby指向内部标题元素（如<h3 id="r1-title">HTML 列表最佳实践</h3>），让屏幕阅读器读出“HTML 列表最佳实践，来自 developer.mozilla.org，2025 年发布” - 避免把摘要段落塞进
<span>或<div>—— 改用<p>，它自带段落语义和语音停顿
分页导航必须与结果列表建立语义关联
分页控件（上一页 / 1 / 2 / 下一页）如果孤立放在 <ol></ol> 外，会被读作两个无关区块。用户翻到第 3 页后，无法确认当前浏览的是哪一批结果。
立即学习“前端免费学习笔记（深入）”；
- 把分页放入
<nav aria-label="搜索结果分页">，并用aria-describedby指向结果列表的id（如aria-describedby="search-results"） - 给
<ol id="search-results"></ol>加aria-live="polite"，当 JS 动态加载新结果时，屏幕阅读器会自动播报“已加载 10 条新结果” - 禁用的页码按钮（如当前页“2”）必须设
aria-current="page"，而非仅靠 CSS 灰色样式
最常被忽略的是：搜索框的 aria-controls 属性没指向结果列表 ID，导致用户输入后，屏幕阅读器根本不知道结果在哪刷新 —— 这比样式丑陋更致命。
