侧边栏中的导航链接必须用<nav>，含辅助内容时外层用<aside>；<nav>强调跳转行为并需aria-label和aria-current，<aside>表示补充关系且不绑定位置；多模块应分层嵌套，CSS与JS须协同保障可访问性。
侧边栏是导航功能，必须用 <nav>
如果侧边栏里放的是跳转链接（比如“前端技术”“后端专栏”“归档”），它就是导航，不是装饰或容器。浏览器、读屏器、搜索引擎都靠 <nav> 标签识别“这是可跳转的导航区”。用 <div> 或 <aside> 包住这些链接，等于主动放弃语义——键盘用户按 Tab 时可能跳过，SEO 会弱化这些链接权重，辅助技术也无从得知这是导航入口。
常见错误现象：
• 页面有多个 <nav> 却没加 aria-label，读屏器报“导航”但不说清是哪个；
• 把整个侧边栏（含广告、作者简介）全塞进一个 <nav>，污染了导航语义；
• 在 <nav> 外层又套 <aside>，结构冗余且违反嵌套逻辑。
实操建议：
• 每个独立导航区域单独用 <nav>，并带 aria-label，例如 <nav aria-label="文章分类导航">；
• 当前激活项加 aria-current="page"，让读屏器明确告知用户“你在这儿”；
• 链接列表统一用 <ul><li><a>，别用 <p> 或 <div> 模拟列表。
侧边栏含辅助内容时，<aside> 是正确容器
<aside> 不是“侧边栏视觉位置”的标签，而是“附属内容”的语义标签。它适合放与主文相关但可独立存在的信息：术语解释、延伸阅读、标签云、作者简介、广告位。这些内容删掉，不影响主文理解。
立即学习“前端免费学习笔记（深入）”；
使用场景举例：
• 博客正文右侧放“本文关键词”和“相似文章推荐” → 用 <aside>；
• 文档页内某段落旁插入一个“注意：该 API 已废弃”提示框 → 也可用 <aside>；
• 但若这个 <aside> 里混着“首页”“关于”“联系”等导航链接 → 这部分必须抽出来，单独包 <nav>。
关键区别：
• <nav> 的核心是“跳转行为”；<aside> 的核心是“补充关系”；
• <aside> 可以出现在 <article> 内、<section> 旁，甚至 <main> 里面，不绑定物理位置；
• 不要用 <aside> 替代 <nav> 实现菜单，那是语义错配。
多模块侧边栏怎么嵌套才合理
真实项目中，侧边栏常同时存在导航链接 + 推荐文章 + 广告。这时候不能全扔进一个标签，得按语义分层。
推荐结构：
• 外层用 <aside> 表明“这是页面级附属区域”；
• 内部导航部分用 <nav aria-label="站点导航">；
• 推荐文章区块用 <section aria-labelledby="rec-title">（配 <h2 id="rec-title">）；
• 广告位可用 <section> 或直接 <div role="complementary">（因广告无强语义，<aside> 不适合重复嵌套）。
容易踩的坑：
• 把 <nav> 放在 <aside> 外面，导致它脱离侧边栏上下文，被当成全局主导航；
• 在 <nav> 里塞 <aside>，HTML5 规范不允许这种嵌套；
• 用 <section> 替代 <nav>，结果所有链接失去导航语义，键盘焦点无法批量跳转。
CSS 布局不改变语义，但影响可访问性实现
即使用了正确的 <nav> 和 <aside>，如果 CSS 把导航项设为 display: none 或用 visibility: hidden 隐藏，读屏器照样会跳过——因为 DOM 节点虽在，但被判定为“不可见且不可交互”。
折叠/展开侧边栏时务必注意：
• 用 transform: translateX(-100%) + inert 属性控制可访问性；
• 切换时同步更新 aria-expanded 和 aria-hidden；
• 移动端侧边栏若用 position: fixed，确保焦点顺序仍符合 DOM 流，避免键盘用户卡在不可见区域。
真正容易被忽略的一点：语义标签选对只是起点，后续 JS 控制状态、CSS 控制可见性、焦点管理三者必须协同。漏掉任一环，对屏幕阅读器用户来说，那个“完美语义”的侧边栏就等于不存在。
