语义化导航需同时满足结构正确与辅助技术可识别：必须用包裹有明确跳转意图的链接组，配合结构，添加aria-label区分多导航，用aria-current="page"标识当前页，并确保js更新时同步操作aria属性。

直接用 <nav></nav> 包裹导航链接，但不加 <ul></ul> 和 <li>，或者给 <nav></nav> 加了 aria-label 却没检查屏幕阅读器是否真能跳转——这两种做法都会让语义化失效。真正的语义化不是标签用了就算，而是辅助技术能按预期识别、跳转、播报。

nav 标签必须包裹成组的、有明确导航意图的链接

<nav></nav> 不是“所有带链接的 div”的替代品。它只适用于用户会主动用来在页面或站点间跳转的链接集合。

• 该用：<nav></nav> 包裹顶部主菜单、页脚站点地图、文章内的目录锚点列表
• 不该用：单个按钮（如“返回顶部”）、纯装饰性图标链接、广告跳转链接、仅用于 JS 事件触发而无 href 的 @#@#@#@#@#@#@#@#@#@0
• @#@#@#@#@#@#@#@#@#@1

错误写法：<nav>@#@#@#@#@#@#@#@#@#@2@#@#@#@#@#@#@#@#@#@1</nav> —— 这会让 NVDA 或 VoiceOver 把两个链接当成连续字符串播报

不要用 <div> 模拟列表：即使加了 <code>role="list" 和 role="listitem"，也比不上原生 <ul></ul>/<li> 的兼容性和稳定性

当前页面状态必须靠 class + aria-current 双重声明

仅靠 CSS 类（如 class="active"）无法被屏幕阅读器感知。用户无法知道“我现在在哪”，尤其当导航项文字相同（比如多个“详情”链接）时。

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

• 必须同时设置：@#@#@#@#@#@#@#@#@#@4
• aria-current="page" 是最常用值，表示当前 URL 对应的页面级导航项；aria-current="step" 用于多步流程
• 避免用 aria-current="true" —— 它不是合法值，部分读屏会忽略或报错
• JS 动态更新时，别只改 class，务必同步操作 aria-current 属性

响应式下拉菜单的 aria-expanded 和 role="menu" 容易误用

普通主导航不需要 role="menu"。这个 role 专用于模仿操作系统级菜单（如右键菜单），会强制读屏切换成“应用模式”，反而干扰浏览流。

• 常规下拉菜单：用 <button aria-expanded="false">产品</button> + <div role="region" aria-labelledby="trigger-id"> 就够了 <li>只有当你实现键盘导航（↑↓←→+Enter/Space）、支持焦点循环、且视觉样式完全匹配系统菜单时，才考虑 <code>role="menu" + role="menuitem"
• aria-expanded 必须与实际展开状态严格同步；JS 切换 class 后漏掉这个属性，会导致读屏播报矛盾信息
• 隐藏的下拉内容必须用 aria-hidden="true"，否则即使 CSS 设为 display: none，某些旧版读屏仍会尝试读取

最容易被忽略的是：语义化结构一旦写进 DOM，就得全程对齐辅助技术行为。比如你用了 <nav></nav>，就得确保它真能被“跳过导航”快捷键定位；用了 aria-current，就得保证它只出现在唯一一项上。这些不是上线前点一下 DevTools Accessibility 面板就能验证完的事，得在真实读屏环境中逐项测试。