1. はじめに
現在、Webコンテンツアクセシビリティガイドライン [WCAG22]などのアクセシビリティ規格への適合性を確認するために、多くのテスト手順やツールが利用可能です。Webが規模や複雑さの両面で発展する中、これらの手順やツールは、Web上のリソースのアクセシビリティ管理に不可欠です。
ACTルール形式は、WCAGやその他のアクセシビリティ要求文書の適合性テストの一貫した解釈を可能にし、テスト結果の一貫性を促進するための指針を提供します。ACTルール形式は、手動テストと、アクセシビリティテストツールによって実施される自動テストの両方を記述できるよう設計されています。
アクセシビリティ要求のテスト方法を文書化することで、透明性があり再現性のあるアクセシビリティテストが可能になります。ACTルール形式は、これらのテスト記述（アクセシビリティ適合性テストルール、ACTルール）の要件を定義します。
ACTルールとは、特定の種類のコンテンツに対してアクセシビリティ要求の特定の側面をテストする方法について、わかりやすく記述したものです。ACTルールは、どのような内容に適用するか、適用対象の要素にどのような条件が満たされていればルールの期待事項をすべて満たすかについて記述します。WCAGの文脈では、ACTルールは成功基準を満たせない失敗をテストします。こうした失敗は、WCAGで文書化された一般的な失敗に示されていますが、ACTルールはテスト手順としてより具体的です。
ACTルール形式は、ACTルールと呼ばれるために必要な情報タイプおよびルール構造を定義します。ACTルールの構造はACTルール構造セクションで定義されています。各ACTルールには、テスト対象となるコンテンツの種類、実施するテスト、期待される結果の内容が簡潔に記述されています。テスト結果が適合性に影響する場合、ルールは対象となる要求項目を明確に記録します。テスト結果は、その要求項目への適合・非適合の判断に利用できます。実装者が期待される結果を正しく判定できるよう、ACTルールには例も含まれます。
2. 対象範囲
本仕様で定義されるACTルール形式は、ハイパーテキストマークアップ言語 [HTML]、カスケーディングスタイルシート [css-2018]、Accessible Rich Internet Applications [WAI-ARIA]、スケーラブルベクターグラフィックス [SVG2]、EPUB 3 [epub-33]など、Web技術で作成されたコンテンツのテストに使えるルールを想定しています。ACTルール形式は技術非依存であり、他の技術のテストルール記述にも利用できます。
ACTルール形式は、Webコンテンツアクセシビリティガイドラインアクセシビリティ要求（[WCAG22]）のテスト用ACTルールの記述にも利用できます。Web技術に適用できる他のアクセシビリティ要求にも、ACTルールでテストが可能です。たとえば、Webベースユーザーエージェントの適合性をUser Agent Accessibility Guidelines [UAAG20]に対してテストするためのACTルールも開発できます。一方で、他の種類のアクセシビリティ要求のテスト記述においては、ACTルール形式が必ずしも常に適用可能であるとは限りません。
2.1. 後方互換性
ACTルール形式1.1は、主に1.0と後方互換性がありますが、完全ではありません。ACTルール形式1.1では、1.0にはなかった要件が導入されています。また、1.0では認められていなかった主観的な適用範囲など、一部の内容が許容されるようになりました。詳細な変更点は変更履歴に記載されています。
3. ACTルールの種類
アクセシビリティにおいては、同じ種類のコンテンツをアクセシブルにするための技術的解決策が複数存在することが多いです。たとえば、HTMLのimg要素にアクセシブルな名前を付けるには、複数の方法があります。複数の解決策を1つのルールでテストすることもできますが、この場合ルールが非常に複雑となり、理解や保守が難しくなります。ACTルール形式は、次の2種類のルールによる解決策を提供します：
-
アトミックルール（Atomic rules）は、特定の解決策をテストする方法を記述します。どの要素、ノード、またはその他のテスト対象の「部分」がテストされるべきか、そしてこれらのテストターゲットがそのルールに合格・不合格となる条件を正確に定義します。アトミックルールは小さくアトミック（分割可能）であることを求められます。1つの「条件」をのみテストし、他のルールのアウトカムを使用せずに記述されます。
-
コンポジットルール（Composite rules）は、複数のアウトカムを、各テストターゲットについて1つの結果にまとめる方法を記述します。コンポジットルールは複数の「条件」を含み、それぞれが独立したアトミックルールでテストされます。コンポジットルールで論理を記述し、いずれかひとつでも条件を満たす場合や、複数条件の組み合わせによる場合など、単一のアウトカムを判定します。
コンポジットルールには他のコンポジットルールを含めることはできません。もし入れ子状のコンポジットルールが必要な場合は、関連するすべてのアトミックルールを新しいコンポジットルールに直接組み合わせてください。
すべてのアトミックルールがコンポジットルールの一部である必要はありません。コンポジットルールは、複数のアトミックルールのアウトカムを組み合わせて、テスト対象がアクセシビリティ要求を満たさないかどうかを判断したい場合に使用されます。
アトミックルールとコンポジットルールの分離によって、役割分担が実現します。アトミックルールはWebコンテンツが特定の解決策で正しく実装されているかを判定し、コンポジットルールは他のアトミックルールのアウトカムが要求事項を部分的に、あるいは全体的に満たしているかを判定します。
4. ACTルール構造
ACTルールは、少なくとも以下の項目を含めなければなりません：
-
記述的タイトル
-
ルール入力（以下のいずれか）：
ACTルールは以下も含むことができます：
ACTルール形式は、ACTルール記述のフォーマット（HTML、DOCX、PDF等）を指定しません。ただし、ACTルールはWebコンテンツアクセシビリティガイドライン[WCAG22]またはこれに相当するアクセシビリティ標準に適合する文書で記述しなければなりません。これにより、ACTルールが障害のある人にもアクセシブルになることが保証されます。ACTルールの例には、アクセシビリティ上問題のある内容を含めても構いません。もし例にWCAG 2.2 Section 5.2.5 非干渉で示されたアクセシビリティ問題が含まれる場合は、ユーザーに事前に注意喚起が必要です。ACTルールは、ローカライズ可能な形式（複数言語を同時記載／翻訳対応可）が望ましいです。
4.1. ルール識別子
ACTルールは、ルールセット内で一意となる識別子を持たなければなりません。識別子は任意のテキスト、URL、データベース識別子等で構いません。
識別子に加え、ACTルールの各新バージョンには日付または番号によるバージョン管理が必須です。旧バージョンへの参照も必須です。ルールの更新でも識別子を変更してはなりません。大幅な変更の場合は新しい識別子で新規ルールを作成し、旧ルールを廃止するべきです。
4.2. ルール説明
ACTルールは、ルールの内容を簡潔に説明するわかりやすい記述を持たなければなりません。
ルールの記述形式に関係なく、説明には言語と段落の基本方向（右→左、左→右等）のメタデータ指定が必要です。ほとんどのマークアップ言語や文書フォーマットにはその指定方法が存在します。詳細は[string-meta]を参照ください。
4.3. ルールタイプ
ACTルールは、以下のいずれかのルールタイプを指定しなければなりません：
- アトミックルール
- コンポジットルール
詳細な定義はルールタイプセクションを参照してください。
4.4. アクセシビリティ要求マッピング
ACTルールが一つ以上のアクセシビリティ要求文書に対する適合性テスト用に設計されている場合は、そのルールは、一つでもアウトカムがfailedの場合に満たされないアクセシビリティ要求を全て記載しなければなりません。加えて、ルールアウトカムが不合格の場合に満たされない可能性のある要求も記載できます。アクセシビリティ要求には二つのタイプがあります：
マッピングされるそれぞれのアクセシビリティ要求には以下を含めなければなりません：
-
アクセシビリティ要求の名称、タイトル、識別子、または要約のいずれか
-
アクセシビリティ要求文書の名称
-
もし存在するならば、アクセシビリティ要求文書へのリンクや参照
-
もし存在するならば、アクセシビリティ要求に関連する適合レベル
-
その要求が適合要件か二次要件かどうか
4.4.1. アウトカムマッピング
各適合要件について、ACTルールはそのルールのアウトカムがそのテスト対象のアクセシビリティ要求の満たし方にどう関係するかを明示しなければなりません。4.4.1.1. 適合要件
ルールが特定のアクセシビリティ要件のテスト用に設計された場合、その要件は以下の両条件が満たされる時に適合要件としてマッピングされます：
-
不合格アウトカム：テスト対象のアウトカムが一つでも
failedの場合、そのアクセシビリティ要件はそのテスト対象で満たされない -
合格または非該当アウトカム：すべてのアウトカムが
passedまたはinapplicableの場合、その要件は満たすまたは追加テストが必要となる可能性があります。
アクセシビリティ要件を満たすかどうかの判定に使えるルールは満足テストと呼ばれます。
-
合格：すべてのアウトカムが
passedの場合、そのアクセシビリティ要件はそのテスト対象で満たすことになります。
注: Webコンテンツアクセシビリティガイドライン [WCAG22]
では、成功基準の評価はpassed、failed、inapplicableとならず、満たすか（そうでないか）となります。（WCAG 2.2 定義:
成功基準を満たす参照）成功基準を満たさない場合は、WCAG 2.2
適合要件1の通り、準拠する代替バージョンがあればページは適合可能です。
4.4.1.2. 二次要件
二次アクセシビリティ要件とは、ルールと相関があるものの、ルールがその要件のテストを目的としていない要件です。ルールのアウトカムがアクセシビリティ要件の結果に影響を及ぼしますが、ルール自体はその要件の適合性をテストするものではありません。こうした相関により、ルールの例の一部が二次アクセシビリティ要件を満たさないことがあります。
ルールがアクセシビリティ要件のテストに設計されていない場合や、ルールの不合格アウトカムがその要件に対して追加テストを必要とする場合、ルールはそのアクセシビリティ要件を二次としてマッピングできます。ACTルールが二次要件をマッピングする場合は、その要件がなぜ二次なのかを説明しなければなりません。
ルールがアクセシビリティ要件のテスト用に設計された場合、アクセシビリティサポートの違いは、その要件を二次アクセシビリティ要件にする理由にしてはなりません。
ルールで二次要件となる場合のシナリオ例:
シナリオ1：ルールが要件ほど厳しくない場合
ルールが最小限のアクセシビリティ要件のみをテストするように設計されており、より厳しい要件が存在する。ルールの不合格アウトカムは、より厳しいアクセシビリティ要件が満たされないことを判定でき、合格アウトカムは必ずしもその要件を満たしているとは限らない。ルールのアウトカムが合格の場合でも、アクセシビリティ要件が満たされない可能性がある。より厳しい要件が二次要件となる。
シナリオ2：ルールが要件より厳しい場合
ルールはアクセシビリティ要件を満たす特定の解決策についてテストするが、その要件はルールで含まれない他の解決策によっても満たされる場合がある。この場合、不合格アウトカムではアクセシビリティ要件が満たされないとは判定できず追加テストが必要となる。合格アウトカムでは要件が満たされると判定できる。アクセシビリティ要件は二次要件となる。
ルールがアクセシビリティ要件のテスト用に設計されており、より厳しくないアクセシビリティ要件が存在する場合、この場合はルールの合格アウトカムでその要件が満たされると判定でき、不合格アウトカムでは必ずしも満たされないとは判定できません。ルールのアウトカムが不合格でも要件が満たされる場合があります。より厳しくないアクセシビリティ要件も二次要件となります。
シナリオ3：ルールがアクセシビリティ要件の適合性テストを目的としないが、その要件に結果が影響する場合
ルールがあるアクセシビリティ要件のテスト用に設計されていて、状況によって他の要件が適用される場合があります。この場合、他のアクセシビリティ要件は、必ずしもルールに常に適用されるわけではないので、満たされたり満たされなかったりします。こうした要件も二次要件です。
4.4.2. WCAG以外のマッピング
ACTルールは、ハイパーテキストマークアップ言語 [HTML]など、W3Cアクセシビリティ標準以外のアクセシビリティ要件や、RGAA 3 2016のような手法のテストにも利用できます。ACTルールは、そのマッピング対象となるアクセシビリティ要件が、マッピング先のアクセシビリティ要件文書で適合のために必須かどうか明記しなければなりません。適合に必須でないアクセシビリティ要件の例としては、WCAGの十分なテクニックや、要件と任意「ベストプラクティス」が含まれる企業スタイルガイドなどがあります。必須と任意の区別を明確にしてください。
4.4.3. アクセシビリティ要件のないルール
ルールがアクセシビリティ要件にマッピングされていない場合、要件マッピングには、そのアクセシビリティ要件文書への適合に必須ではない旨の説明だけが記載されます。これはコンポジットルールで利用されるアトミックルールによく見られます。
failedなアウトカムがアクセシビリティ要件にマッピングできない場合は、要件マッピングにアクセシビリティ要件を含めてはなりません。背景セクションを使って、ルールが失敗テストでないものの関連するアクセシビリティ要件文書を列挙することは可能です。
4.4.4. 外部アクセシビリティ要件マッピング
このセクションは規範的でありません。
ルールは、多くの場合一つまたは少数のアクセシビリティ要件文書向けに設計されていますが、他のアクセシビリティ要件文書がそのACTルールにマッピングできる場合もあります。例として、WCAGに向けて作成されたルールは、多くの場合企業内部アクセシビリティポリシーにもマッピング可能です。この場合、外部アクセシビリティ要件マッピングを作成することができます。外部マッピングは、ACTルールの要件マッピングを補足し、別の要件文書へのマッピングを追加します。外部マッピングによって、単にマッピング内容を変更する目的のルールの重複掲載を防ぐことができます。
4.5. ルール入力
ACTルールでコンテンツを評価するには、ルールがテスト対象から情報を受け取る必要があります。これがルールの入力です。何の入力が必要かを明記することで、テスターがルールの利用に必要な機能を理解しやすくします。アトミックルールとコンポジットルールでは入力が異なります。
4.5.1. 入力アスペクト（アトミックルールのみ）
入力アスペクトとは、テスト対象の明確な部分です。コンテンツをエンドユーザーにレンダリングするには、通常複数の技術が必要で、これらの技術の全部または一部がアトミックルールの入力となります。例えば、サーバーとクライアント間のHTTP [http11]メッセージを直接操作するルールや、Webブラウザーが公開するDOM [DOM]ツリーを操作するルールなどがあります。
アトミックルールは、適用範囲や期待事項の入力として使うアスペクトを列挙しなければなりません。ルールは、HTTPメッセージやDOMツリーなど複数アスペクトを複合して同時に扱うこともできます。
入力アスペクトの中にはHTTPメッセージ、DOMツリー、CSSスタイリング [css-2018]など、正式仕様で定義が明確なものもあります。これらについては、共通入力アスペクトノート該当セクションへの参照を記載すれば十分です。定義が不明確な場合は、対象アスペクトの詳細説明か、明確な記述への参照を必須とします。
入力アスペクトを提供する方法は問いません。例えば、DOMツリーはHTTP経由でHTMLとして提供される場合も、EPUB出版物として複数ページにまとめられる場合も、JSXソースから推論される場合もあります。入力アスペクトがDOMツリーのみであれば、これを利用する全技術に対してルールは適用可能です。
4.5.2. 入力ルール（コンポジットルールのみ）
コンポジットルールは、 アウトカムをアトミックルールから受け取り、ロジックを当てはめて各テストターゲット毎に単一のアウトカムを判定します。該当コンポジットルールで用いる全アトミックルールの識別子と記述的タイトルは、期待事項セクションに列挙しなければなりません。入力ルールは、アトミックルール向けの入力アスペクト同様、コンポジットルールの入力を説明します。
4.6. 適用範囲
適用範囲は、テスト対象のどの部分がテストされるかを説明します。
4.6.1. アトミックルールの適用範囲
適用範囲セクションはアトミックルールの必須項目です。テスト対象のどの部分にルールが適用されるか、正確に説明しなければなりません。例えば、DOM[DOM]ツリー中の特定ノードや、HTML[HTML]文書で不正に閉じられたタグなどです。これらはテストターゲットとして知られています。適用範囲は、ルールで記載された入力アスペクトから得られる情報のみ使わなければなりません。他の情報は使えません。
適用範囲は曖昧であってはならないため、解釈が一通りしか成立しないようにしてください。例えば、見出しや画像という概念はタグ名や意味的役割、ページでの用途などに解釈できるため、曖昧です。一方「見出しタグがついた要素のみを対象」とすれば、曖昧さのない適用範囲となります。
さらに、適用範囲は客観的かつ平易な言葉で記述すべきです。客観的記述とは、その技術において不確実性なく判定できる記述です。HTML の客観的プロパティの例：タグ名、計算された役割、要素間距離等。
主観的プロパティの例：装飾、ナビゲーションメカニズム、録音済みなどは、文脈ごとに定義が異なり、人による判断を要します。主観性は誤解されやすいので、なるべく避けましょう。どうしても客観的に定義できない場合は、主観的な記述も許容されます。主観的な適用範囲を作る場合は、可能なら客観・主観部分を別々のルールに分割して、設計するルールが単一条件のみをテストするACTルールの要件を満たすようにしてください。例えば、セマンティックマークアップが正しく使われている見出しと使われていない見出しのテストルールを分けるなどです。
用語定義は用語集でまとめるか、該当セクションに直接記載できます。
4.6.1.1. 適用範囲タイプ指定（任意）
ルールには、適用範囲が客観的か主観的かを示す適用範囲タイプ識別子を任意で含めることができます。この識別子は、ルール読者および実装者が著者の意図を明確に把握し、読者・実装者による解釈の違いで生じる混乱を減らすことを目的としています。
4.6.2. コンポジットルールの適用範囲
コンポジットルールの適用範囲は、入力ルールで列挙された全ての適用範囲定義の和集合として定義されます。ルール著者は、コンポジットルールの適用範囲説明を省略できます。特に、平易な言葉で複合した適用範囲を表現するのが難しい場合には有用です。もしコンポジットルールに適用範囲を明記する場合は、必ず入力ルールの全ての適用範囲を統合したものでなければなりません。
コンポジットルールに含まれる入力ルールは異なる適用範囲を持つことがあります。そのため、複合ルールで該当する全てのテストターゲットが、必ずしもそれぞれの入力ルールによってテストされるとは限りません。
4.6.2.1. 適用範囲タイプ指定（任意）
コンポジットルールには、適用範囲が客観的か主観的かを示す適用範囲タイプ識別子を任意で含めることができます。コンポジットルールの適用範囲タイプは、いずれかの入力ルールが主観的適用範囲を含む場合は主観的、それ以外は客観的と判定されます。
4.7. 期待事項
ACTルールは一つ以上の期待事項を必ず含めなければなりません。期待事項は、テストターゲット（適用範囲から導出されたもの）に求められる条件を説明します。期待事項とは、テストターゲットについての断定です。テストターゲットが全ての期待事項を満たす場合は、passed（合格）となり、満たさない場合はfailed（不合格）となります。テストターゲットが無い場合は、そのルールのアウトカムはinapplicable（非該当）です。
各期待事項は明確かつ一意で、平易な言葉で記述しなければなりません。
4.7.1. アトミックルールの期待事項
アトミックルールの全ての期待事項は、テストターゲットについてpassedまたはfailedのいずれかのアウトカムを判定する論理を記述しなければなりません。期待事項は、入力アスペクト、適用範囲、同一ルール内の他の期待事項から得られる情報のみを利用しなければなりません。他の情報は利用できません。例えば「期待事項1が真なら・・・」のような記述は可能ですが、「ルールXYZが合格なら・・・」という記述はNGです。これにより、アトミックルールはカプセル化されます。
注: 画像要素のX％にテキスト代替が必要、といった複雑な集計ルールが必要となる場合もあります。この場合、ページ全体をテストターゲットにし、「テストターゲット（ページ）が全img要素のX％にテキスト代替を持つ」などと期待事項を書くことになります。こうした期待事項の集計ロジックは、ルール形式の複雑化を避けるため、実装側に委ねています。
4.7.2. コンポジットルールの期待事項
コンポジットルールの全ての期待事項は、入力ルールのアウトカムに基づいて各テストターゲットについてpassedまたはfailedのいずれかのアウトカムを判定する論理を記述しなければなりません。コンポジットルールの期待事項では、入力アスペクトの情報は利用してはなりません。全入力ルールが非該当となった場合、コンポジットルールもinapplicableとなります。
4.8. 背景
ACTルールの背景セクションには、前提（Assumptions）とアクセシビリティサポート（Accessibility Support）を必ず含めなければなりません。その他、ルールの開発に関する情報や、関連資料（Other ResourcesやRelated Rules）への参照も補足情報として含められます。何かしらの参照文献を含む場合は、その参考資料との関係も明示できます。例えば、WCAG 2.2成功基準向けの関連資料例としては、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コントラスト（最小）テストルールの場合、「HTMLテキストコンテンツ（CSSでスタイル可能）に限り適用、画像のテキストは除外」と記載できます。
アクセシビリティ要件の解釈に複数の妥当な道筋がある場合もあります。例えば、絵文字文字はWCAG 2.2において「テキスト」と「非テキストコンテンツ」どちらに該当するかすぐには明確にならない場合があります。どう解釈するかは、そのルールに必ず記載してください。
前提（Assumptions）セクションはACTルールに必須ですが、特に既知の前提・制約・例外が無い場合は空欄でも構いません。
4.8.2. アクセシビリティサポート
コンテンツは、補助技術やユーザーエージェントによる特定アクセシビリティ機能のサポートに依存して設計される場合があります。例として、WAI-ARIA 1.2の機能を用いる場合は、支援技術・ユーザーエージェントでその機能がサポートされていなければ動作しません。WCAGによるアクセシビリティサポートされたWeb技術の定義も参照ください。
ACTルールには、アクセシビリティサポートに関する既知の制約を必ず記載してください。
アクセシビリティサポートセクションは必須ですが、特に既知のアクセシビリティサポートの問題が無い場合は空欄でも構いません。
注: ウェブサイトのアクセシビリティ適合評価手法（WCAG-EM）は、テストシナリオ用のアクセシビリティサポート基準の定義に関するガイダンスを提供しており、ACTルールを利用する際に適切なルール選択に役立ちます。
4.8.3. 関連ルール（任意）
関連ルールとは、同じアクセシビリティ要件をテストする他のルールです。例として、コンポジットルールの場合、結果に貢献する2つのアトミックルールが関連ルールとなる場合があります。同様に、各アトミックルールも他のアトミックルールやコンポジットルールを関連ルールとしてリストできます。
4.8.4. その他リソース（任意）
ルールに資料を含める場合は、その参考資料との関係性も明示できます。例えば、WCAG 2.2成功基準向けの関連資料例としては、Webコンテンツアクセシビリティガイドライン [WCAG22] の WCAG 2.2の解説文書、WCAG 2.2テクニック、WAI-ARIA 1.2、CSS（[css-2018]）、HTML（[HTML]）の仕様などがあります。
4.9. 例
例は、ACTルール実装の妥当性検証用のコンテンツ（抜粋）です。各ルールはpassed（合格）、failed（不合格）、inapplicable（非該当）アウトカム用の1つ以上の例を必ず持たなければなりません。各例は、ルール毎の入力アスペクトの抜粋と、そのルールの期待されるアウトカムという二つの情報で構成されます。例は、ルールのアウトカムがpassed・failed・inapplicableとなるシナリオ解説として読者理解促進の役割、およびアクセシビリティテストツールや手法利用者による実装妥当性の検証用機能の両方の役割を果たします。
ACTルールのpassedおよびinapplicableの各例は、ルールの適合要件を全て満たすことが必須です。failedの各例については、全ての適合要件が不適合となることが必須です。コンポジットルールの場合は、各入力ルールの全ての例も同一の要件に対して同じ条件を満たす必要があります。
4.10. ルールのバージョン
ACTルールのバージョンを記録しておくことは、テスト結果の変化がテスト用ルール側の変更によるものか、コンテンツ自体の変化によるものかを利用者が理解するために重要です。過去バージョンのACTルールは、ルール文書本体か、そこから参照可能な形ですべて記録しなければなりません。
このセクションは以前「変更履歴（Change Log）」という名称でした。どちらの名称でも構いません。
4.11. ACTルール形式バージョン
ACTルールは、特定のバージョンのACTルール形式に基づいて記述されます。各ACTルールは、どのバージョンのACTルール形式用かを必ず明示してください。ACTルール形式は完全には後方互換性がないため、重要です。
4.12. 用語集
ACTルールには必ず用語集セクションが必要です。用語集には、アウトカム定義、および適用範囲や期待事項セクションで使用する全定義を必ず含めます。定義の変更はルール自体の変更となるため、ルールとは独立して管理はできません。用語集をルール間で共有する場合は、定義変更時に利用ルール全てのバージョン更新が必須です。
注: ルールでは、ルール内の用語集だけでなく外部文書（WCAG 2.2やHTML 5等）の用語集も利用できます。外部用語集の内容がルール本体変更無しに更新されうる場合、用語集のバージョンも明示してください。例えばHTML 5標準は定期的に更新されるため、ルール策定時点の日付をリンクと共に提示するのが有効です。
4.13. 課題リスト（任意）
ACTルールは、既知の課題リストやその参照を含めることができます。課題リストは、ACTルールのアウトカムが不合格であるべきところ合格・非該当など、またはその逆というケース等を記録します。これらが起こる理由は様々です。詳細はルールの正確性を参照してください。
課題リストには2つの目的があります。ACTルール利用者への説明（なぜ不正確な結果となったのかの理解と、その判定への信頼）と、ルール設計者への今後のアップデート計画立案です。新バージョン発行時には、解決済み課題を変更履歴に移動させます。
4.14. 実装（任意）
ACTルールは、実装のリストを含むことができ、各実装には、ルールと一貫性または部分的一貫性を持つ一つ以上のチェックがあります。実装とは、チェックを用いて、アウトカム（アクセシビリティ要件満足判定）を算出するアクセシビリティテスト手法やテストツールです。チェックは完全自動、完全手動、あるいは両方の組み合わせでも構いません。
チェックは、ACTルールと一対一で対応する必要はありません。一つのチェックが複数ACTルールに一貫性を持つ場合や、複数チェックのセットで一つのACTルールに一貫性を持つ場合があります。
各実装には、以下のような情報が含まれる可能性があります：
4.14.1. 一貫性
一貫性は、チェックがACTルールの意図とどれだけ一致しているかを表します。一貫性の記載をACTルールに含める際は、本セクションで定義した方法で評価しなければなりません。ACTルールの一貫性のあるチェックとは、ルールで記載された一部または全部の非適合事例を識別できるものです。チェックが一貫していると言えるのは、以下がすべて成立する場合です:
-
真陽性 ：例と矛盾がないこと：
-
passed・inapplicable例がfailedとして報告されないこと -
failed例が、passedまたはinapplicableとして報告されないこと
-
-
網羅性：カバー漏れがないこと：
-
いずれのチェックのアウトカムにも
untestedが含まれないこと -
failed例のうち少なくとも1つはfailedとして報告されること
-
-
ルールマッピング：アクセシビリティ要件報告が一貫していること：
-
ルールが対象とする全てのアクセシビリティ要件は、適合要件または二次要件いずれかであること（ただし、ルールで明記されていないアクセシビリティ要件文書は除く）
一つのチェックが、1つの例に複数アウトカムを報告する場合は、次に示す優先順位順に最初に現れるアウトカムを一貫性判定に使います：
-
failed -
untested -
cantTell -
passed -
inapplicable
4.14.2. 部分的一貫性
一つのチェックが一貫しているとまでは言えない場合でも、真陽性の条件が成立し、そのチェックがそのルール例全てに対しcantTellやuntestedばかりを報告していない場合は、部分的一貫性とみなします。
4.14.3. 複数チェックによる一貫性
実装には、単一のACTルールの一部のみをテストするチェックが含まれることがあります。これらのチェックがACTルールの全ての部分をカバーしている場合、これらを組み合わせることで一貫性が得られます。チェックのセットの一貫性は、全ての部分的一貫性のチェックをまとめて1つのチェックとして扱うことで判定できます。
チェックのセットがACTルールに対して一貫性を持つには、一貫したチェックのすべての要件を満たす必要があります。このチェックセットのアウトカムは、ACTルールに部分的一貫性のあるすべてのチェックのアウトカムリストです。このチェックセットのアクセシビリティ要件は、ACTルールに部分的一貫性のあるチェックの要件全体のリストです。
4.15. 謝辞（任意）
ACTルールには謝辞を含めても構いません。謝辞には次が含まれます（制限されません）：
-
ルール著者一覧
-
ルールのレビュー/貢献者一覧
-
資金提供またはその他の支援
5. ルールの正確性
このセクションは規範的でありません。
例によってACTルールの実装が正しく行われているか確認できますが、実装が常に正しい結果を出すことを保証するものではありません。ACTルール作成時には、ほぼ確実に例外ケースの見落としが発生します。技術は進歩し続け、コンテンツ制作者は新しい予期しない使い方を常に生み出します。正確性を損なう要因の例：
-
前提が実際には正しくなかった
-
技術が予想外かつ複雑な方法で使われた
-
技術に変更があった、または技術的側面に見落としがあった
-
アクセシビリティ要件の解釈が正しくなかった
誤った結果につながる不正確性には2種類あります。実装での不正確性は例で対処できますが、ACTルール自体の不正確性には対応できません。ルール自体の不正確性は、著者が特定の例外ケースに気づいていないことが原因です。
テスト結果が誤ってアクセシビリティ要件の非適合を示した場合は「偽陽性」と呼ばれ、逆に誤って適合を示した場合は「偽陰性」です。偽陽性・偽陰性の割合は、アクセシビリティ監査の結果との比較で計算できます：
-
偽陽性:これは、ルールによって
failed（不合格）となったが、テストターゲットがアクセシビリティ要件を実際は満たしている場合のパーセンテージ。 -
偽陰性:これは、ルールによって
passed（合格）となったが、テストターゲットがアクセシビリティ要件を実際は満たしていない場合のパーセンテージ。
ACTルールでは偽陽性・偽陰性が常に発生する可能性があるため、継続的なメンテナンスが必要になる場合があります。ACTルールのメンテナンス方法の設計はACTルール形式の範囲外ですが、ルール著者は自身のルールの維持管理プロセスを検討することが推奨されます。
6. 調和
このセクションは規範的でありません。
ACTルール形式は調和を促進することを目的としていますが、既存のACTルールと一貫性のないルール記述を制限する直接的な要件はありません。また、ACTルールに一定数の実装があること、一定の正確度があることなどを義務付ける要件もありません。これにより、ルールセットごとに品質要件を柔軟に設定でき、長期的な発展が可能になります。
調和は、複数のルール実装者がACTルールの妥当性を集団で認めることによって実現します。例えば、アクセシビリティテストツールベンダーのコミュニティグループが、特定のACTルールセットで調和していることを宣言することができます。このようなグループは、ルールの受理基準や、ACTルール形式を超えた品質要件を独自に設定できます。
こうしたプロセス例として、WCAG ACTレビュープロセスがあります。
7. プライバシー配慮事項
本仕様は、Webコンテンツアクセシビリティガイドラインに適合するためのアクセシビリティ適合性テスト（ACT）ルールを提供しますが、利用者情報へのアクセスや、利用者情報をユーザーエージェント、支援技術に直接公開することを意図したものではありません。
8. セキュリティ配慮事項
本仕様は、プロトコル・ドメイン・ポートが基盤プラットフォーム（ブラウザやOS等）と直接通信する手段を提供しません。また、デバイスのセンサーへのアクセスも認めません。仕様は新しいスクリプト実行・読み込みの仕組みも提供しません。本グループが把握している他のセキュリティ課題はありません。
9. 定義
- アクセシビリティ要件
-
アクセシビリティ要件は、障害のある人々がICT製品へアクセスしやすくすることを目的とした要件です。ACTルールのマッピング文脈では、「必須」と「推奨」の要件が存在します。必須の場合は、標準・契約・ポリシー・法令の適合性のために満たす必要があります。推奨の場合は、満たすことが望ましいですが、満たさない場合でも非適合・違反とみなされません。
アクセシビリティ要件の典型例はWCAGの成功基準です。その他、W3Cの標準などにもアクセシビリティ推奨事項があり、WAI-ARIAやHTML、企業ポリシー、地域標準や法制度にもアクセシビリティ要件が含まれています。
- アクセシビリティ要件文書
-
アクセシビリティ要件（accessibility requirements）を含む標準・契約・ポリシー・法令等の文書。例：WCAG 2.2、WAI-ARIA 1.2、HTML 5.2、EPUB Accessibility 1.0、BBC HTMLアクセシビリティ標準v2.0
- チェック
-
ウェブページやその他のテスト対象のアクセシビリティ評価時に、1つ以上のアウトカムを導出する手順。手順内容は、手動テスト手順の詳細記述、完全自動テスト、手動と自動の組み合わせ等。
- 実装
-
複数のチェックで、アクセシビリティ要件の（非）適合判定を可能にするアクセシビリティテスト手法／ツール。
- アウトカム
-
ACTルールをテスト対象またはその構成テストターゲットに適用評価した結果。アウトカムは以下の5タイプのいずれか：
- 非該当:テスト対象に適用範囲に該当する部分がない
- 合格:テストターゲットが全期待事項を満たしている
- 不合格:テストターゲットが全期待事項を満たしていない
- 判定不能:適用範囲か期待事項全てをテスターが完全には判断できない
- 未評価:テスト対象がそのルールで評価されていない
注: ルールは各テストターゲットごとに
passedまたはfailedのいずれかのアウトカムを持ちます。テスターがテストターゲットの判定を行う際に、ルール全体の判定不能な場合はcantTellで報告可能です（例：適用範囲判定が自動でも期待事項判定が手動の場合）。テストターゲットがない場合はルールが
inapplicableアウトカムを持ちます。テストターゲット有無の判定ができない場合はcantTellアウトカムとなります。また、評価が全く実施されていない場合はuntestedアウトカムとなります。したがって各テスト対象は常に1つ以上のアウトカムを持ちます。ACTルールでのアウトカム表現は、EARLのoutcome property（[EARL10-Schema]）で表現できます。
- テスト対象
-
ACTルールで評価可能なリソースまたはリソース群。
注: [EARL10-Schema]利用者はsubject propertyでテスト対象を表現できます。
- テストターゲット
-
注: [EARL10-Schema]利用者はpointer propertyでテストターゲットを表現できます。
付録1: ACTルール結果のJSON-LDおよびEARLによる表現
このセクションは規範的でありません。
このセクションでは、EARLとJSON-LDを使ったACTルール実施結果の表現例を示します。詳細は評価・報告言語(EARL)および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、Shunguo Yan、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プログラム（Grant Agreement 780057）で共同資金提供されています。本出版物の内容は、欧州委員会（EC）や欧州連合（EU）加盟国の見解や方針を必ずしも反映するものではありません。
付録3: 変更履歴
このセクションは規範的でありません。
ACTルール形式1.1初回公開草案以降の変更点
- 2 対象範囲 ACTルール形式1.1が1.0と完全な後方互換性を持たないことの明確化
- 4.9 例 入力ルールのテストケースが適合要件と一致する必要を明確化
- 全体 テストケースの名称を例に変更
- 全体 例はBikeshedの自動番号付けのみを使用
- 付録1: ACTルール結果のJSON-LD・EARLによる表現 このセクションの例のマークアップを正しく表示するよう追加
- 4.2. ルール説明 テキストに言語と書字方向のメタデータ指定があるという前提を追加
- 4. ACTルール構造 ACTルールがローカライズ可能であることを強調
- 4.1. ルール識別子 ルール識別子の一意性判断の明確化
- 4.4.1.2. 二次要件 二次要件説明が背景セクションで必須ではなくなった
- 9. 定義 cantTellおよびUntestedの定義更新
- 4.12. 用語集 内部・外部用語集の両方を許容
- 7. プライバシー配慮事項 追加
- 8. セキュリティ配慮事項 追加
ACTルール形式1.0以降の変更点
- 4. ルール構造 アクセシビリティサポートと前提セクションが背景のサブセクションとなった
- 4.4. アクセシビリティ要件のマッピング アクセシビリティ要件が「適合要件」と「二次要件」に分類されるようになった
- 4.6 適用範囲 主観的適用範囲表現が許可されるようになった。客観的および平易な言葉での要件は必須ではなく推奨に変更
- 4.8. 背景 新たに任意の関連ルール・その他リソースのサブセクションを追加
- 4.10. 変更履歴 変更履歴セクションが「ルールのバージョン」に名称変更
- 4.11 ACTルール形式バージョン ACTルール形式のバージョンとの互換性記載要件が追加
- 4.14. 実装 ACTルールとの一貫性判定方法を含む新セクション追加
- 7. 定義 アウトカム定義がcantTellとuntestedを含むよう更新
- 全体 W3C仕様書のリンクを最新勧告版へ更新
前回公開版からの全変更はEditor’s DraftからRules Format 1.0勧告へのdiffリンクで閲覧できます。