标签需配合aria-label才能让屏幕阅读器区分多个导航区域，否则仅识别为“导航区域”而无法说明具体类型。
只用 <nav></nav> 标签无法让屏幕阅读器区分多个导航区域，必须配 aria-label 才能生效。
为什么 <nav></nav> 单独写没用
浏览器和读屏器（如 NVDA、VoiceOver）看到 <nav></nav>，只会识别为“导航区域”，不说明是主导航、面包屑还是页脚链接。当页面存在多个 <nav></nav> 时，用户完全靠手动摸索，无法快速定位上下文。
- 常见错误写法：
<nav aria-label="Navigation"></nav>——所有导航都叫 Navigation，等于没标 - 更糟的是：
<nav></nav>根本不加aria-label，读屏器静默跳过，键盘焦点停在那儿却听不到任何提示 -
<nav></nav>是语义容器，不是“语义说明书”；它声明“这是导航”，但不回答“这是哪一类导航”
aria-label 的值该怎么写才有效
必须按实际功能命名，且中英文需匹配主流读屏器习惯。值不是越长越好，而是要准确、无歧义、不重复。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 中文推荐：
aria-label="主导航"、aria-label="面包屑导航"、aria-label="页脚快捷链接" - 英文推荐：
aria-label="Main navigation"、aria-label="Breadcrumb"（注意不是 "Breadcrumbs"） - 禁用空泛词：
"Navigation"、"Menu"、"Links"—— 读屏器已知角色，缺的是“做什么” - 避免拼写变体或大小写混用，否则某些组合（如 Chrome + VoiceOver）可能无法稳定识别
导航内部结构该用 <ul></ul> 还是 <ol></ol>
不能用 <div> 堆链接，也不能裸写 <code><a></a>。结构选择取决于是否有明确顺序或层级关系。
- 主导航、页脚链接等无强序关系的集合 → 用
<ul><li><a></a></li></ul>，语义清晰且兼容性好 - 面包屑、步骤条、路径类导航 → 必须用
<ol><li><a></a></li></ol>，读屏器会读出“第1项”“第2项”，帮助用户感知深度 - 禁用
role="list"或role="navigation"套在<ul></ul>上——重复声明，反而干扰默认行为 - 每个链接必须是
<a href></a>或<button></button>，不能用<div> + click 事件模拟 <h3>当前页链接怎么标才对</h3> <p>当前页不是“禁用按钮”，而是“语义终点”。误用 <code>aria-disabled="true"或移除href会导致键盘用户无法聚焦、读屏跳过，甚至误报“已禁用”。- 必须保留
href（哪怕指向当前 URL），确保可聚焦、可回车触发（JS 可拦截） - 仅在当前页对应的
<a></a>上加aria-current="page"，值只能是"page"（不是"true"或"active"） - 分隔符（如
/或>）要用<li aria-hidden="true">包裹，或纯 CSS 伪元素生成，避免被读出 - 不要给整个
<nav></nav>加aria-current，它只作用于具体链接元素
最容易被忽略的是：多个
<nav></nav>共存时，漏掉任意一个的aria-label，都会导致部分导航对辅助技术“不可见”。这不是样式问题，是结构缺失——补上后无需 JS，立刻生效。 - 必须保留
