ARIA 组件模式

• aria-live 的作用与原理
• polite 与 assertive 的区别
• 动态内容更新的应用

aria-live 让屏幕阅读器等辅助技术实时播报动态更新的内容，而无需用户重新聚焦。aria-live="polite" 会等当前播报结束后再播报更新，不打断用户当前任务，适合非紧急的更新（如异步结果、加载完成）；aria-live="assertive" 会立即打断当前播报，适合紧急且必须让用户立即知道的内容（如错误提示、表单提交失败）。使用时通常配合 role="status"（polite）或 role="alert"（assertive）语义化，并让 live region 在有内容时再填充，避免页面加载时播报空内容。

Live Region 是 SPA 动态内容无障碍的关键——没有它，读屏用户不知道新内容出现。polite 与 assertive 的选择要谨慎：assertive 会打断用户，滥用会干扰阅读。工程上常把错误汇总放在 role="alert" 中，把加载结果放在 role="status" 中。

• 各角色的语义与适用场景
• 键盘交互模式
• ARIA Authoring Practices 的对应关系

这些角色定义了常见的复杂组件交互模式：combobox 是组合输入框（输入 + 下拉列表），含 listbox 作为选项容器；listbox 是单选/多选列表（配合 option 角色）；grid 是类似表格的可聚焦网格（按行/列导航）；menu 是纵向菜单（menuitem 及其子项），menubar 是横向菜单栏；tablist 是标签页容器（配合 tab、tabpanel）。每种模式都定义了键盘交互（如 listbox 用 Up/Down 移动选项、tablist 用 Left/Right 切换标签、grid 用方向键在单元格间移动）。ARIA Authoring Practices（APG）为这些模式提供了权威实现指导。

ARIA 角色不是孤立标签，而是有对应交互模式的"契约"。用对角色意味着必须实现 APG 规定的键盘行为与焦点管理，否则读屏语义与键盘操作会脱节。理解这些模式是构建复杂可访问组件的基础。

• aria-live 区域的使用场景
• 动态加载/更新的播报
• 与 SPA 的配合

aria-live 区域用于向读屏播报动态内容变化，典型场景：异步加载完成、搜索结果更新、购物车变化、聊天消息、表单错误汇总、进度提示。实现要点：在页面静态渲染一个 aria-live 容器（避免动态创建导致播报不稳定），把更新内容插入其中；用 role="status"/role="alert" 提供默认 polite/assertive 语义；对内容变化用 aria-busy 标记加载中。注意避免把整个列表都设为 live 导致频繁播报，通常只播报关键变化（如"已加载 5 条"）。

SPA 中几乎所有内容都是动态更新的，若不处理 live region，读屏用户会"失明"。工程上把 live region 做成独立容器、只播报摘要信息，是平衡"及时告知"与"不轰炸读屏"的实用策略。

• APG 的内容与定位
• APG 提供的模式与示例
• 在工程中的价值

APG（ARIA Authoring Practices Guide）是 W3C 提供的权威指南，给出各种复杂组件（accordion、dialog、combobox、menu、tabs、slider、tooltip 等）的完整可访问实现模式，包括：推荐的角色与属性、键盘交互规范、焦点管理、HTML 结构示例、常见错误。它帮助开发者"用正确的方式做 ARIA"，避免自行发明模式。APG 还区分了"必须实现"与"建议实现"的交互，并强调优先用原生元素。组件库（如设计系统）常以 APG 为规范基准。

APG 是"ARIA 的说明书"，把抽象规范落地为可复制的模式。开发可访问组件时对照 APG 的键盘交互与焦点管理表，能系统性地避免遗漏，也是面试中体现专业深度的重要知识点。

• Skip link 的作用
• 实现要点（href、tabindex、目标）
• 长页面中的导航优化

