1. 引言
目前已经有许多测试流程和工具，帮助用户测试网页内容是否符合诸如 网页内容辅助功能指南 [WCAG22] 等辅助功能标准。随着互联网规模和复杂度的日益提升，这些流程与工具对于管理网上资源的辅助功能至关重要。
ACT 规则格式提供了指导意见，旨在确保如何测试 WCAG 以及其他辅助功能要求文档的一致解释，并推动辅助功能测试结果的一致性。ACT 规则格式用于描述手动测试和由辅助功能测试工具执行的自动测试。
记录如何测试辅助功能要求，有助于实现测试过程的透明化并获得可复现的测试结果。ACT 规则格式定义了这些测试描述的要求，这些描述称为辅助功能一致性测试规则（ACT 规则）。
ACT 规则是用通俗语言描述如何针对辅助功能要求的某一具体方面测试某种类型内容的方法。ACT 规则说明它适用于何种内容，以及哪些条件适用于被测元素从而满足该规则的所有期望。在 WCAG 语境下，ACT 规则用于测试未满足成功标准的情形，这些失败通常在 常见错误 中予以说明。ACT 规则专为测试流程编写，通常比常见错误更为具体。
ACT 规则格式定义了每个规则必须包含的信息类型和结构。ACT 规则的具体结构定义见 ACT 规则结构 部分。每条 ACT 规则还需包含通俗描述，被测内容类型、执行的测试及预期结果。若测试结果影响一致性，则该规则需记录所测试的具体要求。测试产生的结果可以用于判断是否符合相关要求。此外，ACT 规则还会配有示例，确保规则的实现可正确判定预期结果。
2. 适用范围
本规范所定义的 ACT 规则格式，设计用于测试使用 Web 技术创建的内容，例如 超文本标记语言 [HTML]、层叠样式表 [css-2018]、辅助功能富互联网应用 [WAI-ARIA]、可缩放矢量图形 [SVG2]、EPUB 3 [epub-33] 等。ACT 规则格式本身技术无关，也可用于描述其它技术的测试规则。
ACT 规则格式可用于描述专门测试 辅助功能要求的 ACT 规则，例如《网页内容辅助功能指南》 [WCAG22] 中界定的这些要求专为网页内容设计。其他适用于 Web 技术的辅助功能要求同样可用 ACT 规则进行测试。例如，可开发 ACT 规则测试基于 Web 的用户代理是否符合 用户代理辅助功能指南 [UAAG20]。但 ACT 规则格式或许并不总适用于描述其它类型辅助功能要求的测试。
2.1. 向后兼容性
ACT 规则格式 1.1 与 1.0 在很大程度上是向后兼容的，但并非完全兼容。ACT 规则格式 1.1 引入了 1.0 未包含的新要求，也允许少数 1.0 不允许的情况，如主观性的 适用性。详情见 变更历史。
3. ACT 规则类型
在辅助功能领域中，常有不同技术方案可用于让同类内容变得可访问。例如，HTML 中有多种方式赋予 img 元素可访问名称。若在一条规则中测试多方案，则规则往往过于复杂，难以理解和维护。ACT
规则格式通过设定规则类型来解决这一问题：
-
原子规则：描述如何测试某一具体解决方案。它对需测试的元素、节点或其他 测试对象的“部分”有明确界定，并规定何时通过或不通过该规则。原子规则应保持简明与“原子性”，即只测试单一“条件”，且不依赖其它规则的 结果。
-
复合规则：描述如何将多个 原子规则的结果组合为每个 测试目标的最终结果。一个复合规则可以有多个“条件”，分别由不同的原子规则测试；其逻辑说明不同条件的组合如何得出单一结果。
复合规则不能包含其它复合规则。若需嵌套复合规则，应直接将相关的原子规则组合进新的复合规则。
并非所有原子规则都需隶属于复合规则。当需要综合多个原子规则的测试结果以判断某个测试对象是否未满足某项辅助功能要求时，才用复合规则。
原子规则和复合规则的分离形成职责划分。原子规则用于测试某种解决方案的实现是否正确，复合规则用以判定其他原子规则的多个结果是否部分或全部满足辅助功能要求。
4. ACT 规则结构
一条 ACT 规则必须至少包含以下项目：
-
描述性标题
-
规则输入，可为下列之一：
一条 ACT 规则还可包含：
ACT 规则格式并未规定 ACT 规则必须采用何种文件格式（如 HTML、DOCX、PDF 等）。但 ACT 规则必须编写在符合《网页内容辅助功能指南》 [WCAG22] 或同等标准的文档中。这样可确保 ACT 规则对残障人士也是可访问的。ACT 规则示例允许包含不可访问内容。如果任何示例存在WCAG 2.2 第 5.2.5 节 非干扰性中列出的辅助功能问题，用户必须提前获得警告。ACT 规则应采用可本地化格式，从而规则可包含多种语言版本或可被翻译。
4.1. 规则标识符
一条 ACT 规则必须拥有在其规则集内唯一的标识符。该标识符可以是任意文本、URL 或数据库编号等。
除标识符外，每个 ACT 规则的新版本必须以日期或编号进行版本管理。需能查阅该规则前一版本的引用。规则更新时不得更改标识符。若为重大变更，则应创建带新标识符的新规则，并对旧规则进行弃用。
4.2. 规则描述
一条 ACT 规则必须有通俗易懂的规则描述，简要说明该规则的作用。
无论规则以何种数据格式撰写，描述内容都应包含指明语言和基础段落方向的元数据。多数标记语言或文档格式都具备相关标识方式。更多详情见 [string-meta]。
4.3. 规则类型
一条 ACT 规则必须指定规则类型，必须为下列之一：
- 原子规则
- 复合规则
详细定义参见 规则类型 部分。
4.4. 辅助功能需求映射
当某条 ACT 规则用于测试一项或多项辅助功能要求文档的符合性时，规则必须枚举所有当该规则的一项或多项结果为未通过时未被满足的辅助功能要求。规则可以列出因规则结果为未通过而可能不被满足的要求。辅助功能要求分为两类：
映射中的每条辅助功能要求 必须包含：
4.4.1. 结果映射
针对映射中的每条一致性要求，ACT 规则必须说明规则的结果对该测试对象满足辅助功能要求的影响。4.4.1.1. 一致性要求
当规则用于测试某一具体辅助功能要求时，仅在以下两个条件均满足时，该要求被映射为一致性要求：
-
未通过结果：当某一测试对象的一个或多个结果为
未通过时，该辅助功能要求对该测试对象被视为未满足，且 -
通过或不适用结果：当所有结果均为
通过或不适用时，该辅助功能要求对测试对象可视为已满足或需进一步测试。
能够判定辅助功能要求已满足的规则被称为满足性测试。
-
通过：当所有结果均为
通过时，该辅助功能要求对测试对象已满足。
注意： 在 网页内容辅助功能指南 [WCAG22]
中，成功标准的评估不会直接体现为通过、未通过或不适用。而是体现为已满足（或未满足）。详见 WCAG 2.2
定义：满足成功标准。若某一成功标准未被满足，仅在网页有合规的备选版本时才符合规范，相关描述见 WCAG 2.2 一致性要求 1。
4.4.1.2. 次要要求
次要辅助功能要求是与规则相关但规则本身并未设计用于测试的要求。规则的结果会影响辅助功能要求的判断，但该规则并不针对要求的符合性进行测试。这种相关性通常导致规则的部分示例不满足次要辅助功能要求。
当规则并非设计用于测试某辅助功能要求，或者规则的未通过结果仍需进一步测试该要求时，规则可以将该辅助功能要求映射为次要要求。映射为次要要求的 ACT 规则必须说明该要求为何为次要要求。
当规则是为测试某项辅助功能要求而设计时，辅助功能支持方面的差异不能成为将其视为次要辅助功能要求的理由。
部分情景下规则会有次要要求：
情景 1：规则较某要求宽松
规则只测试了辅助功能最低要求，而存在更严格的要求。规则的未通过结果能确定更严格的辅助功能要求未被满足，但通过结果未必能判定更严格要求已满足。即使规则结果为通过，辅助功能要求也可能未被满足，更严格的要求视为次要要求。
情景 2：规则比某要求更严格
规则设计用于测试某辅助功能要求的特定方案，但该要求也可通过规则未涵盖的其他方案来满足，此时规则的未通过结果不能判定辅助功能要求未被满足，因为还需进行进一步测试；而通过结果则能确定要求已满足。该辅助功能要求为次要要求。
规则设计用于测试一项辅助功能要求，且存在较宽松的要求。此时规则的通过结果能判定较宽松要求已满足，而未通过结果未必能判定该要求未被满足。即使规则结果为未通过，辅助功能要求也可能被满足。较宽松的辅助功能要求为次要要求。
情景 3：规则可能影响辅助功能要求判定，但未用于测试该要求的符合性
规则用于测试某辅助功能要求，在某些情况下，其他辅助功能要求也会适用。此时，这些其他辅助功能要求有时满足，有时不满足，因为它们在本规则中并非总是适用，故为次要要求。
4.4.2. WCAG 之外的映射
ACT 规则可用于测试非 W3C 辅助功能标准中的辅助功能要求，比如 超文本标记语言 [HTML] 中的辅助功能要求，或如 RGAA 3 2016 方法学中的测试。ACT 规则必须指明所映射的辅助功能要求在其对应的辅助功能要求文档是否为符合性必需。例如，WCAG 充分技术，或包含要求和可选“最佳实践”的企业规范。必须清晰区分何为必需、何为可选。
4.4.3. 无辅助功能要求的规则
如果规则未与任何辅助功能要求映射，辅助功能要求映射仅包含说明其不要求符合对应的辅助功能要求文档。这常见于复合规则中的原子规则。
若未通过 结果无法与任何辅助功能要求映射，则辅助功能要求映射中不能有辅助功能要求。可选的背景部分可用于列出相关辅助功能要求文档，但规则并非针对这些文档的失败测试。
4.4.4. 外部辅助功能要求映射
本节非规范性。
虽然规则通常为一个或少量辅助功能要求文档而设计，但其它要求文档也可能映射到这些 ACT 规则。例如，一些规则为网页内容辅助功能指南 [WCAG22]编写，但也可能映射到公司的内部辅助功能政策。针对这种情况，可以创建外部辅助功能要求映射。外部映射是在 ACT 规则的辅助功能要求映射基础上新增其它要求文档的映射，从而避免仅为改变映射而重复编写规则。
4.5. 规则输入
要使用 ACT 规则评估内容，规则需要来自测试对象的某些信息，这些就是规则的输入。需要哪些输入已明示，以帮助测试人员理解使用规则的能力需求。原子规则与复合规则的输入不同。
4.5.1. 输入方面（仅原子规则）
输入方面是一种测试对象的独立部分。将内容渲染给终端用户通常涉及多个技术，原子规则可能需要所有或部分技术相关的输入。例如，有的规则需直接操作服务器和客户端间交换的超文本传输协议 [http11]消息，有的规则需操作浏览器暴露的文档对象模型 [DOM]树。
原子规则必须明确列出用于规则适用性和 期望判定的输入方面。规则可同时操作多个方面，如 HTTP 消息与 DOM 树。
部分输入方面在规范中有明确定义，如 HTTP 消息、DOM 树及 CSS 样式 [css-2018]等。对于这些方面，可引用通用输入方面说明的相关章节作为描述。若输入方面并无清晰定义，则 ACT 规则必须详细说明或引用权威描述。
输入方面的服务方式无关紧要。例如 DOM 树可通过 HTTP 以 HTML 形式提供，也可打包为 EPUB 出版物的多页，或者通过JSX 源文件推断。所有仅以 DOM 树为输入方面的规则均适用于这些技术。
4.5.2. 输入规则（仅复合规则）
复合规则使用 原子规则的结果，并对此进行逻辑处理，从而为每个 测试目标得出单一结果。复合规则必须列出所有用于 期望 的原子规则的 标识符 及 描述性标题。输入规则即对复合规则的输入加以说明，方式类似于为原子规则的输入方面加以说明。
4.6. 适用性
适用性描述了将在测试对象中测试哪些部分。
4.6.1. 原子规则的适用性
适用性为原子规则的必需部分。必须精确描述规则适用的测试对象部分。例如，DOM [DOM] 树中的特定节点，或 HTML [HTML] 文档中闭合不正确的标签。这些被称为测试目标。适用性描述必须只用规则的 输入方面所提供的信息，不能使用其他信息。
适用性必须明确无歧义，即只能有一种理解方式。例如，标题与图片等概念并不明确，因其可指标签名、语义角色或网页上的功能用途，而明确规定仅适用于“heading标签”的规则则满足无歧义要求。
此外，适用性应当用客观、通俗的语言描述。客观的描述是在特定技术环境下可确定、无不确定性的，比如 HTML 中标签名、计算出的角色以及元素之间距离都属于客观属性。
主观属性包括装饰性、导航机制和预录制等概念，往往依赖人工判断、定义多样。建议尽量避免主观性描述，以减少误解；如确实无法客观定义，可接受主观性，但若可能，应将客观部分和主观部分拆分成单独规则设计，以确保原子规则只测试一个条件。例如，测试标题标签语义正确性和语义错误的分别用不同规则。
定义可以放在规则术语表中，或在使用处定义。
4.6.1.1. 适用性类型标识（可选）
规则可选地包含一个适用性类型标识，用以标明规则包含的是客观还是主观适用性。此标识将帮助规则阅读者和实施者清楚了解规则作者对适用性的意图，从而减少因理解差异带来的困惑。
4.6.2. 复合规则适用性
复合规则的适用性由输入规则中所有适用性定义的并集构成。规则作者可以省略复合规则的适用性描述。如果难以用通俗语言表达合并后的适用性可以不写。如果复合规则包含适用性描述，则必须是输入规则所有适用性的并集。
注意，复合规则中的输入规则可以具有不同的适用性。因此，并不是每个适用于复合规则的测试目标都会被每个输入规则测试。
4.6.2.1. 适用性类型标识（可选）
复合规则可选地包含一个适用性类型标识，指出规则采用的是客观还是主观适用性。复合规则的适用性类型根据其输入规则来判定：若任何输入规则为主观，则整体为主观，否则为客观。
4.7. 期望
ACT 规则必须包含一个或多个期望。期望描述了由适用性所派生的测试目标需满足的要求。期望即针对每个测试目标的断言。当测试目标满足所有期望时，则通过本规则；若不满足所有期望，则未通过规则；如果没有测试目标，则本规则结果为不适用。
每项期望必须独立、无歧义，并用通俗语言书写。
4.7.1. 原子规则的期望
所有原子规则的期望必须描述用于判定某个测试目标是通过还是未通过的逻辑。期望必须只用输入方面、适用性描述和本规则其他期望中可获得的信息，不能用别的规则的信息。例如，可以写“期望一为真且...”，但不能写“规则 XYZ
通过且...”。这样保证原子规则是封装的。
注意： 有些规则需要更复杂的汇总逻辑，例如页面上 X% 的图片需有文本替代。这时页面本身就是测试目标，期望描述则是“测试目标（页面）有 X% 的 img 元素具备文本替代”。这种规则中期望的具体计算逻辑，留给具体实现，以避免规则格式本身过于复杂。
4.7.2. 复合规则期望
所有复合规则的期望必须描述用于根据其输入规则的结果，判定某个测试目标是通过还是未通过的逻辑。复合规则期望不能使用输入方面的信息。若所有输入规则均为不适用，则复合规则结果为不适用。
4.8. 背景
ACT 规则的背景必须包含假设和辅助功能支持两个部分。背景还可以包含规则开发相关信息，或指向相关重要阅读的其他资源、相关规则。当在规则中引用资料时，可说明与本规则内容的关系。比如关于网页内容辅助功能指南 [WCAG22] 成功标准的规则，可以引用 WCAG 2.2 解读文档、WCAG 2.2 技术、WAI-ARIA 1.2、CSS [css-2018]、HTML [HTML] 等规范。
4.8.1. 假设
ACT 规则必须列明任何已知的假设、局限性或测试、测试环境、所用技术或被测对象中的任何例外。例如，仅通过 CSS 属性检查部分测试 WCAG 2.2 成功标准 1.4.3 最小对比度 的规则，需要说明仅适用于可用 CSS 样式的 HTML 文本内容，且不支持图片文本。
有时同一辅助功能要求可有多种合理解释。例如，在网页内容辅助功能指南 [WCAG22]中，表情符号字符是“文本”还是“非文本内容”并不直观。无论选择哪一种解释，必须在规则中明确说明。
虽然假设部分必须包含在 ACT 规则中，但如无假设、局限或例外则可为空。
4.8.2. 辅助功能支持
内容可以设计为依赖不同辅助技术和用户代理对某些辅助功能特性的支持。例如，使用某个WAI-ARIA 1.2特性的内容，依赖相关特性有辅助技术及用户代理支持，否则就不可用。详见 WCAG 对辅助功能支持的定义。
ACT 规则必须包括任何已知的辅助功能支持局限性。
尽管辅助功能支持部分必须包含在 ACT 规则中，若无相关问题可为空。
注意： 网站辅助功能符合性评估方法（WCAG-EM）为测试场景定义辅助功能支持基线提供了指导，帮助 ACT 规则用户选择适合自身环境的规则。
4.8.3. 相关规则（可选）
相关规则是指同时测试相同辅助功能要求的其它规则。例如，某复合规则的相关规则可以是决定其结果的两个原子规则。同理，每个原子规则也可将其它原子规则及对应复合规则列为相关规则。
4.8.4. 其他资源（可选）
每当规则引用某资源时，可说明资源与本规则内容的关系。比如关于网页内容辅助功能指南 [WCAG22] 成功标准的规则，可以引用 WCAG 2.2 解读文档、WCAG 2.2 技术、WAI-ARIA 1.2、CSS [css-2018]、HTML [HTML] 等规范。
4.9. 示例
示例是可用于验证 ACT 规则实现效果的内容片段。每条规则必须有一个或多个用于通过、未通过和不适用 结果的示例。示例包括两部分数据：每个规则输入方面的内容片段，以及该规则的预期结果。示例既为读者提供场景，以便了解何时规则结果为通过、未通过或不适用，也供辅助功能测试工具和方法的开发者、使用者验证规则实现的正确性。
ACT 规则的每一个通过和不适用示例必须满足本规则所有一致性要求。每个未通过示例，所有一致性要求必须处于未满足状态。对于复合规则，所有输入规则的示例必须同样满足复合规则的一致性要求。
4.10. 规则版本
需要记录 ACT 规则的各个版本，以便规则使用者判断测试结果变化究竟源自规则变更还是内容本身变更。所有 ACT 规则以往版本必须在规则文档中记录或引用。
本节原名“变更日志”，两者均可。
4.11. ACT 规则格式版本
ACT 规则针对某一特定版本的 ACT 规则格式编写。每条 ACT 规则必须指明其所采用的 ACT 规则格式版本。因为规则格式并非完全向后兼容，此项很重要。
4.12. 术语表
ACT 规则必须有术语表。术语表必须包含结果定义，同时需收录规则适用性和期望章节所用的所有定义。因定义的更改会导致规则本身变化，这些定义不能与规则分离维护。如果为规则集采用共享术语表，则必须在术语表变动时，对所有引用该术语表的规则同步进行规则版本更新。
注意： 规则可用多个术语表，部分在规则内，部分在外部。术语表也可以引用其它文档（如 WCAG 2.2、HTML 5 等）中的定义。若外部术语表条目会独立变动，则需注明条目的版本。例如 HTML 5 标准经常更新，可在链接中注明作者采用的日期版本。
4.13. 问题列表（可选）
ACT 规则可以包含已知问题列表或相关问题列表。问题列表用于记录出现 ACT 规则的结果为未通过但本应通过或不适用，或相反的情况。产生这类问题的原因有多种，详情见规则准确性。
问题列表有两个作用：一方面能让 ACT 规则使用者了解为何会有不准确的结果，增强对规则的信心；另一方面也便于规则设计者规划规则的未来更新。新版本规则中已解决的问题会移入变更日志。
4.14. 实现（可选）
ACT 规则可以包含实现列表，每个实现包含一个或多个校验，这些校验与规则保持一致或部分一致。实现指用校验判断结果，从而确定辅助功能要求是否有可能被满足的测试方法或工具。这些校验可以完全自动化、完全手动，或二者结合。
校验无需与 ACT 规则一一对应。单个校验可和多条 ACT 规则一致，一组校验也可与单条 ACT 规则一致。
每个实现可包含如下信息：
4.14.1. 一致性
一致性描述某校验与 ACT 规则意图的匹配程度。若在 ACT 规则中包含一致性描述，则必须按本节规定判定一致性。ACT 规则的一致校验指可用于识别规则所描述的部分或全部不符合问题。校验为一致需满足以下全部条件：
-
真实阳性：示例无不一致之处，具体为：
-
通过和不适用示例不能被报告为未通过；并且 -
未通过示例不能被报告为通过或不适用；并且
-
-
完整性：覆盖范围无缺口，即：
-
校验的结果不应有任何
未测试；并且 -
至少有一个
未通过示例被报告为未通过；并且
-
-
规则映射：辅助功能要求需一致报告，即：
当某校验对一个示例报告多个结果时，需依照如下有序列表，取出现最早的结果用于判定一致性：
-
未通过 -
未测试 -
无法判定 -
通过 -
不适用
4.14.2. 部分一致性
若某校验不属于一致，但满足真实阳性条件，且其报告结果不全为无法判定或未测试，则视为部分一致。
4.14.3. 多校验一致性
实现可包含仅测试某个 ACT 规则部分的校验。只要组合后的校验覆盖 ACT 规则全部内容，这组校验就是一致的。校验集的“一致性”可以将所有部分一致的校验视为一个整体校验来判断。
若校验集满足一致校验的所有要求，则它就与 ACT 规则一致。该校验集的结果为与 ACT 规则部分一致的所有校验的结果列表，校验集的辅助功能要求为所有与 ACT 规则部分一致校验的辅助功能要求的列表。
4.15. 致谢（可选）
ACT 规则可以包含致谢信息，包括但不限于：
-
规则作者名单
-
规则审阅者/贡献者名单
-
资助或其他支持
5. 规则准确性
本节为非规范性。
虽然示例可用于判断 ACT 规则实现是否正确，但并不能保证实现永远不会产出错误结果。编写 ACT 规则时，难免会忽略某些边界情况。技术不断发展，内容作者也不断发现新颖或意外的用法。导致不准确的例子包括：
-
对测试对象的假设后来被证明不成立
-
技术被以不寻常且难以预测的方式使用
-
技术有变更，或某些技术方面被忽略
-
辅助功能要求被错误理解
错误结果有两类：实现不准确可以用示例改进，而规则本身不准确则无法靠示例修正。毕竟规则不准确是因为作者没意识到某边界情况。
当测试错误地指出不符合辅助功能要求时称为“假阳性”；反之，规则错误地判定符合性，就是“假阴性”。假阳性和假阴性比例可通过与辅助功能审计结果对比获得：
ACT 规则的假阳性和假阴性始终存在可能，因此规则通常要持续维护。维护 ACT 规则的流程不属于 ACT 规则格式的范畴，但建议规则作者自行制定维护流程。
6. 统一化
本节为非规范性。
虽然 ACT 规则格式设计用来促进统一，但 ACT 规则格式中没有直接要求禁止作者编写与已有规则不一致的新规则，也没有规定规则需具备多少实现或准确度。这样一来，不同规则集可设不同质量要求，也能随时间发展。
统一（harmonization）发生在一群规则实现者集体认可某条 ACT 规则的有效性。例如某无障碍测试工具厂商组成的社群可声明他们在某套 ACT 规则上达成统一。此类社群可自行为规则制定验收标准及更高质量要求。
类似的流程可参考WCAG ACT 评审流程。
7. 隐私注意事项
本规范提供辅助功能一致性测试（ACT）规则以测试内容是否符合网页内容辅助功能指南。本规范无意访问用户信息，也不会将用户信息直接暴露给用户代理或辅助技术。
8. 安全注意事项
本规范不提供协议、域和端口直接与底层平台（包括浏览器和操作系统）通信的方式，也不允许访问设备传感器。规范也未启用新的脚本执行或加载机制。目前未发现其他安全注意事项。
9. 定义
- 辅助功能要求
-
辅助功能要求旨在提升残障人士使用信息与通信技术产品的便利。对 ACT 规则映射来说，要求可分为强制或建议。强制要求必须满足以符合标准，或符合同类合同、政策或法规。建议要求仅推荐满足，不满足不会导致不符合或违规。
典型辅助功能要求如 WCAG 成功标准，也有其他标准（包括 W3C 标准）含有辅助功能建议，如 WAI-ARIA、HTML。公司政策、地区标准或立法中也常见辅助功能要求。
- 辅助功能要求文档
-
包含辅助功能要求的文档，如标准、合同、政策或法规。例：WCAG 2.2、WAI-ARIA 1.2、HTML 5.2、EPUB Accessibility 1.0、BBC HTML Accessibility Standards v2.0
- 校验
-
对网页或其它测试对象的无障碍性进行评估后得出一个或多个结果的流程。流程可为手动测试步骤说明、全自动测试，或手动与自动结合。
- 实现
- 结果
-
针对测试对象或其组成部分测试目标执行 ACT 规则后得出的结论。结果有以下五种类型：
注意：每个测试目标对应一个
通过或未通过结果。评估测试目标时，如无法全部测试，可报告为无法判定（如适用性自动，期望要手动判断）。如无测试目标，则规则只有一个
不适用结果。如无法确定是否存在测试目标，则有一个无法判定结果。若未进行评估，则测试目标有一个未测试结果。因此每个测试对象总有一个或多个结果。ACT 规则中的结果可参照EARL 结果属性表达，详见[EARL10-Schema]。
- 测试对象
-
可由 ACT 规则评估的资源或资源集合。
注意：实现者可用[EARL10-Schema]的 subject 属性 表达测试对象
- 测试目标
-
注意：实现者可用[EARL10-Schema]的 pointer 属性 表达测试目标
附录 1：用 JSON-LD 和 EARL 表达 ACT 规则结果
本节为非规范性。
本节提供了使用 EARL 和 JSON-LD 表达执行 ACT 规则后的结果示例。详情请参阅评估与报告语言和JSON-LD（面向关联数据的 JSON 序列化）。更多示例和背景资料可在EARL 的 JSON-LD 序列化 GitHub 仓库获取。
本节示例包括：
-
单断言的最简结果
-
多断言的结果
-
基于要求汇总
-
基于“测试对象”汇总
-
本节的假定上下文
附录 2：致谢
本节为非规范性内容。
参与本文件开发的 AG WG 成员
Shadi Abou-Zahra、Trevor Bostic、Helen Burge、Tom Brunet、Romain Deltour、Catherine Droege、Kathy Eng、Wilco Fiers、Alistair Garrison、Kasper Isager、严顺国、Todd Libby、Chris Loiselle、Sage Keriazes、Maureen Kraft、Daniel Montalvo、Mary Jo Mueller、Jey Nandakumar、Charu Pandhi、Stein Erik Skotkjerra、Suji Sreerama、 Anne Thyme Nørregaard 和 Kathleen Wahlbin。
支持资助方
本出版物由WAI-Tools 项目支持开发，该项目由欧盟委员会（EC）在 Horizon 2020 计划（资助协议 780057）下共同资助。出版物内容不一定反映欧盟委员会（EC）或欧盟（EU）成员国的观点或政策。
附录 3：变更历史
本节为非规范性内容。
自 ACT Rules Format 1.1 首次公开工作草案 以来的变更
- 2 范围 明确 ACT Rules Format 1.1 并非与 1.0 完全向后兼容
- 4.9 示例 明确输入规则测试用例必须与一致性要求保持一致
- 全部 Test cases 更名为示例（examples）
- 全部 示例现在仅使用 Bikeshed 自动编号
- 附录 1：用 JSON-LD 和 EARL 表达 ACT Rule 结果 新增本节示例正确渲染的标记
- 4.2. 规则描述 增加文本含有语言和书写方向元数据的假设
- 4. ACT 规则结构 强调 ACT 规则需支持本地化
- 4.1. 规则标识符 细化判断规则标识符唯一性的说明
- 4.4.1.2. 次要要求 次要要求说明不再需要在背景部分给出。
- 9. 定义 更新 cantTell 和 Untested 的定义。
- 4.12. 术语表 支持内部和外部术语表
- 7. 隐私注意事项 新增
- 8. 安全注意事项 新增
自 ACT Rules Format 1.0 以来的变更
- 4. 规则结构 Accessibility Support 与 Assumptions 现为背景的子节。
- 4.4. 辅助功能要求映射 辅助功能要求现分为一致性要求与次要要求。
- 4.6 适用性 接受主观适用性表达。客观与通俗要求由 must 改为 should。
- 4.8. 背景 新增可选相关规则和其他资源子节
- 4.10. 变更日志 变更日志重命名为规则版本
- 4.11 ACT 规则格式版本 新增需标识规则格式兼容版本的要求
- 4.14. 实现 新增该节，包括判断与 ACT 规则一致性的方法
- 7. 定义 Outcome 定义涵盖 cantTell 与 untested
- 整体 指向 W3C 规范的链接已更新至最新版
所有已发布版本的变更可通过 Editor's draft 到 Rules Format 1.0 推荐版的差异查看