nav标签是语义与可访问性必需，须用nav包裹并嵌套ul/li结构，配aria-label；横向布局用flex替代float；链接需支持键盘焦点；折叠菜单须正确管理aria属性与DOM可见性。

nav 标签不是“加个样式更高级”的可选项，而是语义和可访问性的硬性起点。不用它，屏幕阅读器可能跳过整个导航区；用了但结构错乱，反而让辅助技术更难理解。

必须用 nav 包裹，且内部首选 ul/li

W3C 明确建议：主导航应使用 nav + 无序列表结构。这不是为了好看，而是告诉浏览器“这是一组有逻辑关系的导航链接”。ul 表达并列关系，li 是每个导航项的语义容器——比用一堆 div 或 span 更准确。

• 错误写法：<nav><a href="/">首页</a><a href="/about">关于</a></nav>（缺少列表语义）
• 推荐写法：<nav aria-label="主导航"><ul> <li><a href="/">首页</a></li> <li><a href="/posts">文章</a></li> </ul></nav>
• aria-label 不是可选修饰，它让屏幕阅读器能朗读出“主导航”，否则只读“列表，2项”，用户根本不知道这是干啥的

横向排列别再死磕 float，用 display: flex

老教程里靠 float: left + clear: both 排导航，现在不仅冗余，还容易触发 BFC 问题、高度塌陷、响应式断点错乱。Flexbox 是更干净的解法。

• nav ul 设 display: flex，nav li 默认自动横向排列，无需浮动
• 用 gap 控制间距，比给每个 li 加 margin-right 再单独处理最后一个更可靠
• 移动端折叠时，直接 flex-direction: column 切换布局，不需要重写结构
• 注意：IE11 支持 flex，但不支持 gap，如需兼容，改用 margin + :last-child 降级

链接样式要兼顾视觉与键盘焦点

很多人只测试鼠标点击，却忽略键盘用户按 Tab 键时的体验。一个没设 :focus-visible 的导航链接，在聚焦时可能只剩浏览器默认虚线框，极难辨认。

DeepBI DHTML 页面生成器

生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

下载

• a 必须设 display: block 或 inline-block，否则宽高、内边距无效
• 悬停（:hover）和聚焦（:focus-visible）样式最好一致，比如同样加背景色或下划线
• 避免仅用颜色区分状态，色觉障碍用户可能无法识别；加图标、粗细或位置变化更稳妥
• 别用 outline: none 全局清除焦点框——除非你提供了同等明显的替代样式

响应式折叠菜单的 DOM 结构不能偷懒

移动端收起导航，不是单纯靠 CSS display: none 隐藏 ul 就完事。如果 JS 没正确切换 aria-expanded 和 hidden 属性，屏幕阅读器会完全“看不见”被隐藏的菜单项。

立即学习“前端免费学习笔记（深入）”；

• 按钮需带 aria-controls="menu-id"，ul 需对应 id="menu-id"
• 展开时设 aria-expanded="true"，同时移除 hidden；收起则反之
• 不要把整个 nav 用 display: none 隐藏——这会让辅助技术彻底跳过该区域
• 动画过渡建议用 max-height + overflow: hidden，而非依赖 height（因为高度不可预知）

真正难的不是让导航横过来，而是确保它在任何设备、任何输入方式、任何辅助技术下，都保持“可发现、可理解、可操作”。结构松散、属性缺失、焦点管理随意——这些细节不会报错，但会在真实用户那里悄悄流失信任。