Skip link 是页面顶部或导航开头的"跳到主内容/各个区块"的链接，让键盘与读屏用户跳过冗长的页头、全局导航等重复内容，直达主内容。实现要点：链接指向目标 id（如 href="#main"），目标元素需 tabindex="-1" 以便编程聚焦；链接通常默认隐藏、聚焦时显示（:focus 时可见）；多个区块可提供多个 skip link（如跳到主内容、跳到导航、跳到搜索）。在长页面中，skip link 显著提升键盘导航效率，是 WCAG 2.4.1（跳过块）与 2.4.10（章节标题）的常见实现。

长页面中"重复导航"是最大的键盘效率杀手。Skip link 用一次跳转解决"每次都要 Tab 过整个导航"的问题。它简单却高效，是"可操作/可导航"原则的经典落地。

• 面包屑的 nav/aria-label 语义
• 对话框的 modal 模式与焦点管理
• Tooltip 的触发与读屏语义

面包屑：用 <nav aria-label="Breadcrumb"> 包裹，用 aria-current="page" 标记当前页，列表项用 ol/li 表达顺序。对话框：用 role="dialog" + aria-modal="true"（或原生 dialog），提供 aria-labelledby 指向标题，实现焦点陷阱、Esc 关闭、关闭后归还焦点。Tooltip：用 role="tooltip" 表示提示，通过 aria-describedby 关联到触发控件，但 APG 强调 tooltip 不应是唯一信息载体（因为即时消失、读屏静态支持有限），且不应获取焦点。三个模式都强调"正确的语义 + 键盘/焦点管理"。

这三个组件看似简单，但各有经典坑：面包屑漏 aria-current、对话框漏焦点陷阱、tooltip 用 aria-label 而非 aria-describedby 或把关键信息只放 tooltip。对照 APG 模式实现能避免这些常见问题。

• aria-modal 的含义
• aria-haspopup 的取值
• tablist/tab/tabpanel 结构

aria-modal="true" 告知辅助技术"只有对话框内内容可交互"，配合焦点陷阱强制背景不可聚焦；下拉菜单用 aria-haspopup（取值 true 或 menu/listbox/dialog 等）指示元素会弹出菜单，配合 aria-expanded 表达展开状态；标签页用 role="tablist" 容器 + role="tab"（可选中标签）+ role="tabpanel"（内容面板），tab 用 aria-selected 标记选中态，并用 aria-controls 关联到对应面板。三个都用"语义 + 状态 + 焦点管理"协作，让辅助技术理解复杂的交互结构。

这三个 ARIA 属性/角色是离散组件（弹层、菜单、标签页）的语义核心。理解它们"声明什么语义、如何配合焦点/状态"是写出可访问复杂组件的基础。重点是 aria-modal 需配合真实焦点陷阱，不能只加属性。

• grid 角色的数据表格语义
• tree 角色的层级导航
• menu 角色的命令列表

ARIA Grid 用 role="grid"（含 row、gridcell、columnheader）表达类似表格的可聚焦数据，支持方向键在单元格间移动，适合可交互大表格；Tree 用 role="tree"（含 treeitem、group）表达层级树形目录，支持 Up/Down/Left/Right 展开折叠与导航，适合文件树、目录；Menu 用 role="menu" + menuitem 表达命令列表，支持方向键与快捷键，适合动作菜单。工程价值：让复杂数据组件对读屏用户可结构化解析、可键鼠操作，且贴合 APG 模式。但要注意：若数据是纯展示，用原生 table 更合适；menu 不应代替普通导航。

Grid/Tree/Menu 是"用 ARIA 表达复杂信息结构"的典型。难点在于键盘导航与焦点管理的复杂度。选择哪个角色取决于"内容是否可交互、是否层级、是命令还是数据"，避免滥用。

• aria-expanded 的展开状态
• aria-hidden 的语义移除
• aria-controls 的关联

aria-expanded 表达"展开/折叠"状态（展开 true、收起 false），用于 accordion、下拉菜单、可展开面板的触发控件；aria-hidden="true" 从辅助技术语义树中移除不想要的内容（如加载中的占位、装饰性内容），但绝不能放在可聚焦元素上，否则会破坏焦点；aria-controls 声明触发控件控制的元素 id（如按钮控制的面板），帮助辅助技术建立关联。正确用法是三者协同：按钮 aria-expanded + aria-controls 指向面板，收起时 aria-hidden 隐藏面板。状态必须随用户操作实时更新，否则读屏播报与实际不符。

