无障碍配置

DFC Bridge 的最终实现以 WCAG 2.2 AA 级为目标。本配置把要求分配给设计、契约、实现和 QA。仅凭 Figma 文件不能声称符合标准：须对完整产品和全部适用的 WCAG 2.2 成功准则进行评估。

先看证据：Figma 原生属性描述设计，简短标签定位意图，结构化 bridge 元数据记录更详细的决策。再分别阅读源检查与实现路径。源报告只覆盖其范围内声明的规则，不代表运行时获准交付，也不证明符合 WCAG。 查看原图。

设计证据、结构化意图、语义实现和面向用户的测试缺一不可。任何单独一层都不能证明无障碍。

规范基线

• WCAG 版本：2.2。
• 目标级别：AA，包含全部适用的 A 级和 AA 级成功准则，不限于本页摘要。
• 范围：完整页面和流程、响应式与本地化变体、登录后状态、错误、浮层、嵌入内容及支持的平台。
• 产品所依赖的无障碍支持技术，由实现团队声明，并使用有代表性的浏览器与辅助技术测试。
• 即使 WCAG 允许某项例外，本配置中更严格的产品要求仍然适用。

使用 WAI-ARIA Authoring Practices确定预期的控件交互模式。优先使用平台原生语义和控件；ARIA 不能修复不合适的交互模型。

责任矩阵

阶段	必需证据
设计	阅读顺序、名称、标签、状态、焦点、对比度、重排、目标尺寸、替代方案、减少动态效果。
契约	稳定的语义角色和关系、反应中的焦点与播报、数据等价信息、例外和负责人。
实现	原生语义、键盘行为、无障碍 API 暴露的信息、用户偏好处理、响应式行为。
QA	自动检查，以及键盘、缩放重排、屏幕阅读器、对比度、动效、媒体和完整任务的人工测试。

把矩阵应用于完整任务，而不只检查单个控件。例如，打开对话框需要设计初始焦点、记录焦点返回规则、实现语义，并用键盘和屏幕阅读器测试。不要把无障碍当成留给开发者的模糊收尾工作，也不要把自动扫描当成符合性证明。

语义和阅读顺序

页面契约应明确：

• 描述性的页面标题、文档语言以及局部语言变化；
• 适用的页头、导航、主内容、补充内容、表单和页脚区域；
• 按区块含义而非字号划分的逻辑标题层级；
• 与含义相符的列表、表格、引用、标签、状态和关系；
• 图像的替代文本，或明确的装饰性分类；
• 不依赖视觉定位的合理 DOM 和无障碍阅读顺序。

使用现有 Figma 结构、组件来源、稳定名称、[decor] 和结构化无障碍元数据作为证据。不要为每个 HTML 元素新增平面标签。目标适配器选择原生元素，同时保留声明的语义。

无障碍名称、标签和描述

每个控件与字段都要有程序可识别的名称，名称须匹配或包含可见标签。纯图标控件需要明确且稳定的名称。附加描述连接说明、单位、约束、错误消息和后果，不能替代标签。

要求：

• 可见文本是无障碍名称的默认来源；
• 同一控件在不同断点和状态中保留相同名称，除非动作改变；
• 占位文字不是标签；
• 链接文字在上下文中说明目标；
• 重复的“了解更多”链接应有可区分的上下文；
• 状态徽标用文字表达状态，不只靠颜色；
• 出错前就说明必填项和接受格式；
• 错误说明字段、原因，以及已知的修正方式。

设计来源没有更合适属性时，可用简短的 [a11y-label=...] 为纯图标链接或控件命名。详细帮助、错误和关系放进结构化契约，不额外塞入图层名标签。

键盘和焦点

全部功能都应可用键盘或等价的顺序输入完成，且没有键盘陷阱。契约定义：

• 基于语义结构的逻辑 Tab 顺序；
• 标准交互模式要求时，控件内部的方向键行为；
• 每个主题和状态中的可见焦点样式；
• 对话框、抽屉、菜单、路由变化、验证、删除及动态更新时的初始和恢复焦点；
• 跳过重复区块的机制；
• 有 sticky 页头、Cookie 横幅、浮层或滚动容器时的焦点可见性；
• 拖动、路径手势、悬停和仅指针操作的替代方式。

不要用正值 tabindex 或视觉顺序代替正确的源顺序。AA 级的焦点不被遮挡（最低要求）要求，获得焦点的组件不能被作者创建的内容完全隐藏。DFC Bridge 还要求有意设计焦点指示，而不是依赖浏览器或主题碰巧具有足够对比度。

视觉要求

实现至少须满足：

• 普通文本对比度 4.5:1；符合 WCAG 大文本定义时为 3:1；
• 必要的界面组件和图形对象对比度 3:1；
• 不只用颜色传达信息；
• 文本放大至 200% 时仍可用；
• 等效宽度 320 CSS px 时可以重排，无需整页双向滚动，真正需要二维布局的内容除外；
• 用户应用 WCAG 文本间距覆盖值时不丢失内容或功能；
• 支持横屏与竖屏，除非某种方向必不可少；
• 可见说明不只依赖形状、颜色、声音、位置或感官描述。

检查实际呈现状态，不是令牌名称。accessible-blue 这个名字不能证明它在实际背景和透明度下具有足够对比度。

目标尺寸和指针输入

WCAG 2.2 AA 的目标尺寸（最低要求）要求指针目标至少 24 × 24 CSS px，或满足其间距条件或例外。DFC Bridge 建议主要触摸控件采用 44 × 44 CSS px 激活区域，并以 24 px 准则作为必须满足的 AA 底线。

还须定义：

