ARIA Authoring Practices Guide

ARIA 规范定义了角色、状态与属性的词汇体系。ARIA Authoring Practices Guide 则说明如何实际运用这些词汇：每种模式需要哪些键盘交互、焦点如何在组件内移动、状态变化时应播报什么内容，以及 DOM 应呈现怎样的结构。

APG 包含哪些内容

APG 收录了 ARIA 规范所支持的每种组件模式的标准实现：

• 组合框（含自动补全模式，键盘行为复杂，几乎所有团队都会实现错误）。
• 对话框——模态与非模态，含完整的焦点捕获及关闭后返回焦点的行为。
• 展开/收起组件（简单的显示/隐藏模式）。
• 菜单与菜单栏——需要方向键导航，而非仅依靠 Tab 键。
• 选项卡——Tab/tabpanel 组合，含键盘方向键导航及自动/手动激活语义。
• 树形视图——文件树式的层级导航。
• 列表框——单选与多选。
• 微调按钮、滑块、轮播图以及十余种其他模式。

每个模式页面由三部分组成：可运行的在线示例、键盘交互表格，以及所使用的精确 ARIA 属性。此外还有地标模式——关于 <header>、<nav>、<main> 及其映射 ARIA 角色的指导——以及专门说明反模式的章节，阐述哪些做法不应采用。

何时参考 APG

当需要构建一个没有对应原生 HTML 元素的组件时，APG 最为实用。在编写任何代码之前，应先检查 APG 中是否已有该模式。通常情况下：

• 需要实现的键盘交互已有规范。
• DOM 结构已有文档记录。
• ARIA 属性已完整定义。

忽略这一步是许多团队交付”无障碍”组件却让屏幕阅读器产生混乱的根源——而这类问题往往无法被任何自动化工具检测到。APG 是决定一个组合框究竟是对所有用户都可用还是编译通过但对屏幕阅读器用户无效的关键所在。

APG 明确不是什么

APG 不是规范性文档。规范性文档是 ARIA 规范本身以及 WCAG。APG 提供的是指导：完全按照 APG 的方式实现组件是推荐路径，但并非唯一合规路径。即便如此，在没有充分文档化理由的情况下偏离 APG，往往意味着对该模式的理解还不够深入。

APG 同样不能取代原生 HTML。如果 <select> 能满足下拉菜单的需求，就应直接使用 <select>——不要仅仅因为 APG 的组合框模式听起来更高级就贸然采用。