这三个属性是"展开控件"的语义核心。常见错误是 aria-controls 指向不存在的 id、aria-hidden 用在可聚焦元素上、状态未同步。系统化管理状态是组件可访问性的关键。

• roles/states/properties 的分工
• 自定义组件的语义化流程
• 结合原生语义

在自定义组件中，roles 定义"组件是什么"（如 button、tab、slider），states 表达"当前状态"（aria-expanded、aria-selected、aria-checked、aria-busy），properties 补充"信息与关联"（aria-label、aria-describedby、aria-controls、aria-valuenow）。工程应用流程：先判断能否用原生元素；若不能，则加 role、配 state、补 property，并实现对应的键盘/焦点行为。系统化做法是建立组件模板/规范，把"角色+状态+属性+行为"列成清单，配合 axe 校验。这样保证每个自定义组件语义完整、无遗漏。

roles/states/properties 是 ARIA 的"语法"，语义化工程是"把语法用对"。关键是把三者当作一个整体来设计，而非零散加属性，并始终以原生语义为优先。这能保证自定义组件与原生组件在可访问性上等价。

• role="tree" 与 role="grid" 组合
• tree 与 treegrid 的区别
• 树形数据导航

ARIA Tree 用 role="tree" + role="treeitem" + role="group" 表达树形层级，支持方向键导航与展开/折叠（aria-expanded）。ARIA Treegrid 是 role="grid" 与 tree 语义的结合（一个单元格 role="gridcell" 内含 treeitem），用于"树形行 + 多列数据"的表格状树（如文件管理器列出多列属性）。区别：tree 是单列层级，treegrid 是"多列表格 + 层级行"。工程应用：树形目录、文件管理器、组织架构、分类导航。实现难点是方向键导航、展开折叠时的焦点停留与 aria-expanded 同步。

Tree/Treegrid 用于"既有层级又有数据"的复杂组件。选择 tree 还是 treegrid 取决于数据是否多列。两者都依赖精细的键盘导航实现，是"ARIA 模式落地的深度"体现。

• combobox/listbox 的角色结构
• 自动补全的键盘交互
• 焦点与选中状态管理

自动补全组件用 role="combobox"（输入框）关联 role="listbox"（选项列表），listbox 内是 role="option"。combobox 用 aria-expanded 表达列表展开状态，用 aria-controls（或 aria-activedescendant）关联当前高亮选项。键盘交互：输入时过滤选项，Up/Down 移动高亮，Enter 选择，Esc 收起。工程价值：让读屏用户知道"输出了什么、可选项有哪些、当前选中哪个"，并让键盘用户能完整操作。标准做法是保持输入框聚焦，用 aria-activedescendant 指向高亮 option 的 id，代替真实移动焦点。

Combobox 是 APG 中最复杂的模式之一，难点在于"输入框保持焦点 + 用 aria-activedescendant 表达高亮"的机制。理解它对实现搜索框、标签选择器等自动补全组件至关重要。

• role="menu"/menuitem 结构
• 键盘交互
• 与导航/按钮的区分

role="menu" 容器 + role="menuitem" 项（或 menuitemcheckbox、menuitemradio）表达命令列表，常用于右键菜单、下拉动作菜单。键盘交互：Up/Down 移动高亮，Enter 执行，Esc 关闭。规范强调：menu 应只用于"命令/操作"，不应替代普通页面导航（导航用 nav + 链接）；菜单项用 aria-checked 表达勾选状态；菜单用 aria-haspopup 的触发控件 + aria-expanded 控制展开。现代实践还常用 contextmenu 事件实现右键菜单，并保证焦点管理、Esc 关闭、点击外部关闭。

常见误区是把 menu 用于链接导航。区分"命令菜单（menu）"与"导航（nav）"是现代实践的关键。App 风格的动作菜单可用 menu，但页面导航应保持原生链接语义。

