直接使用 button 标签更省心可靠，因其原生支持键盘聚焦、enter/space 触发、disabled 同步及默认焦点样式；而 div + role="button" 易遗漏 tabindex、keydown 监听、aria 状态等，导致键盘用户无法操作或辅助技术误读。

为什么比

更省心也更可靠

直接用 button 标签，就自动获得键盘聚焦、Enter/Space 触发、disabled 同步、焦点样式默认可见——这些不是“可选功能”，而是浏览器原生保障。而 div 加 role="button" 后，漏掉任意一项都会让键盘用户卡死。

• 漏 tabindex="0" → Tab 键跳过该元素，根本进不去
• 没监听 keydown 里的 "Enter" 和 " "（空格）→ 按键无响应，只靠鼠标才能点
• 禁用时只改 CSS 灰度 + pointer-events: none → 屏幕阅读器仍报“可点击”，且表单提交时可能被包含
• 开关类按钮没同步 aria-pressed 或 aria-expanded → 状态对辅助技术完全不可见

label 和 input 怎么才算真正关联上了

屏幕阅读器不认 CSS 对齐，只认 DOM 关系。写 label 但没连上 input，等于没写。

HTML Extract

使用 MinerU 从 HTML 页面和文件中提取内容，将 HTML 转换为保持标题、列表、表格及文本层次结构的干净、结构化 Markdown。F...

下载

• 显式关联最稳：<label for="email">电子邮箱</label><input type="email" id="email">，注意 for 和 id 必须**完全一致**（包括大小写、连字符）
• 嵌套写法（<label>用户名<input></label>）虽合法，但在旧版 TalkBack 中可能截断播报，慎用
• 检查方法：打开 Chrome DevTools → 切换到 “Accessibility” 面板 → 点击 input → 看 “Accessible Name” 字段是否显示 label 文本
• 多个同名 id 会导致关联错乱，务必全局唯一

nav、main、header 这些结构标签光写对还不够

只写 <nav></nav> 是无效的。当页面有多个 nav（比如顶部导航、面包屑、页脚快捷入口），读屏器无法区分用途，会统一报“导航区域”然后跳过。

• <nav aria-label="主导航"></nav> 和 <nav aria-label="面包屑导航"></nav> 是必须项，值要具体，不能是 "Navigation" 或空着
• aria-current="page" 必须加在当前页的 a 元素上，且值只能是 "page"，不是 "true" 或 "active"
• <main></main> 在整页中只能出现一次；若嵌套在 <table> 或其他非流式容器里，语义会被破坏，AT 可能忽略它 <li> <code><header></header> 和 <footer></footer> 应作用于其直属上下文（如 <article></article> 内的 <header></header> 表示文章头，而非全站头）

自定义组件怎么透传语义而不是覆盖它

用 Web Components 或框架封装时，常见错误是把内部结构全塞进 div，再靠一堆 aria- 补救——这等于放弃语义根基，又想拿无障碍结果。

• 如果组件本质是按钮（如 <icon-button></icon-button>），根节点必须是 button，不能是 div 包裹后加 role="button"
• 用 <slot name="header"></slot>，别用 <slot name="top"></slot> —— slot 名称本身要有语义，方便外部传入正确语义内容
• 树形控件折叠时，仅靠 display: none 不行：子节点 DOM 仍在，NVDA 会照读；必须配对操作 aria-expanded="false" 和子容器的 aria-hidden="true"
• 动态加载内容（如搜索建议列表）要加 aria-live="polite" 且 aria-atomic="true"，否则读屏器可能只读增量部分，漏掉上下文
实际项目里最容易被忽略的，是那些“看起来没问题”的地方：比如 lang 属性留空导致语音引擎切错、title 和 h1 写死在模板里没随路由更新、nav 的 aria-label 被当成可选配置漏填。这些不是边缘 case，而是上线后第一批被读屏用户发现并投诉的问题。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！