• 相邻破坏性或高频操作目标之间的足够间距；
• 适用时，对按下事件触发的动作提供取消或撤销；
• 拖动操作的非拖动替代方式；
• 多点或路径手势的单指针替代方式；
• 窄屏和缩放时仍可见、可操作的标签。

不能只放大画出的图标，却保留很小的激活区域。

表单、错误和身份验证

表单遵循状态机契约，并提供：

• 标签、说明、字段用途及适用的自动填充元数据；
• 错误标识，以及已知的修正建议；
• 复杂表单的错误摘要，以及明确的焦点和播报行为；
• 法律、财务或修改数据的提交所需的检查、确认、撤销或修正机制；
• 验证或服务器失败后的值保留；
• 同一流程不重复要求已提供的信息，适用例外除外；
• 不单独依赖认知能力测试的认证方式，并支持密码管理器和粘贴。

禁用提交按钮不能成为说明表单未完成的唯一方式。

动态内容和异步状态

加载、结果、错误、后台保存、连接变化及其他重要更新需要可见反馈，适用时通过 polite 或 assertive 实时区域播报。声明：

• 播报什么、何时播报；
• 原有内容是否变为忙碌、过期或不可用；
• 如何合并重复更新以避免噪声；
• 焦点保持原处，还是因具体任务移动；
• 用户如何发现新增内容；
• 超时延长、重试和恢复控件。

不要仅为让屏幕阅读器读出状态而移动焦点。使用语义状态机制，并尽可能保留用户所在位置。

数据、图表和复杂视觉内容

应用数据与可视化契约。表格保留表头关系；图表和地图提供名称、摘要、不只靠颜色的编码、键盘可到达的交互，以及适当的表格、列表或下载途径来读取原始值。装饰图像不进入无障碍树。

复杂图像需要就近的简短替代文本，以及附近或链接到的详细说明，让用户获得相同的必要信息。官方模式参见 WAI 复杂图像教程。

动效、时间、闪烁和媒体

应用动效契约。尊重减少动态效果的偏好，在静态替代方案中保留任务；对符合条件的移动或自动更新内容提供控制；不得超过 WCAG 闪烁阈值。

对时间限制，声明警告、延长、内容保留和重新认证行为。对预录制或直播音视频，提供全部适用 A/AA 准则要求的字幕、音频描述、文字稿、媒体控制和替代信息。根据适用准则避免音频自动播放，或提供控制。

响应式变换

响应式变换必须保留：

• 无障碍名称、角色、值、状态和关系；
• 阅读与焦点顺序；
• 键盘和指针完成任务的能力；
• 错误、状态、来源说明和帮助；
• 到达折叠内容的路径；
• 切换呈现方式时的焦点和历史恢复。

表格变卡片、导航变菜单，并不允许删除标题、关系或动作。除了视口断点，也要测试由容器尺寸触发的变化。

方向、书写模式和双向内容

无障碍评审涵盖支持的 ltr/rtl 方向和书写模式，不只是翻译字符串。保留逻辑阅读和键盘顺序，不强迫它跟随视觉镜像。测试混合方向的姓名、电话、日期、标识符、代码和数字，以及图标镜像、图表轴和类别顺序、焦点指示、错误位置和播报。使用逻辑 start/end，并声明嵌入值的基本方向，让辅助技术获得可理解的序列。

结构化无障碍元数据

仅对设计来源和组件不能表达的意图添加结构化元数据：

非独立模块片段。 此例只展示 bridge.accessibility，省略了必需的外层字段。交换数据或验证完整契约前，将其放入交付契约规定的完整 bridge 结构。

{
  "bridge": {
    "accessibility": {
      "profile": { "standard": "WCAG", "version": "2.2", "level": "AA" },
      "elements": [{
        "element": "revenue-chart",
        "name": "Monthly revenue compared with target",
        "description": "Actual revenue exceeded target in 8 of 12 months",
        "details": "revenue-table",
        "readingOrder": ["chart-title", "chart-summary", "revenue-chart", "revenue-table"],
        "reducedMotion": "static-series",
        "testIds": ["a11y-chart-keyboard", "a11y-chart-values"]
      }]
    }
  }
}

元数据补充可见内容和实现语义，不能替代它们。

必需的 QA 矩阵

至少用以下条件测试有代表性的完整任务：

1. 仅键盘，正向和反向操作，包括浮层和失败路径；
2. 在团队声明的无障碍支持平台组合上使用屏幕阅读器和键盘；
3. 文本放大 200%，浏览器缩放 400%，并在窄等效宽度检查重排；
4. 文本间距覆盖和较长本地化文本；
5. 支持时使用强制颜色、高对比度或平台对比度模式；
6. 减少动态效果，以及首选动画机制被禁用或不受支持；
7. 指针与触摸目标尺寸、取消、手势替代方式和屏幕方向；
8. 自动检测可识别的问题，然后人工评审；
9. 加载、空、部分结果、过期、错误、离线、验证和权限状态；
10. 每项声明的响应式变换；
11. 支持的 RTL、双向文本和书写模式样例，包括图表和混合标识符。

记录浏览器、平台、辅助技术及版本、场景、预期结果、实际结果和证据。一个屏幕阅读器与浏览器组合通过测试，不代表所有组合都支持。

例外与符合性声明

例外记录必须指出具体 WCAG 准则或 DFC Bridge 要求、受影响范围、证据、用户影响、原因、负责人、缓解措施、批准信息及复查或到期日。没有证据和缓解计划，不能只写“技术限制”。

不能凭设计稿、单独组件、自动评分或不完整用户流程声明符合 WCAG。只有对已实现的完整范围内页面和流程评估全部适用准则，并准确披露已知问题后，发布版本才能作出符合性声明。