• role="slider" 与 aria-valuenow/valuemin/valuemax
• 键盘操作（方向键）
• 焦点与播报

role="slider" 用于范围选择控件（音量、价格区间、亮度等）。关键属性：aria-valuenow（当前值）、aria-valuemin/aria-valuemax（范围）、aria-valuetext（值的可读文本，如"50%"/"音量 50%"）、aria-orientation（水平/垂直）。键盘操作：方向键/PageUp/PageDown/Home/End 调整值，焦点保持在滑块上。实现时用 div+role，配合 tabindex=0 可聚焦，并监听键盘事件更新值与 aria-valuenow。注意：原生 <input type="range"> 自带这些语义，若可行应优先用原生。

Slider 的难点是"改值不移动焦点"（焦点保持在滑块上，值通过 aria-valuenow 播报）。若功能允许，用原生 range input 最省心；自定义时需完整实现键盘与 aria 值属性。

• role="progressbar" 的语义
• aria-valuenow/valuemin/valuemax
• 不确定进度（indeterminate）

role="progressbar" 表达加载/任务进度。确定进度用 aria-valuenow + aria-valuemin + aria-valuemax（如 0-100）；不确定进度（无法预估时）省略 aria-valuenow，用 aria-busy 或 CSS 动画表示进行中。工程上：进度条更新时用 aria-live 或 role="status" 让读屏播报百分比变化，但避免过度播报（如每 1% 都播报，可只播报整数或关键节点）。对后台任务，用 aria-busy="true" 标记容器"正在处理"，完成后恢复。注意不要把进度条设为可聚焦（除非需要交互）。

Progressbar 的关键是"进度对读屏可见"与"不轰炸读屏"的平衡。确定/不确定进度的区分，以及用 live region 播报关键百分比，是工程要点。

• role="spinbutton" 的语义
• 与原生 input[type=number] 的对比
• 键盘操作

role="spinbutton" 用于可增减的数字输入控件。若用原生 <input type="number">，浏览器已提供数值语义与增减行为，无需 ARIA；自定义实现时用 role="spinbutton" + aria-valuenow/valuemin/valuemax，配合 Up/Down 键增减值，并处理焦点与值播报。现代实践：优先原生 number input；若自定义（如带步进按钮的组件），需把步进按钮用 aria-label 命名、用 aria-describedby 关联输入框，并保证键盘可操作。增减后的值更新需同步 aria-valuenow。

Spinbutton 是"原生已覆盖"的典型案例——原生 number input 已有语义，重点在于是否用对了原生控件。自定义时完整实现键盘与 aria 值属性是核心。

• aria-keyshortcuts 的作用
• 快捷键的命名与格式
• 工程价值

aria-keyshortcuts 声明元素上可用的键盘快捷键（如 aria-keyshortcuts="Control+K"），让辅助技术能告知用户"该元素有快捷键"。内容用空格分隔多个组合键，按键名用标准键名（如 Control、Alt、Shift、Meta、Enter、ArrowUp）。工程价值：让读屏用户知道快捷键存在、避免快捷键与读屏冲突（如 NVDA 的 Insert 键）、帮助实现"快捷键可发现与可覆盖"。注意：aria-keyshortcuts 只是"声明"，实际快捷键仍需脚本实现，且应保证所有快捷键功能也能通过非快捷键方式访问。

aria-keyshortcuts 提升"快捷键可发现性"，是健壮性的体现。同时强调"快捷键不能是唯一访问方式"，保证无障碍。这是键盘自描述实践的价值所在。

• aria-current 的取值
• aria-busy 的作用
• 路由/加载场景应用

aria-current 标记当前项（如当前页面 aria-current="page"、当前步骤 aria-current="step"、当前时间 aria-current="time"），帮助读屏在导航/步骤中告知用户所在位置（如面包屑、分页、步骤条）。aria-busy="true" 标记容器"正在加载/更新中"，告知辅助技术"暂时不要解析该区域，等更新完成"，常用在路由切换、异步数据加载时。工程价值：路由切换后 aria-current 更新当前导航项、aria-busy 屏蔽加载中的中间态，避免读屏播报"半成品"内容；配合 focus 管理（切换后聚焦新标题）形成完整的路由可访问性。

