屏幕阅读器依赖语义标签而非css，必须用原生、、等标签确保可访问性；滥用或误用会破坏导航、正文定位和交互逻辑。

屏幕阅读器不“读页面”，它解析语义角色、名称和状态；没用 <nav></nav>、<main></main>、<button></button> 这类原生标签，等于主动放弃对视障用户的可访问性支持。

为什么 <nav></nav> 不能替换成 <div class="nav"> <p>屏幕阅读器根本不看 CSS 类名，<code><div class="nav"> 的 computed role 是 <code>generic，它就当那是普通容器，连“导航”两个字都不会提。用户听不到结构，也无法按 N 键跳入。

• <nav></nav> 自带 role="navigation"，被 NVDA/VoiceOver/JAWS 固化为地标（landmark），无需额外声明
• 多个 <nav></nav> 必须加 aria-label 区分，否则全叫“导航”，用户分不清主导航、页脚导航还是面包屑
• <nav></nav> 只适用于主要导航路径（如顶部菜单、分页），轮播图控制按钮组、友情链接列表不是导航，别硬套
• <nav></nav> 必须直接包裹可聚焦元素（如 <a></a>、带 tabindex 的 <button></button>），不能只放纯文本
• 嵌套在 <header></header> 里 ≠ 自动语义化：<header><div class="nav">...</div></header> 仍是零语义

<main></main> 缺失或重复时，正文定位直接失效

几乎所有主流屏幕阅读器把 <main></main> 当作“页面主体内容”的唯一可信锚点。没它，系统退而求其次找 role="main"，再找不到就从第一个 <h1></h1> 开始算正文——但页眉里也可能有 <h1></h1>，结果用户下拉 7–12 次才摸到真正内容。

Html2md

使用 Readability + Turndown 将 HTML 页面转换为干净的、Agent 友好的 Markdown。去除导航栏、广告、页脚、Cookie 横幅、社交按钮等干扰元素。支持 URL...

下载

• <main></main> 全局只能出现一次，且不能嵌套在 <header></header>、<footer></footer>、<nav></nav> 或 <aside></aside> 内部
• React/Vue 项目中常见错误：根容器用 <div id="app"> 包全局，子组件各自渲染 <code><main></main> → 必须由布局组件统一提供，子组件改用 <section></section>
• <main></main> 内可嵌套 <header></header> 和 <footer></footer>，但不要用 <section></section> 替代 <main></main> —— 会丢失“这是本页最核心信息”的语义声明
• CMS 富文本输出常把小标题渲染成 <p class="title-h3"></p>，必须拦截并替换为真 <h3></h3>，否则大纲断裂

<button></button> 和 role="button" 的键盘交互能力根本不在一个量级

二者在读屏器里可能都读成“按钮”，但行为天差地别：<button></button> 自动支持空格/回车触发、disabled 状态禁用朗读与交互、默认焦点样式；<div role="button"> 必须手动补全全部逻辑，漏一项，键盘用户就卡住。 <ul> <li> <code><button></button> 的 type 属性必须显式声明：type="submit"（表单内）、type="button"（纯 JS 行为）、type="reset"（慎用）

• 仅含图标的按钮（如 ×、?️）必须配 aria-label，title 属性无效，不触发朗读
• <button type="button"></button> 是最安全的兜底选择，尤其在组件库中封装按钮时，应默认设为该值，避免父级表单污染
• 禁用按钮时，仅设 style="opacity: 0.5" 不够，必须加 disabled 属性，否则辅助技术仍认为可操作
• 用 <div> 模拟按钮是高频雷区：测试只点鼠标，上线后视障用户完全无法提交 <p>最容易被忽略的不是“怎么加标签”，而是“什么时候不该加”——比如把广告位、轮播图容器、页脚链接列表硬套 <code><nav></nav> 或 <section></section>，反而破坏可访问性树；语义化不是堆砌标签，是让每个标签都承担它该承担的结构责任。