1. 導入
現在、ユーザーがWeb Content Accessibility Guidelines [WCAG]などのアクセシビリティ標準に適合しているかどうかウェブコンテンツをテストするのに役立つ多くのテスト手順とツールが利用可能である。ウェブはサイズと複雑さの両方で発達するため、これらの手順とツールは、ウェブ上で利用可能なリソースのアクセシビリティを管理するために不可欠である。
このフォーマットは、WCAGおよびその他のアクセシビリティ要件文書への適合をテストする方法の一貫した解釈を可能にし、アクセシビリティテストで一貫した結果を促進することを目的としている。ルールフォーマットは、手動のアクセシビリティテストと、アクセシビリティテストツールによって実行される自動テストの両方を記述するように設計されている。
アクセシビリティ要件をテストする方法を文書化することは、再現可能なテスト結果とともに、透過的なアクセシビリティテストをもたらす。Accessibility Conformance Testing (ACT) Rules Formatは、アクセシビリティ適合性テストルール（ACTルール）として知られる、これらのテスト記述の要件を定義する。
ACTルールは、アクセシビリティ要件の特定の側面について特定の種類のコンテンツをテストする方法をわかりやすく説明したものである。 ACTルールは、どのようなコンテンツに適用されるのか、およびルールのすべての期待を満たすために適用可能な要素についてどの条件が当てはまるかを記述する。 WCAGのコンテキストでは、ACTルールは達成基準を満たすのための失敗をテストする。そのような失敗は、WCAGで文書化されているよくある失敗例でしばしば説明される。 ACTルールはテストプロセス用に記述されるもので、通常、よくある失敗例よりも具体的である。
ACTルールフォーマットは、ACTルールと呼ばれるために各ルールに含める必要のある情報のタイプの要件とルール構造を定義する。ACTルールの構造は、ACTルールの構造のセクションで定義される。各ACTルールは、テスト対象のコンテンツのタイプ、実行するテスト、および期待される結果のわかりやすい説明も含まれる。テスト結果が適合性に影響を与える場合、ルールはテストされる特定の要件を文書化する。テストの結果は、要件への適合または不適合を判断するために使用できる。テストケースはまた、ACTルールの一部として記述され、ルールの実装が期待される結果を正常に決定できることを検証する方法を提供する。
2. 範囲
この仕様で定義されるACT Rules Formatは、Hypertext Markup Language [HTML]、Cascading Style Sheets [css-2018]、Accessible Rich Internet Applications [WAI-ARIA]、Scalable Vector Graphics [SVG2]、EPUB 3などのウェブ技術を使用して作成されたコンテンツのテストに使用できるルール用に設計されている。 ACTルールフォーマットは技術に依存しないように設計されており、他の技術のテストルールを記述するために使用できることも意味する。
ACTルールフォーマットは、Web Content Accessibility Guidelines [WCAG]で定義されるアクセシビリティ要件のテスト専用のACT Rulesを記述するために使用でき、これはウェブコンテンツ用に特別に設計されている。ウェブ技術に適用可能なその他のアクセシビリティ要件も、ACTルールでテスト可能である。 たとえば、ACTルールを開発して、ウェブベースのユーザーエージェントのUser Agent Accessibility Guidelines [UAAG20]への適合性をテストできる。ACTルールフォーマットは、他の種類のアクセシビリティ要件のテストを説明するのに常に適しているとは限らない。
3. ACTルールタイプ
アクセシビリティにおいて、同じ種類のコンテンツをアクセシブルにするためのさまざまな技術的解決策がしばしば存在する。たとえば、HTMLのimg要素にアクセシブルな名前を付ける方法は複数ある。1つのルールで複数の解決策をテストできる。しかし、そのようなルールは非常に複雑になる傾向があり、理解と維持が困難になる。ACTルールフォーマットは、次の2種類のルールを提供することでこれを解決する：
アトミックルールは、特定の種類の解決策をテストする方法を説明する。これには、テスト対象のどの要素、ノード、またはその他の「パーツ」がテストされるか、およびそれらのテスト対象がルールに合格または失敗とみなされるときの正確な定義が含まれる。これらのルールは小さく、アトミックに保つ必要がある。これは、アトミックルールが単一の「条件」をテストし、他のルールの結果を使用せずにテストすることを意味する。
コンポジットルールは、複数のアトミックルールの結果を組み合わせて、各テスト目標を単一の結果にする方法を説明する。コンポジットルールは複数の「条件」を含めることができ、それぞれが個別のアトミックルールでテストされる。コンポジットルールのロジックは、これらの条件を満たす条件のいずれか、またはそれらの組み合わせを使用して、単一の結果を決定する方法を記述する。
コンポジットルールに他のコンポジットルールを含めることはできない。ネストされたコンポジットルールが必要になるときはいつでも、関連するすべてのアトミックルールを新しいコンポジットルールに直接組み合わせることができる。
すべてのアトミックルールがコンポジットルールの一部である必要はない。コンポジットルールは、複数のアトミックルールの結果を組み合わせて、テスト対象がアクセシビリティ要件を満たしていないかどうかを判断する必要がある場合に使用される。
アトミックルールとコンポジットルールとの分離は、責任の分割を生み出す。アトミックルールは、ウェブコンテンツが特定の解決策で正しく実装されているかどうかをテストする。コンポジットルールは、他のアトミックルールからの結果の組み合わせが、部分的または全体的にアクセシビリティ要件を満たしているかどうかをテストできる。
4. ACTルール構造
ACTルールは、少なくとも次の項目で構成されなければならない：
説明タイトル
ルール入力、これは以下のいずれかを含む：
ACTルールはまた、以下を含んでもよい：
ACTルールフォーマットは、ACTルールを記述できるフォーマット（HTML、DOCX、PDFなど）を規定しない。しかし、ACTルールは、Web Content Accessibility Guidelines [WCAG]または同等のアクセシビリティ標準に準拠した文書で作成しなければならない。これにより、障害を持つ人がACTルールにアクセスできるようになる。ACTルールのテストケースには、アクセシブルでないコンテンツを含めることが可能である。テストケースにWCAG 2.1セクション5.2.5非干渉にリストされるアクセシビリティの問題が含まれる場合、ユーザーは事前にこれについて警告しなければならない。障害を持つ人をサポートすることに加えて、アクセシブルなフォーマットを使用することはまた、ACTルールの国際化も容易になる。
4.1. ルール識別子
ACTルールは識別子を持たなければならない。ルールがルールセットの一部である場合、この識別子は一意でなければならない。識別子は、プレーンテキスト、URL、データベース識別子などの任意のテキストにすることができる。
識別子に加えて、ACTルールの新しいリリースはそれぞれ、日付または数字のいずれかでバージョン管理をしなければならない。そのルールの以前のバージョンへの参照が利用可能でなければならない。 ルールの更新時に識別子を変更してはならない。大幅な変更を行う場合は、新しい識別子で新しいルールを作成すべきであり、古いルールを廃止すべきである。
4.2. ルール説明
ACTルールは、ルールが何をするのかの簡単な説明を提供する平易な言葉による説明を持たなければならない。
4.3. ルールタイプ
ACTルールは、次のいずれかのルールタイプを持たなければならない：
- アトミックルール
- コンポジットルール
ルールタイプの詳細な定義については、ルールタイプセクションを参照のこと。
4.4. アクセシビリティ要件のマッピング
ACTルールが1つ以上のアクセシビリティ要件文書への適合性をテストするように設計される場合、ルールは、ルールの結果の1つ以上が失敗したときに満たされない文書からのすべてのアクセシビリティ要件をリストしなければならない。たとえば、画像ボタンが代替テキストを持つかどうかをテストするWCAGのルールを設計する場合、ルールは達成基準1.1.1非テキストコンテンツ、および4.1.2名前 (name) ・役割 (role) 及び値 (value)にマッピングされる。そのACTルールは、アクセシビリティ要件のマッピングに両方の達成基準をリストする。
マッピングの各アクセシビリティ要件は、次のものが含まれなければならない：
アクセシビリティ要件の名前、タイトル、識別子、または要約のいずれか、および
アクセシビリティ要件文書の名前、および
アクセシビリティ要件文書が存在する場合、その文書へのリンクまたは参照、および
アクセシビリティ要件が存在する場合、そのアクセシビリティ要件に関連する適合レベル。
4.4.1. 結果のマッピング
マッピングのアクセシビリティ要件ごとに、ACTルールは、そのテスト対象のアクセシビリティ要件を満たすためにルールの結果が何を意味するかを示さなければならない。テスト目標の1つ以上の結果がfailedである場合、テスト対象のアクセシビリティ要件は満たされない。すべての結果がpassedまたはinapplicableである場合、アクセシビリティ要件が満たされるか、さらにテストが必要になる。 アクセシビリティ要件が満たされるかどうかを判断するために使用できるルールは、満足なテストと呼ばれる。
注：Web Content Accessibility Guidelines [WCAG]では、達成基準はpassed、failed、またはinapplicableとは評価されない。むしろ、達成基準は満たされる（または満されない）。（WCAG 2.1の定義：成功基準を満たすを参照のこと。）達成基準が満たされない場合、WCAG 2.1適合要件1で説明されているように、ウェブページは適合する代替版がある場合にのみ適合できる。
4.4.2. WCAG外のマッピング
ACTルールは、Hypertext Markup Language [HTML]のアクセシビリティ要件など、W3Cアクセシビリティ標準の一部ではないアクセシビリティ要件をテストしたり、RGAA 3 2016のような方法でテストしたりするために使用することができる。ACTルールは、 マッピングするアクセシビリティ要件が適合するために必須かどうかを、そのアクセシビリティ要件文書で示さなければならない。適合のために必須でないアクセシビリティ要件の例は、WCAGの十分な達成方法、すなわち要件とオプションの「ベストプラクティス」の両方を含む企業スタイルガイドである。必須のものとオプションのものの違いを明確にする必要がある。
4.4.3. アクセシビリティ要件のないルール
ルールがアクセシビリティ要件にマッッピングされない場合、アクセシビリティ要件のマッピングは、アクセシビリティ要件文書への適合に必要ないという説明のみが含まれる。これは、コンポジットルールで使用されるアトミックルールで一般的である。
failedの結果をアクセシビリティ要件にマッピングできない場合、アクセシビリティ要件のマッピングにアクセシビリティ要件があってはならない。オプションの背景セクションは、テーマに関連しているが、ルールが失敗テストではない場合、アクセシビリティ要件文書をリストするために使用できる。
4.4.4. 外部のアクセシビリティ要件のマッピング
この節は非規範的である。
多くの場合、ルールは1つ、または場合によってはアクセシビリティ要件文書の小さなコレクション用に設計されているが、他のアクセシビリティ要件文書もそれら文書のACTルールにマッッピングされる可能性がある。たとえば、Web Content Accessibility Guidelines [WCAG]のルールを作成できるが、その多くは企業の内部アクセシビリティポリシーにマッピングするかもしれない。 そのようなシナリオでは、外部のアクセシビリティ要件のマッピングを作成できる。 外部アクセシビリティ要件マッピングは、別のアクセシビリティ要件文書にマッピングを追加することにより、ACTルールのアクセシビリティ要件マッピングを修正する。 外部アクセシビリティ要件のマッピングは、マッピングを変更することのみを目的としたルールの重複を回避する。
4.5. ルール入力
ACTルールを使用してコンテンツを評価するためには、ルールにテスト対象からの情報が必要である。 これはルールするための入力である。どのような入力が必要なのかを明示することで、テスターがルールを使用するためにどのような能力が必要かを理解できるようにする。アトミックルールとコンポジットルールの入力は異なる。
4.5.1. 入力アスペクト（アトミックルールのみ）
入力アスペクトは、テスト対象の明確な一部である。特定のコンテンツの一部分をエンドユーザーにレンダリングするのは、異なる技術を通常含んでおり、その一部またはすべてがアトミックルールの入力として必要となる。たとえば、サーバーとクライアントとの間で交換されるHypertext Transfer Protocol [http11]メッセージを直接操作する必要があるルールもある一方で、ウェブブラウザーによって公開されるDocument Object Model [DOM] ツリーを操作する必要があるルールもある。
アトミックルールは、アトミックルールの適用可能性と期待のための入力として使用されるアスペクトをリストしなければならない。ルールは、HTTPメッセージとDOMツリーの両方など、いくつかのアスペクトで同時に動作できる。
HTTPメッセージ、DOMツリー、CSSスタイリング[css-2018]など、一部の入力アスペクトは正式な仕様で明確に定義されている。これらについては、Common Input Aspects noteの対応するセクションへの参照は、アスペクトの説明として十分である。明確に定義されていない入力アスペクトの場合、ACTルールは、問題のアスペクトの詳細な説明、または明確に定義された説明への参照のいずれかを含めなければならない。
入力アスペクトが提供される方法は関係ない。たとえば、DOMツリーはHTMLとしてHTTPを通して提供したり、EPUBパブリケーションの複数のページとして扱ったり、JSXソースファイルから推測したりすることができる。入力アスペクトとしてDOMツリーのみを持つすべてのルールは、これらの技術に適用できる。
4.5.2. 入力ルール（コンポジットルールのみ）
コンポジットルールは、アトミックルールからの結果を使用し、それら結果にロジックを適用して、テスト目標ごとに単一の結果を決定できるようにする。期待で使用されるすべてのアトミックルールの識別子および説明的なタイトルは、コンポジットルールにリストされなければならない。入力ルールは、入力アスペクトがアトミックルールの入力を記述する方法と同様に、コンポジットルールの入力を記述する。
4.6. 適用性
適用性は、テスト対象のどの部分がテストされるかを説明する。
4.6.1. アトミックルールへの適用性
適用性セクションは、アトミックルールの必須部分である。ルールが適用されるテスト対象の部分の正確な説明が含まれなければならない。たとえば、DOM [DOM]ツリーの特定のノード、またはHTML [HTML]文書の誤って閉じられたタグ。これらはテスト目標として知られている。適用性は、ルールでリストされた入力アスペクトを通じて利用可能になった情報のみを使用しなければならない。他の情報を適用性に使用することはできない。適用性は、客観的、明確、およびわかりやすい言葉で説明しなければならない。
客観的な説明とは、特定の技術において、不確実性なしに解決できる説明である。HTMLの客観的プロパティの例は、タグ名、それらタグ名の計算されたロール、2つの要素間の距離などです。一方で主観的プロパティは、装飾、ナビゲーションメカニズム、事前に記録されたものなどの概念である。
見出しや画像などの概念でさえ誤解される可能性がある。これらの用語は、あいまいであるため、タグ名、セマンティックロール、またはウェブページ上の要素の目的を指すかもしれない。後者は客観的に定義することはほぼ不可能である。適用性に使用する場合、潜在的に曖昧な概念を客観的に定義しなければならない。定義は、ルールの用語集に記載する、または使用するセクションで定義できる。
4.6.2. コンポジットルールへの適用性
コンポジットルールの適用性は、入力ルールにリストされているルールからのすべての適用性定義の結合として定義される。ルールの著者は、コンポジットルールの適用性の説明を省略してもよい。これは、組み合わせた適用性を平易な言葉で表現することが難しい場合に役立つ。 コンポジットルールに適用性が含まれる場合、そのコンポジットルールは入力ルールのすべての適用性の結合でなければならない。
コンポジットルールの入力ルールは、異なる適用性を持ってもよいことに注意すること。このため、コンポジットルール内で適用可能なすべてのテスト目標がすべての入力ルールによってテストされるわけではない。
4.7. 期待
ACTルールは、1つ以上の期待が含まれなければならない。期待は、適用性から導き出されたテスト目標の要件が何であるかを説明する。期待は、テスト目標に関する主張である。テスト目標がすべての期待を満たす場合、そのテスト目標はルールにpassedとなる。テスト目標がすべての期待を満たさない場合、そのテスト目標はルールにfailedとなる。テスト目標がない場合、ルールの結果はinapplicableとなる。
それぞれの期待は、明確で、あいまいでなく、そして平易な言葉で書かれなければならない。
4.7.1. アトミックルールへの期待
アトミックルールのすべての期待は、テスト目標の単一のpassedまたはfailedの結果を決定するために使用されるロジックを説明しなければならない。期待は、適用性、および同じルールの他の期待から、入力アスペクトで利用可能な情報のみを使用しなければならない。他の情報は期待に使用できない。よって、たとえば期待は「期待1が真であり…」であるかもしれないが、「ルールXYZが合格であり…」となることはない。これにより、アトミックルールが確実にカプセル化される。
注：場合によっては、より複雑な集計を含むルールが必要になることがある。たとえば、ウェブページ上のすべての画像のX％にテキストによる代替があると予想される。この場合、ページ自体がテスト目標となる必要がある。期待は「テスト目標（ページ）には、すべてのimg要素のX％のテキストによる代替がある」となるだろう。 そのようなルールの期待を計算するためのロジックは、このルールフォーマットの過度の複雑さを回避するために、実装に任される。
4.7.2. コンポジットルールへの期待
すべてのコンポジットルールの期待は、入力ルールのルールの結果に基づいて、テスト目標の単一のpassedまたはfailedの結果を決定するために使用されるロジックを記述しなければならない。コンポジットルールの期待は、入力アスペクトからの情報を使用してはならない。すべての入力ルールが適用できない場合、コンポジットルールの結果はinapplicableとなる。
4.8. 仮定
ACTルールは、評価、テスト環境、使用されている技術、またはテスト主題の対象に関するすべての既知の仮定、制限、または例外をリストしなければならない。たとえば、CSSプロパティの検査に基づいてWCAG 2.1達成基準1.4.3コントラスト(最低限)を部分的にテストするルールは、CSSでスタイル設定可能なHTMLテキストコンテンツにのみ適用可能であり、ルールは文字画像をサポートしないと述べることができる。
アクセシビリティ要件を解釈できるもっともらしい方法が複数ある場合がある。たとえば、Web Content Accessibility Guidelines [WCAG]において、絵文字が「テキスト」であるか「非テキストコンテンツ」であるかはすぐにはわからない。 解釈がどうであれ、これはルールに文書化されなければならない。
仮定はACTルールに含めなければならないが、既知の仮定、制限、または例外がない場合は空になってもよい。
4.9. アクセシビリティサポート
コンテンツは、さまざまな支援技術やユーザーエージェントによる特定のアクセシビリティ機能のサポートに依存するように設計さされうる。たとえば、特定のWAI-ARIA 1.1機能を使用するコンテンツは、支援技術とユーザーエージェントによってサポートされるその機能に依存している。このコンテンツは、WAI-ARIAをサポートしない支援技術やユーザーエージェントでは機能しない。ウェブ技術のアクセシビリティサポーテッドの使用については、WCAGの定義を参照のこと。
ACTルールは、アクセシビリティサポートに関する既知の制限を含めなければならない。
アクセシビリティサポートのセクションはACTルールに含めなければならないが、既知のアクセシビリティサポートの問題がない場合は空になってもよい。
注：Website Accessibility Conformance Evaluation Methodology (WCAG-EM)は、テストシナリオのアクセシビリティサポートベースラインを定義するためのガイダンスを提供する。これは、ACTルールのユーザーが自分の状況に適したルールを選択するのに役立つ。
4.10. テストケース
テストケースは、ACTルールの実装を検証するために使用できるコンテンツ（のスニペット）である。各ルールは、passed、failed、およびinapplicableの結果の1つ以上のテストケースを持たなければならない。テストケースは、2つのデータ、ルールの各入力アスペクトのスニペット、およびそのルールの期待される結果で構成される。テストケースは2つの機能を果たす。まず、ルールの結果がpassed、failed、またはinapplicableである場合に、読者が理解するためのシナリオ例としてである。また、アクセシビリティテストツールおよび方法論の開発者およびユーザーが、ルールが正しく実装されていることを検証するのにも役立つ。
4.11. 変更ログ
ルールのユーザーはテスト結果の変更がテストの実行時に使用されるルールの変更によるものなのか、またはコンテンツ自体の変更によるものなのかを理解できるように、ACTルールの変更を追跡することが重要である。 評価の結果を変更する可能性のあるACTルールへのすべての変更は、変更ログに記録されなければならない。 変更ログは、ルール文書自体の一部にするか、ルール文書から参照するかのいずれも可能である。
4.12. 用語集
ACTルールは用語集のセクションを持たなければならない。用語集は、結果の定義と、ルールの適用性および期待のセクションで使用される定義を含まなければならない。定義を変更するとルールが変更されるため、これらの定義をルールから独立して維持することはできない。共有の用語集をルールに使用する場合、定義の変更は、その定義を使用するすべてのルールの変更ログに含めなければならない。
4.13. Issueリスト（オプション）
ACTルールは、既知のissueの、リストまたはリストへの参照を含めてもよい。issueリストは、ACTルールの結果が、passedまたはinapplicableであるはずの場所でfailed場合、またはその逆の場合を記録するために使用される。これが発生する理由はいくつかある。詳細については、ルールの精度を参照のこと。
issueリストには2つの目的がある。ACTルールのユーザーの場合、issueリストは、不正確な結果が発生した理由に関する洞察を提供し、そのルールの結果に対する信頼を提供する。ルールの設計者にとって、issueリストは、ルールの将来の更新を計画するのにも役立つ。ルールの新しいバージョンにて、解決された問題は変更ログに移動される。
4.14. 背景（オプション）
ACTルールは、ルール開発の背景に関する情報、または関連する資料への参照が含まれてもよい。背景情報はオプションであるが、ルールに含まれている場合はいつでも、関連する読みものとの関係を指定できる。Web Content Accessibility Guidelines [WCAG]の達成基準のルールに関連する背景参照の例は、WCAG 2.1 解説書、WCAG 2.1達成方法集、またはWAI-ARIA 1.1、CSS [css-2018]、またはHTML [HTML]仕様である。
4.15. 謝辞（オプション）
ACTルールには謝辞を含んでもよい。これには以下が含まれるが、これらに限定されない：
ルール著者のリスト
ルールのレビューア/コントリビューターのリスト
資金提供またはその他のサポート
5. ルールの精度
この節は非規範的である。
テストケースは、ACTルールが正しく実装されているかどうかを判断するために使用できるが、実装によって誤った結果が生成されないことを保証するものではない。 ACTルールを作成する場合、エッジケースが見落とされることはほぼ避けられない。技術は常に進化しており、コンテンツ著者は技術を使用するための新しい予期しない方法を常に考え付きます。不正確さの原因のいくつかの例は次のとおりである：
真実ではないことが判明したテスト対象についての仮定がなされた
技術が独特で予測が難しい方法で使用された
技術に変化があるか、技術の側面が見落とされていた
アクセシビリティ要件が正しく解釈されなかった
不正確な結果を生み出す可能性のある不正確さには2つの種類がある。実装の不正確さはテストケースで対処できるが、ACTルール自体の不正確さは対処できない。結局のところ、ルールの不正確さは、ルールの著者が特定のエッジケースを認識していないことに起因する。
テスト結果がアクセシビリティ要件への不適合を誤って示している場合、これは偽陽性と呼ばれる。反対に、ルールが誤って適合性を示している場合、これは偽陰性である。偽陽性と偽陰性の割合は、アクセシビリティ監査の結果と比較することで計算できる。
偽陽性：これは、ルールによって
failedしたが、アクセシビリティ要件を満たしているテスト目標の割合である。偽陰性：これは、ルールに
passedしたが、アクセシビリティ要件を満たしていないテスト目標の割合である。
ACTルールで偽陽性と偽陰性が発生する可能性が常に存在するということは、継続的なメンテナンスが必要になる可能性が高いことを意味する。ACTルールを維持するためのプロセスの設計は、ルール自体に限定されているACTルール形式の範囲外である。それでも、ルールの著者はルールを維持するためのプロセスを作成することを勧める。
6. 調和
この節は非規範的である。
ACTルールフォーマットは調和を促進するように設計されているが、ACTルールフォーマットには、ルール著者がすでに確立されているACTルールと矛盾するルールを作成するのを防ぐ直接の要件は存在しない。ACTルールに特定の数の実装を持たせたり、特定のレベルの精度を持たせたりする必要もない。これにより、ルールセットごとに品質要件を変えることができ、時間の経過とともに開発することができる。
調和は、ルール実装者のグループがACTルールの有効性を集合的に受け入れるときに発生する。たとえば、アクセシビリティテストツールベンダーのコミュニティグループは、特定のACTルールのセットに調和していると宣言できる。そのようなグループは、ルールの受け入れ基準を設定し、ACTルールフォーマットを超える品質要件を持つことができる。
そのようなプロセスの例は、WCAG ACT Review Processである。
7. 定義
- アクセシビリティ要件（Accessibility requirement）
要件は、標準に準拠するため、または契約、ポリシー、もしくは規制に準拠するために満たす必要のある条件である。アクセシビリティ要件は、ICT製品への障害を持つ人のアクセスを改善することを目的とした要件である。
アクセシビリティ要件の一般的な例は、WCAG達成基準である。WAI-ARIAやHTMLなど、アクセシビリティに関する推奨事項があるW3C標準を含む他の標準が存在する。アクセシビリティ要件は、会社のポリシー、地域の企画、または法律にもよく見られる。
- アクセシビリティ要件文書（Accessibility requirements document）
アクセシビリティ要件を含む、標準、契約、ポリシー、規制などの文書。 たとえば、WCAG 2.1、WAI-ARIA 1.1、HTML 5.2、EPUB Accessibility 1.0、BBC HTML Accessibility Standards v2.0など。
- 結果（Outcome）
テスト対象またはその構成要素であるテスト目標の1つでACTルールを評価することから得られる結論。結果は、次の3つの種類のいずれかになる：
- 該当なし（Inapplicable）：テスト対象のどの部分も適合性に一致しない
- 合格（Passed）：テスト目標がすべての期待を満たしている
- 失敗（Failed）：テスト目標がすべての期待を満たしていない
注：ルールには、テスト目標ごとに1つの
passedまたはfailedの結果を持つ。テスト目標がない場合、ルールは1つのinapplicableの結果を持つ。これは、各テスト対象が1つ以上の結果を持つことを意味する。注：[EARL10-Schema]を使用する実装者は、outcome propertyを使用して結果を表現できる。
passed、failed、inapplicableに加えて、EARL1.0はincomplete結果も定義した。完全に適用したとき、これはACTルールの結果にはなりえないが、ルールが部分的にしか評価されないことがよくある。たとえば、適用性が自動化されているが、期待を手動で評価する必要がある場合である。このような「中間」の結果は、incompleteの結果で表現できる。- テスト対象（Test Subject）
ACTルールで評価できるリソースまたはリソースのコレクション。
注：[EARL10-Schema]を使用する実装者は、 subject propertyを使用してテスト対象を表現できる。
- テスト目標（Test Target）
-
注：[EARL10-Schema]を使用する実装者は、pointer propertyを使用してテスト目標を表現できる。
付録1：JSON-LDとEARLを使用したACTルールの結果の表現
この節は非規範的である。
このセクションでは、EARLとJSON-LDを使用してACTルールを実行した結果を表現する例を示す（Evaluation and Report LanguageおよびA JSON-based Serialization for Linked Data (JSON-LD)を参照）。JSON-LD serialization of EARL GitHubリポジトリーで、さらに多くの例と背景が提供されている。
このセクションの例は次のとおり：
例1：1つのアサーションからの最小限の結果
{ "@context" : "context.json" , "@type" : "Assertion" , "assertedBy" : "https://example.org/MyTool" , "subject" : "https://example.org/page1.html" , "test" : "ACT-CG:rules/23a2a8" , "result" : { "outcome" : "earl:failed" , "pointer" : "html > body > h1:first-child" } }
例2：複数のアサーションの結果
{ "@context" : "context.json" , "@graph" : [{ "@type" : "Assertion" , "assertedBy" : "https://example.org/MyTool" , "subject" : "https://example.org/page1.html" , "test" : "ACT-CG:rules/23a2a8" , "result" : { "outcome" : "earl:failed" , "pointer" : "html > body > h1:first-child" } }, { "@type" : "Assertion" , "assertedBy" : "https://example.org/AnotherTool" , "subject" : "https://example.org/page1.html" , "test" : "ACT-CG:rules/23a2a8" , "result" : { "outcome" : "earl:passed" , "pointer" : "html > body > h1:nth-child(2)" } }] }
例3：要件に基づく集計（例たとばWCAG達成基準）
{ "@context" : "context.json" , "@type" : "Assertion" , "assertedBy" : "https://example.org/MyTool" , "subject" : "https://example.org/page1.html" , "test" : { "@type" : "earl:TestRequirement" , "@id" : "WCAG21:non-text-content" }, "result" : { "outcome" : "earl:failed" , "source" : [{ "test" : "ACT-CG:rules/23a2a8" , "result" : { "outcome" : "earl:failed" , "pointer" : "html > body > h1:first-child" } }, { "test" : "ACT-RULES-CG:rules/23a2a8" , "result" : { "outcome" : "earl:passed" , "pointer" : "html > body > h1:nth-child(2)" } }] } }
例4：「テスト対象」に基づく集計（たとえばウェブサイト）
{ "@context" : "context.json" , "@type" : "Assertion" , "assertedBy" : { "@type" : "Organization" , "@id" : "_:myOrg" , "title" : "My Organization" , "description" : "Accessibility testing service" , "homepage" : "http://example.org/myOrg/" }, "subject" : { "@type" : [ "WebSite" , "TestSubject" ], "@id" : "https://example.org/" }, "test" : { "@type" : "earl:TestRequirement" , "@id" : "http://www.w3.org/WAI/WCAG2A-Conformance" }, "result" : { "outcome" : "earl:failed" , "source" : [{ "test" : { "@type" : "earl:TestRequirement" , "@id" : "WCAG21:non-text-content" }, "result" : { "outcome" : "earl:failed" , "source" : [ …] } }, { "test" : { "@type" : "earl:TestRequirement" , "@id" : "WCAG21:audio-only-and-video-only-prerecorded" }, "result" : { "outcome" : "earl:passed" , "source" : [ …] } }, { "test" : { "@type" : "earl:TestRequirement" , "@id" : "WCAG21:captions-prerecorded" }, "result" : { "outcome" : "earl:passed" , "source" : [ …] } }, …] } }
例5：このセクションの想定されるコンテキスト
{ "@vocab" : "http://www.w3.org/ns/earl#" , "cnt" : "http://www.w3.org/2011/content#" , "dct" : "http://purl.org/dc/terms/" , "earl" : "http://www.w3.org/ns/earl#" , "foaf" : "http://xmlns.com/foaf/0.1/" , "htp" : "http://www.w3.org/2011/http#" , "ptr" : "https://www.w3.org/2009/pointers#" , "schema" : "http://schema.org/" , "xsd" : "https://www.w3.org/2001/XMLSchema#" , "WCAG20" : "https://www.w3.org/TR/WCAG20#" , "WCAG21" : "https://www.w3.org/TR/WCAG21#" , "ACT-RULES-CG" : "https://act-rules.github.io/" , "WebSite" : "schema:WebSite" , "WebPage" : "schema:WebPage" , "title" : "dct:title" , "description" : "dct:description" , "date" : "dct:date" , "hasVersion" : "dct:hasVesion" , "isPartOf" : "dct:isPartOf" , "hasPart" : "dct:hasPart" , "source" : "dct:source" , "Agent" : "foaf:Agent" , "Person" : "foaf:Person" , "Organization" : "foaf:Organization" , "Group" : "foaf:Group" , "Document" : "foaf:Document" , "name" : "foaf:name" , "firstName" : "foaf:firstName" , "surname" : "foaf:surname" , "mbox" : "foaf:mbox" , "mbox_sha1sum" : "foaf:mbox_sha1sum" , "member" : "foaf:member" , "homepage" : "foaf:homepage" , "assertedBy" : { "@type" : "@id" }, "subject" : { "@type" : "@id" }, "test" : { "@type" : "@id" }, "mode" : { "@type" : "@id" }, "outcome" : { "@type" : "@id" }, "pointer" : { "@id" : "earl:pointer" , "@type" : "ptr:CSSSelectorPointer" } }
付録2：謝辞
この節は非規範的である。
この文書の作成に積極的なAG WGの参加者
Shadi Abou-Zahra, Trevor Bostic, Romain Deltour, Kathy Eng, Wilco Fiers, Alistair Garrison, Kasper Isager, Maureen Kraft, Mary Jo Mueller, Jey Nandakumar, Charu Pandhi, Stein Erik Skotkjerra, Anne Thyme Nørregaard, Kathleen Wahlbin
資金提供者
This publication has been developed with support from the WAI-Tools Project, co-funded by the European Commission (EC) under the Horizon 2020 Program (Grant Agreement 780057). The content of this publication does not necessarily reflect the views or policies of the European Commission (EC) or any of the European Union (EU) Member States.
付録3：変更履歴
この節は非規範的である。
No changes have been made since the previous Proposed Recommendation draft of 30 July 2019.