SPA 路由切换是动态内容的典型场景。aria-current 保持"位置感"，aria-busy 避免"中间态误播报"，二者结合提升 SPA 的读屏可理解性。

• role="switch" 的语义
• 与 checkbox 的区别
• 状态与键盘

role="switch" 表示开关（on/off），语义上类似 toggle。它与 checkbox 的区别：switch 表达"立即生效的开关状态"，而 checkbox 表达"待确认/提交的选项"。状态用 aria-checked（true/false）表达，配合 aria-label 命名。键盘操作：Space 切换开关状态。工程上优先用原生 <input type="checkbox" role="switch">（覆盖原生可聚焦与键盘行为，仅覆写角色），或自定义时用 div+role 并实现 Space/Tab 与状态更新。状态变化应同步 aria-checked 并即时播报。

switch 是"预先定义好的 checkbox 角色覆写"，用原生 checkbox + role="switch" 是最优解。理解其与 checkbox 的语义差异（立即生效 vs 提交确认）是正确使用的关键。

• role="tooltip" 的语义
• aria-describedby 关联
• tooltip 的局限

role="tooltip" 用于鼠标悬停/聚焦时显示的提示信息，实现上用 aria-describedby 把触发控件与 tooltip 关联，让读屏能播报提示。工程边界：APG 明确 tooltip 不应获取焦点（避免打断用户）、不应作为关键信息的唯一载体（因为悬停即失、触屏不可用、读屏支持不一）；关键信息应放在可见文本或 aria-label 中，tooltip 仅作补充说明。自定义 tooltip 需处理：触发控件用 aria-describedby、显示/隐藏逻辑、键盘/触屏可访问性（触屏用户无法悬停，需提供替代访问）。

Tooltip 的边界在于"不能是唯一信息源"。它适合补充说明，但关键信息必须通过其他方式可达。理解这个边界能避免"只有 tooltip 能看到的提示"这种无障碍缺陷。

• 轮播的 ARIA 结构
• 自动播放与暂停
• 焦点与导航

轮播（carousel）的 ARIA 实践：用 role="region" 或 aria-roledescription="carousel" 标记轮播区域，aria-label 命名；每个滑动项用 role="group" + aria-roledescription="slide" + aria-label="1 of 5"；提供上一张/下一张按钮（aria-label 命名），用 aria-live="polite" 或 "off" 控制播报（自动播放轮播通常用 aria-live="off" 避免频繁播报，改用手动时通知）；提供 aria-controls 关联。自动播放应提供暂停按钮并尊重 prefers-reduced-motion，支持键盘导航（方向键切换）。焦点管理：轮播不应自动抓取焦点。

轮播是常见的无障碍重灾区（自动播放、信息突然消失）。工程实践强调：自动播放可暂停、支持键盘、适度播报、尊重 reduced-motion。这是"时间媒体 + 运动降级"的综合应用。

• 原生 table 的语义
• 何时需要 ARIA table/grid
• 取舍原则

纯展示数据应优先用原生 <table>（自带 table/row/columnheader/cell 语义、表头关联、阅读顺序），加 <caption> 提供标题、用 <th scope> 表头关联，无需 ARIA。ARIA table（role="table"）用于"无法用原生 table、但需要表格语义"的场景（如某些布局受限或自定义结构），但 ARIA 不提供原生 table 的免费行为（如阅读顺序、表头语义），需手动补齐。ARIA grid 则用于可交互/可聚焦的表格。取舍原则：静态数据用原生 table；可交互用 grid；只有原生表达不了才用 ARIA table。

"原生优先"在本例最明显——原生 table 自带完整表格语义，ARIA 只是不得已的替代。理解何时用 table、grid、ARIA table 三种方案，是数据展示无障碍的工程决策。