Copyright © 2022-2026 World Wide Web Consortium. W3C® liability, trademark and document use rules apply.
この文書では、デジタル製品が Web Content Accessibility Guidelines (WCAG) 2 にどの程度適合しているかを評価するための、段階的なプロセスを備えた方法論について説明します。
この文書は、評価範囲を定義し、対象製品を調査し、製品から代表的な サンプルセットを選択し、選択したサンプルセットを評価し、評価結果を報告するための、 技術に依存しないガイダンスを提供します。この手順は、自己評価や第三者評価を含む、 さまざまな評価状況での使用に適しています。
この文書では、機能固有の手順を定義しません。これらは WCAG 達成基準および補足文書で扱われているためです。また、 WCAG 2 の追加要件を定義するものでも、いかなる方法でもそれらを置き換えたり優先したりするものでもありません。
この節では、公開時点におけるこの 文書の位置付けについて説明します。現在の W3C 公開文書の一覧およびこの技術報告書の最新版は、 W3C 標準および草案 インデックスで確認できます。
この文書は、Web Content Accessibility Guidelines (WCAG) Working Group（現在は Accessibility Guidelines (AG) Working Group に改称）と Evaluation and Repair Tools (ERT) Working Group の共同タスクフォースである WCAG 2.0 Evaluation Methodology (Eval) Task Force によって策定された WCAG-EM 1.0 を基礎としています。 この文書は、Web Content Accessibility Guidelines (WCAG) 2 に準拠した評価に関する参考ガイダンスを提供します。
この文書は、Accessibility Guidelines Working Group によって、 ノート トラックを使用した グループノートとして公開されました。
このグループノートは、 Accessibility Guidelines Working Group によって承認されていますが、 W3C 自体またはその メンバーによって承認されているものではありません。
W3C 特許 ポリシーは、 この文書に対していかなるライセンス要件または確約も 課しません。
この文書は、 2025年8月18日付 W3C プロセス文書に準拠します。
この文書では、デジタル製品の代表的なサンプルが Web Content Accessibility Guidelines (WCAG) 2 に適合しているかどうかを包括的に評価するためのプロセスについて説明します。
デジタル製品のアクセシビリティ評価は、製品の公開、調達、再設計の前や、製品のアクセシビリティ性能を 経時的に定期監視する場合など、多くの状況で必要になることがあります。
評価には、次のようないくつかの要因が影響する可能性があります。
この文書では、これらの要因を考慮し、評価者のためのいくつかの考慮事項を示します。また、 アクセシビリティ評価の共通フレームワークをロードマップとして提供し、評価者が 適切な実践を適用し、よくある誤りを回避し、より比較可能な結果を得られるよう支援します。
この文書は、製品開発のすべての段階を通じて品質保証を行う必要性に代わるものではありません。 また、規範的な WCAG 2 標準で定義されている要件をいかなる形でも追加または変更するものではありません。さらに、ウェブコンテンツの機能ごとの評価手順を提供するものでもありません。この 方法論は、WCAG 2.2 の達成方法集など、WCAG 2 達成基準を満たすための達成方法と組み合わせて使用できますが、 この達成方法集またはその他の特定の達成方法一式を使用することを要求するものではありません。
この方法論は、デジタル製品の代表的なサンプルの WCAG 2 への適合性を評価するために、共通のアプローチに従うことを希望するすべての人を対象としています。これには次の人々が含まれます。
WCAG 2.2 は、個々のウェブページ（および場合によってはウェブページの集合）に対する 適合要件 を定義していますが、ウェブサイト全体を評価する方法については説明していません。また、個々の ウェブページ、複数ページのフォームなどの一連のウェブページ、およびウェブサイトなどの関連する複数のウェブページを対象とする、任意の 適合宣言を作成する方法も定義しています。これは、適合宣言の範囲に含まれるすべてのウェブページが それぞれ評価されているか、またはそれぞれがすべての適合要件を満たすことを保証するプロセスで作成されている場合に適用されます。
選択した一部のウェブページおよび機能のみの評価に基づいて、ウェブサイト全体について WCAG 2 適合宣言を行うことはできません。これは、それらのウェブサイトに 未特定の適合エラーが存在する可能性が常にあるためです。実際には、この 評価方法論を使用する大半の場合、デジタル製品から サンプルのみが評価対象として選択されます。したがって、 大半の状況では、この方法論のみを使用しても WCAG 2 適合宣言を行えるようにはなりません。この 方法論の使用結果に関するステートメントを作成するためのガイダンスは、ステップ 5.3: 評価ステートメントを提供する（任意）に示されています。
この方法論は、WCAG 2 を使用してデジタル製品を詳細に評価するために使用します。デジタル製品 全体を評価する前に、通常は対象製品のさまざまな サンプルについて予備評価を行い、 明らかなアクセシビリティ障壁を特定し、デジタル製品のアクセシビリティを 全体的に理解することが適切です。
簡易チェック — ウェブ アクセシビリティの初期レビューでは、この 方法論を補完する予備評価のためのアプローチについて説明しています。
この方法論の利用者は、WCAG 2 を使用したコンテンツの評価方法、アクセシブルな設計、支援技術、およびさまざまな障害のある人がデジタル 製品をどのように使用するかについて、十分に理解していることが前提となります。
これには、次の事項の理解が含まれます。
特に、この方法論の利用者は、背景資料に記載されているすべてのリソースを 十分に熟知していることが前提となります。
この方法論は、前の セクション（必要な専門知識）で説明した技能を持つ個人の評価者、または集合的な 専門知識を持つ評価者チームによって実施できます。
1 人の評価者だけでは必要な専門知識をすべて備えていない場合、異なる評価者の専門知識を組み合わせることが 必要または有益なことがあります。
専門知識を組み合わせた ウェブアクセシビリティ評価では、評価チームの専門知識を組み合わせて使用する方法について、さらに詳しいガイダンスを提供しています。
障害のある人（経験豊富な評価者または評価チームの一員ではない人）に参加してもらうことで、 専門家による評価だけでは容易に発見できない追加のアクセシビリティ障壁を特定できる場合があります。 この方法論を使用するうえで必須ではありませんが、評価プロセス中に幅広い能力を持つ実際の 人々に参加してもらうことを評価者に強く推奨します。
ウェブアクセシビリティ 評価へのユーザーの参加では、ウェブアクセシビリティ評価にユーザーを参加させる方法について、さらに詳しいガイダンスを提供しています。
この方法論は、特定のアクセシビリティ評価ツール、ウェブブラウザー、およびその他の ソフトウェアツールに依存しません。ほとんどのアクセシビリティ検査は完全には自動化できませんが、評価ツールは 評価プロセス中に評価者を大きく支援し、より効果的な 評価に貢献できます。例えば、一部のアクセシビリティ評価ツールでは、デジタル製品全体を走査し、 手動評価に関連する サンプルを特定するのに役立ちます。ツールは、アクセシビリティ検査の手動 （人による）評価中にも役立ちます。
ウェブアクセシビリティ評価 ツールの選択では、ツールの使用に関するさらに詳しいガイダンスを提供しています。
この方法論は、ウェブサイトなどの、完全で自己完結した デジタル製品を評価するために設計されています。 ステップ 1.1で、評価者は正確な評価範囲を定義します。
製品全体の包含が不可欠です。これは、特定の部分を除外せず、デジタル製品のすべてのビュー、状態、および 機能を含むように範囲を定義することを意味します。デジタル製品の 特定の部分を範囲から除外すると、ページ全体および 完全なプロセスに関する WCAG 2.2 適合要件と矛盾する可能性が高く、あるいは評価 結果を歪める可能性があります。
製品包含の例として、次の銀行ウェブサイトが考えられます。このサイトには、 個人向け銀行業務、法人向け銀行業務、インターネットバンキング、サービスおよび問い合わせの個別の領域があります。また、法的通知やサイトマップなど、すべてのページからリンクされる 共通ビューもあります。
評価対象が銀行ウェブサイト全体である場合、図示されているすべての領域が 評価範囲に含まれます。これには、申込フォーム、認証、および インターネットバンキングなどのコンテンツが含まれます。また、サイト内で使用される第三者コンテンツも含まれます。
評価対象が「法人向け銀行業務」のような特定のウェブサイト領域のみである場合、その領域のすべての 部分が評価範囲に含まれます。この例では、評価範囲には 支払い、住宅ローン、ローン、貯蓄に加え、共通ビュー、法的 通知、およびサイトマップが含まれます。
この方法論は、幅広い種類のデジタル製品に適用できます。以下に、 特定の状況に関する考慮事項を示します。
ウェブサイト
ウェブアプリケーション
ネイティブ、ハイブリッド、および
クロスプラットフォームアプリケーション
キオスク、
セルフサービス端末、およびセットトップ
ボックスのインターフェイス
文書この方法論は、さまざまな状況および文脈に適用できます。次の考慮事項は、 評価に関する特定の状況および文脈に適用されます。
デジタル製品に大きな変更が加えられていない限り、通常、 選択したサンプルの規模またはサンプリングに使用したアプローチを変更する必要はありません。新しい サンプルセットで置き換える サンプルの数は、 通常、初期サンプルセットの約半分ですが、サンプルの大半が WCAG 2 に適合している場合は、 この割合を増やすことができます。
評価手順には 5 つのステップがあります。デジタル 製品の種類および評価の目的によっては、順序が異なる場合があります。
ステップは次のとおりです。
評価者は 1 つのステップから次のステップへ進むことができ、プロセス中に新しい情報が 明らかになった場合には、前の任意のステップに戻ることができます。
方法論要件 1: 方法論要件 1.1、方法論要件 1.2、および 方法論要件 1.3に従って 評価範囲を定義し、任意で 方法論要件 1.4にも従います。
通常、このステップでは、期待を一致させるために評価依頼者（製品所有者である場合も、そうでない場合もあります）が関与し、 製品の初期調査を行います。
方法論要件 1.1: 適用範囲に従って対象 デジタル製品を定義し、各 ビューが 評価範囲内にあるかどうかを明確に判断できるようにします。
適用 範囲の考慮事項を踏まえて対象製品を定義します。例えば、次のようにします。
このステップでは、範囲に含まれるビューについて疑念が生じないよう、 明確かつ曖昧さのない定義を行うことが重要です。可能であれば、正規表現や ウェブアドレス（URI）の一覧などの形式化を使用することを推奨します。
また、対象製品の識別を支援するために、その特定の側面を文書化することも重要です。これには次のものが含まれます。
方法論要件 1.2: 評価の対象とする WCAG 2 適合レベル（A、AA、または AAA）を 選択します。
WCAG 2 レベル AA は、一般に受け入れられ、推奨される目標です。
多くの場合、デジタル製品の適合目標を超えて評価することが有用です。例えば、 製品がより高い適合レベルの個別要件を満たしている場合があります。 この情報を文書化することで、将来の改善をより効果的に計画できます。
方法論要件 1.3: デジタル製品で提供される機能が アクセシビリティサポートされる対象となる ウェブブラウザー、支援技術、およびその他の ユーザーエージェントを定義します。
特に新しい技術では、メディアプレーヤーの「字幕を表示」機能など、デジタル製品で提供されるすべてのアクセシビリティ 機能が、オペレーティングシステム、ウェブブラウザー、支援技術、および その他のユーザーエージェントの考えられるすべての組み合わせでサポートされることを保証できるとは限りません。WCAG 2 は、 どの機能と技術の組み合わせをサポートしなければならないかを事前に定義していません。これは、製品の言語、 コンテンツの作成に使用される技術、および現在利用可能なユーザーエージェントなど、 製品の特定の状況に依存するためです。アクセシビリティ サポートを理解するでは、WCAG 2 のアクセシビリティ サポートという概念に関するさらに詳しいガイダンスを提供しています。
このステップで評価者は、製品が動作することを期待される オペレーティングシステム、ウェブブラウザー、支援技術、およびその他のアプリケーション／ユーザーエージェントの組み合わせの最小一式を決定します。この一式は、上記でリンクした WCAG 2 のアクセシビリティサポートに関するガイダンスと一致する必要があります。 このステップは、対象とするアクセシビリティサポートのレベルについて共通の 認識を確保するため、評価依頼者と協議して実施します。製品所有者および製品 開発者が、その製品でサポートするよう設計された組み合わせの一覧を持っている場合もあり、 それをこのステップの出発点とすることができます。評価の目的によっては、その一覧を 更新する必要があります。例えば、製品が より新しいブラウザーでどの程度動作するかを評価するため、一覧の更新が必要になる場合があります。
この基準の初期定義は、評価者が後の時点で 追加のオペレーティングシステム、ウェブブラウザー、支援技術、およびその他のユーザーエージェントを使用することを制限しません。例えば、評価者は、 評価プロセスのこの初期段階で特定されなかったコンテンツを評価するため、追加の組み合わせを使用する場合があります。この場合、使用した追加ツールによって 基準が拡張されます。
イントラネット製品など、利用者と製品へのアクセスに使用するコンピューターの両方が既知である 閉鎖ネットワーク内の一部の製品では、この基準を、 その閉鎖ネットワーク内で使用されるオペレーティングシステム、アプリケーション、ウェブブラウザー、および支援技術に限定できます。ただし、ほとんどの場合、この基準は、該当する特定の地理的 地域および言語コミュニティにおいて、障害のある人が使用する現在のユーザーエージェントの大半を対象とするよう、 より広く設定することが理想的です。
方法論要件 1.4: 評価者と 評価依頼者が合意した 追加の評価要件を定義します（任意）。
評価依頼者は、対象製品の WCAG 2 への適合度を 評価するために必要な情報を超える、追加情報に関心を持つ場合があります。例えば、評価 依頼者は次の事項に関心を持つ場合があります。
評価者と合意したこのような追加の評価要件は、 早期に明確化して文書化する必要があります。また、結果として作成される報告書にも反映する必要があります。例えば、 サンプルセットの選択方法を明確化するため、後で追加要件が必要になることがあります。
方法論要件 2: 方法論要件 2.1、方法論要件 2.2、方法論要件 2.3、方法論要件 2.4、および 方法論要件 2.5に従って、評価するデジタル 製品を調査します。
このステップで評価者は、評価対象製品を調査し、その製品およびその使用方法、目的、機能について 初期理解を深めます。この多くは、評価者、特に開発チーム外部の評価者には 直ちには明らかになりません。場合によっては、製品を実現するために使用されているすべての機能、ビューの種類、および 技術を網羅的に特定して一覧化することもできません。製品所有者および製品開発者が関与することで、 評価者はより効果的に調査を行えます。
このステップで初期の概略的な検査を行うことで、 後の詳細評価に関連するビューを特定できます。例えば、評価者は、 色のコントラスト、文書構造、または一貫したナビゲーションが不足しているように見えるビューを特定し、後で 詳細に評価するために記録できます。
このステップを実施するには、評価者が製品の関連するすべての 部分へアクセスできることが不可欠です。例えば、アカウントを作成し、 製品の設定が代表的なものになるようにする必要がある場合があります。製品がデータを表示する場合、 評価を開始する前に現実的なデータを事前入力する必要がある場合があります。
方法論要件 2.1: 対象製品の 共通ビューを特定します。
対象製品を調査し、ビューの特定の状態でもあり得る共通ビューを特定します。 通常、これらは対象製品の主要な入口（ウェブサイトのホーム ページやアプリの開始画面など）から直接リンクされ、多くの場合、他のビューのヘッダー、ナビゲーション、および フッターのセクションからもリンクされています。このステップの成果は、対象製品に含まれるすべての共通ページまたはビューの一覧です。
方法論要件 2.2: 対象製品の 主要機能の 初期一覧を特定します。
対象製品を調査し、その主要機能を特定します。一部の機能は 容易に特定できますが、他の機能はより慎重な調査が必要です。例えば、オンラインショップで製品を購入する機能は、 販売者がそのショップを通じて製品を販売するために提供される機能よりも特定しやすい場合があります。このステップの成果は、利用者が製品上で実行できる機能の 一覧です。この一覧は、評価用の代表的なサンプルを選択するため、 後続のステップで使用されます。
このステップの目的は、製品のすべての機能を網羅的に特定することではなく、 対象製品の目的および目標に不可欠な機能を決定することです。これは、 後のサンプル選択とその評価に役立ちます。その他の機能も、 別の選択方法を通じて評価に含まれます。
方法論要件 2.3: サンプルの 種別を特定します。
スタイル、レイアウト、構造、および機能が異なるサンプルでは、多くの場合、アクセシビリティのサポートも 異なります。それらは、異なるテンプレートやスクリプトによって生成されたり、異なる 人々によって作成されたりすることがあります。特定の製品利用者および状況によっては、 異なる外観や動作になり、異なるコンテンツを含む場合があります。
このステップで評価者は、対象製品を調査して、異なる サンプルの種別を特定します。このステップの成果は、 特定のサンプルそのものではなく、特定されたコンテンツ種別の説明の一覧です。この一覧は、 評価用の代表的なサンプルセットを選択するため、後続のステップで使用されます。
評価者は、さまざまな種類のコンテンツが評価で十分に 表現されるように、異なるサンプル種別や以前の評価について評価依頼者に尋ねることを推奨します。
方法論要件 2.4: 製品を提供するために 依存する技術を特定します。
このステップでは、適合のために依存する技術を特定します。これには、 HTML、CSS、JavaScript、SVG、WAI-ARIA、PDF、EPUB などの技術が含まれる場合があります。このステップの成果は、WCAG 2 に従って依存する技術の 一覧です。この一覧は、評価用の 代表的なサンプルを選択するため、後続のステップで使用されます。
適合のために依存するその他のシステムも特定することを推奨します。例えば、次のものです。
例えば、バージョン番号 および設定情報を含めるなど、可能な限り詳細に記録することを推奨します。これにより、評価をより効率的にできます。
方法論要件 2.5: 障害のある人およびデジタル 製品のアクセシビリティに関連する その他のサンプルを特定します。
一部のデジタル製品には、障害のある人および デジタル製品のアクセシビリティに特に関連するサンプルが含まれます。このステップの成果は、ステップ 2.1: デジタル製品の共通ビューを特定するの一環として まだ特定されていない場合、そのようなサンプルの一覧です。
方法論要件 3: 方法論要件 3.1、方法論要件 3.2、および 方法論 要件 3.3に従って、デジタル製品から 代表的なサンプルセットを選択します。
評価対象製品を代表するサンプルセットを選択します。これにより、 評価結果が、合理的な確信をもってデジタル製品のアクセシビリティ性能を反映するようになります。
実行可能であれば、デジタル製品全体を評価することを推奨します。その場合、 サンプリング手順を省略できます。
サンプリング手順を省略し、 代わりにデジタル製品全体を評価することが合理的な、その他の特定のケースもあります。このようなケースには、デジタル製品が次の条件を満たす場合が含まれます。
サンプリング手順を省略する場合、この評価プロセスの 残りのステップでは、製品全体を「選択したサンプルセット」として使用します。
デジタル製品を評価するために必要なサンプルセットの実際の規模は、次の事項を含む多くの 要因に依存します。
このステップで行う選択は、まず ステップ 2: 対象デジタル製品を調査するで行った調査に基づきます。また、評価者が対象製品の特定の実装側面についてさらに把握するにつれて、 後続の ステップ 4: 選択したサンプルセットを評価するでも継続的に 選択を改善します。
方法論要件 3.1: 特定されたすべての (1) 共通ビュー、(2) 主要機能、(3) サンプル種別、(4) 依存する技術、および (5) その他の関連サンプルを反映するサンプルを選択します。
次のものを含むサンプルセットを選択します。
個々のサンプルは、上記に示した各基準のうち、複数を反映する場合があります。例えば、 1 つのサンプルが、特定の設計レイアウト、機能、および 使用される技術を代表する場合があります。このステップの目的は、デジタル製品で使用される異なる種類の サンプル、機能、および技術を代表させることです。これらの代表例を慎重に選択することで、 デジタル製品全体を適切に代表しながら、 必要なサンプルセットの規模を大幅に削減できます。必要な サンプル事例の数は、前のセクション「サンプルセットの規模に影響する要因」で説明したデジタル製品の特定の側面に依存します。
方法論要件 3.2: 無作為な サンプルセットを選択し、評価対象に含めます。
無作為に選択したサンプルセットは、前のステップで選択した構造化サンプルセットが、 ウェブサイトで提供されるコンテンツを十分に代表していることを確認する指標として機能します。 両方の選択アプローチによる評価結果が相関する場合、評価結果全体に対する信頼度を高めるための重要なステップとなります。
無作為に選択するサンプルの数は、前のステップで選択した構造化サンプルセットの 10% です。例えば、デジタル製品について選択した構造化サンプルセットが 80 サンプルになった場合、無作為サンプルセットの規模は 8 サンプルです（これらは追加されるため、その場合、 合計で 88 サンプルになります）。
この選択を実行するには、前のステップで選択した構造化サンプルセットに まだ含まれていない一意のサンプルを、対象デジタル製品から無作為に選択します。 製品の種類および評価者がアクセスできる範囲に応じて、この選択には異なる 技法を使用する必要があります。評価者は次のことを行えます。
無作為に選択したサンプルは、ステップ 4.3: 構造化サンプルセットと無作為サンプルセットを比較するで 残りの構造化サンプルセットと比較する必要があるため、文書化します。
無作為サンプルセットは厳密に科学的な 基準に従って選択する必要はありませんが、選択範囲はデジタル製品の範囲全体に及ぶ必要があり（デジタル製品上の任意の サンプルを選択できます）、個々のサンプルの選択が 予測可能なパターンに従わないようにする必要があります。無作為サンプルセットの生成に使用した方法を記録することは、 評価結果の信頼性および再現性を確保するために有用です。
無作為サンプルセットの方法によって、サンプルセットにすでに含まれるビューと 同一のビューが選択された場合は、別のビューを選択するべきです。新しいビューが 見つからない場合、このステップは完了したものと見なすべきです。
方法論要件 3.3 選択したサンプルセットに、 完全なプロセスの一部であるすべての サンプルを含めます。
選択したサンプルセットには、完全なプロセスを構成する一連のページまたはビューを すべて含める必要があります。サンプルがプロセスに属する場合、同じ プロセスに属するすべてのページまたはビューを含める必要があります。
必要なサンプルを含めるには、次のステップを使用します。
既定の系列は、完全なプロセスにおける既定の経路を説明する 標準的なユースケースに従います。利用者の入力エラーがなく、 追加オプションも選択されないことを前提とします。例えば、ウェブショップアプリケーションでは、利用者は 購入手続きへ進み、既定の支払い方法を確認し、必要な支払い 詳細をすべて正しく入力して購入を完了します。この間、ショッピングカートの内容を変更せず、 保存済みの利用者プロファイルを使用し、代替の支払い方法や 配送先住所を選択せず、誤った入力も行わないものとします。
分岐系列は、プロセスの既定の分岐に再合流する地点で終了できます。例えば、新しい配送先住所を追加する処理は、 プロセスの既定の分岐に戻る重要な 代替分岐として記録されます。
ほとんどの場合、後で再現できるよう、 プロセスを完了するために系列内の 1 つのサンプルから次のサンプルへ進むのに必要な操作を記録して指定する必要があります。 このような操作の例として、「氏名と住所を入力し、『送信』ボタンを選択する」があります。 ほとんどの場合、完全な プロセス内のサンプルを特定するには、ウェブアドレス（URL）だけでは不十分です。また、 サンプルがプロセスの一部であることを明確に記録することで、評価者が、 追加、変更、または表示された要素など、関連する変更に作業を集中できるようになります。
方法論要件 4: 方法論要件 4.1、方法論要件 4.2、および 方法論要件 4.3に従って、 選択したサンプルセットを評価します。
このステップで評価者は、ステップ 3: 代表的なサンプルセットを選択するで選択したすべてのサンプルを詳細に評価し、構造化サンプルセットと無作為に 選択したサンプルセットを比較します。評価は、ステップ 1.2: 適合目標を定義するで定義した対象 適合レベルにおける 5 つの WCAG 2 適合要件に従って実施します。
WCAG 2.2 の 5 つの適合要件は次のとおりです。
これらの適合要件に対する評価の追加ガイダンスを、以下の セクションに示します。WCAG 2 のガイダンス階層および 適合を理解するでは、 この文書の範囲を超える WCAG 2 適合要件に関する、さらに詳しい背景情報およびガイダンスを提供しています。
このステップを実施するには、WCAG 2 適合要件を深く理解し、 必要な専門知識のセクションで説明した専門知識を備えている必要があります。
方法論要件 4.1: 完全なプロセス内またはその終端にない 各サンプルが、対象適合レベルにおける 5 つの WCAG 2 適合要件のそれぞれに適合していることを確認します。
ステップ 3: 代表的なサンプルセットを選択するで選択した各サンプルのうち、 完全なプロセス内またはその終端にないものについて、ステップ 1.2: 適合目標を定義するで定義した対象適合レベルで、5 つの WCAG 適合要件それぞれへの適合性を確認します。これには、いかなる機能も有効化せず、 データを入力せず、その他の方法でプロセスを開始しない状態で、サンプルのすべてのコンポーネントが含まれます。このような機能および インタラクションは、完全なプロセス内またはその終端にあるサンプルを含め、 後続のステップで評価します。
多くのサンプルには、ヘッダー、ナビゲーションバー、検索フォームなど、 繰り返し現れるコンポーネントがあります。要件は ページ全体を確認することですが、通常、これらのコンポーネントは、 異なる表示や動作をする場合、または ステップ 1.4: 追加の 評価要件を定義する（任意）で追加の評価要件が定義されている場合を除き、出現するたびに再評価する必要はありません。
通常、WCAG 2 達成基準を満たしているか、満たしていないかを判断する方法はいくつかあります。 W3C/WAI は、特定の WCAG 2 達成基準を満たす方法を文書化した、 （非規範的な）WCAG 2.2 の達成方法集を提供しています。また、 コンテンツが特定の WCAG 2 達成基準を満たさないことが既知である方法を示す、文書化された一般的な失敗例も含まれています。WCAG 達成基準の 達成方法を理解するでは、WCAG 2 の達成方法という概念に関するさらに詳しいガイダンスを提供しています。
評価者は、このような文書化されたガイダンスを使用して、特定のウェブコンテンツが WCAG 2 達成基準を満たすか、満たさないかを確認できます。文書化された達成方法および失敗例は、 評価報告書の背景情報としても有用です。ただし、W3C/WAI が文書化した特定の 達成方法および失敗例一式を使用する必要はありません。実際、評価者は いかなる達成方法および失敗例にも従う必要はありません。評価者は、WCAG 2 達成基準を満たすか、満たさないかを評価するため、 その他のアプローチを使用できます。例えば、評価者は、十分な達成方法の 要件を満たす特定のテスト手順およびプロトコルを使用できます。これらは、公開されている場合もあれば、 評価者のみが利用できる場合もあります。達成方法の使用に関する詳細なガイダンスは、前述の WCAG 達成基準の 達成方法を理解するに示されています。
WCAG 2 達成基準はそれぞれ、「特定のウェブコンテンツに適用したときに 真または偽のいずれかになる検証可能な記述」として策定されています。特定の達成基準に関連するコンテンツが 利用者に提示されていない場合（例えば、ウェブページ上に動画がない場合）、 WCAG 2 に従えば、その達成基準は「満たされている」となります。任意で、 評価報告書では、関連するコンテンツが存在しない達成基準を、 例えば「存在しない」と明示できます。適合を 理解するでは、さらに詳しい背景情報およびガイダンスを提供しています。
サンプル上のコンテンツには、代替バージョンが存在する場合があります。例えば、動画コンテンツは、 字幕のあるバージョンとないバージョンで提供される場合があります。場合によっては、サンプルセット全体（またはその系列）が、 初期サンプルの代替バージョンとして提供されることがあります。WCAG 2 への適合は、WCAG 2 の 適合する 代替バージョンの定義に記載されている要件を満たす代替バージョンを利用して達成できます。例えば、字幕のない動画コンテンツを含むウェブページであっても、 動画について適合する代替バージョンとして認められる代替バージョンを提供することで、 WCAG 2 を満たすことができます。適合する 代替バージョンを理解するでは、この文書の範囲を超える、適合する代替バージョンに関するさらに詳しいガイダンスを提供しています。
代替バージョンは別個のサンプルではなく、コンテンツの一部と見なされます。 サンプルは、その代替バージョンとともに 1 つの単位（ページ全体）として評価されます。
サンプル上のコンテンツは、アクセシビリティサポートされている方法で 提供される必要があります（直接、または代替バージョンを通じて）。例えば、動画の字幕は、 利用者に表示できる方法で提供する必要があります。WCAG 2 の アクセシビリティサポートの定義では、 アクセシビリティサポートされていると認められるための ウェブコンテンツ技術の使用に関する 特定の要件を定義しています。アクセシビリティ サポートされたウェブ技術の使用を理解するでは、この文書の範囲を超えるアクセシビリティ サポートに関するさらに詳しいガイダンスを提供しています。ただし、WCAG 2 は、デジタル製品がアクセシビリティのためにサポートする必要がある 特定のしきい値やソフトウェア一式を定義していません。 このような基準の定義は、デジタル製品の目的、対象 読者、言語など、いくつかの要素に依存します。特定の デジタル製品を評価するために使用する基準は、ステップ 1.3: アクセシビリティサポートの 基準を定義するで定義します。
サンプル上のコンテンツが WCAG 2 に適合していない場合でも、サンプル全体としては WCAG 2 に適合する場合があります。例えば、情報および機能が、 支援技術でまだ広くサポートされていない ウェブコンテンツ技術を使用して、または支援技術でサポートされない方法で提供される一方、 その情報および機能について、アクセシビリティサポートされた、適合する代替バージョンが提供される場合があります。この場合、サンプルが WCAG 2 に適合できるよう、 不適合コンテンツが適合コンテンツに悪影響を与えてはなりません。WCAG 2 の 非干渉に関する適合要件では、 コンテンツが非干渉と認められるための特定の要件を定義しています。要件 5 を 理解するでは、この文書の範囲を超える非干渉に関するさらに詳しいガイダンスを提供しています。
方法論要件 4.2: 完全なプロセスの一部である各サンプルに対する すべてのインタラクションが、対象適合レベルにおける 5 つの WCAG 2 適合要件のそれぞれに適合していることを確認します。
ステップ 3.3: 完全なプロセスを含めるで特定した各完全なプロセスについて、 特定した既定および分岐のサンプル系列に従い、ステップ 4.1: すべての初期サンプルを確認するに従って各サンプルを評価します。ただし、この場合、 すべてのコンテンツではなく、プロセスに沿って変化するコンテンツだけを評価すれば十分です。
機能、データ入力、通知、およびその他のインタラクションは、この確認の一部です。特に、次のものが含まれます。
方法論要件 4.3: 無作為に選択したサンプルセット内の 各サンプルに、構造化サンプルセットに表れていない種類のコンテンツおよび結果が 現れていないことを確認します。
WCAG 2 達成基準の個々の発生箇所は、構造化サンプルセットと 無作為に選択したサンプルセットで異なりますが、無作為に選択したサンプルセットに、 構造化サンプルセットに存在しない新しい種類のコンテンツが現れるべきではありません。また、無作為に 選択したサンプルセットの評価結果に、構造化サンプルセットにはない新しい評価結果が 現れるべきではありません。無作為に選択したサンプルセットに新しい種類のコンテンツまたは新しい評価結果が現れる場合、 構造化サンプルセットがウェブサイトで提供されるコンテンツを十分に代表していなかったことを示します。この場合、評価者は ステップ 3: 代表的なサンプルセットを選択するに戻り、 新たに特定した種類のコンテンツおよび評価結果を反映する追加サンプルを選択する必要があります。また、ステップ 2: 対象 デジタル製品を調査するの結果も、それに応じて調整する必要がある場合があります。このステップは、 構造化サンプルセットがデジタル製品で提供されるコンテンツを適切に代表するまで繰り返します。
方法論要件 5: 方法論要件 5.1に従い、任意で 方法論要件 5.2、方法論要件 5.3、方法論要件 5.4、および 方法論要件 5.5にも従って、 評価結果を報告します。
評価結果はプロセスの最後に報告しますが、検証可能な結果を確保するため、 評価プロセス全体を通じて文書化します。文書には通常、さまざまな 機密性レベルがあります。例えば、個々の要件の評価に使用した特定の方法の文書は 評価者のみに限定される場合がありますが、これらの検査結果に関する報告書は 通常、評価依頼者が利用できます。製品所有者はさらに、 この方法論に従った評価結果について公開ステートメントを作成することもできます。
方法論要件 5.1: ステップ 1: 評価範囲を定義する、ステップ 2: 対象デジタル製品を調査する、ステップ 3: 代表的な サンプルセットを選択する、および ステップ 4: 選択したサンプル セットを評価するで定義された各ステップの結果を文書化します。
透明性、評価結果の再現性、およびこの評価に基づくステートメントの根拠を確保するため、 前の各ステップ（すべてのサブセクションを含む）の結果を文書化することが不可欠です。
[WCAG-EM-Report-Tool] は、 この文書のステップに基づく報告書の生成を支援します。
この文書を公開する必要はありません。機密性のレベルは、 通常、評価依頼者が決定します。
少なくとも次の事項を含めます。
評価結果の文書化の一環として、問題の明確な説明、再現手順、 評価結果の重大度、スクリーンショットおよび／または動画を含めることで、チームが問題をより迅速に解決できます。
報告書文書に求められる詳細度に応じて、ステップ 4: 選択したサンプルセットを評価するの結果は、評価した 各サンプルについて個別に提供することも、サンプルセット全体について集約して提供することもできます。報告書には、 満たしていない各適合要件および WCAG 2 達成基準について、少なくとも 1 つの 例を含めるべきです。評価者が繰り返し発生する問題を示すことも、 適切な実践です。
報告書には、ステップ 1.4: 追加の評価要件を定義する（任意）で定義した 追加の評価要件に応じて、追加情報を含めることもできます。例えば、 評価依頼者は、すべてのサンプルについて発生したすべての失敗例、特定した失敗の性質および原因に関する詳細情報、または失敗を修正するための 修復案を示す報告書を要求する場合があります。
方法論要件 5.2: 評価した サンプルを保存し、それらの評価に使用した評価ツール、ウェブブラウザー、支援技術、その他の ソフトウェア、および方法を記録します（任意）。
任意ではありますが、評価者が評価の詳細を記録しておくことは適切な実践です。例えば、 紛争が発生した場合に解決を支援するため、評価者が評価の詳細を記録しておく必要がある場合があります。これには、評価したサンプルの保存、およびそれらの評価に使用した 評価ツール、ウェブブラウザー、支援技術、その他のソフトウェア、および方法の記録が含まれます。 この記録は通常、内部で保持され、ステップ 1.4: 追加の評価要件を定義する（任意）で別途 合意されない限り、評価者は共有しません。
評価の詳細の記録には、次の事項を含めることができます。
一部のツールでは、ファイルおよびリソースの初期コンテンツではなく、評価中に表示された 動的に生成または変更されたコンテンツ、すなわち Document Object Model (DOM) を保存できます。これらはしばしば異なります。
この記録は、評価全体に対して包括的に適用することも、個々のサンプルに適用することも、 評価対象サンプルセット内で実施した個々の検査に適用することもできます。評価した異なるサンプルに何を使用したかを記録するには、 表またはグリッドが有用な場合があります。
評価の詳細の記録には、内部 コード、パスワード、およびデータのコピーなど、機密情報が含まれる場合があります。特別なセキュリティおよびプライバシー上の対策が 必要になる場合があります。
方法論要件 5.3: 適合性評価の結果を説明する ステートメントを提供します（任意）。
注意: 大半の状況では、この方法論のみを使用しても、対象デジタル製品について WCAG 2 適合宣言を行えるようにはなりません。詳しい背景情報については、WCAG 2 適合宣言との関係を参照してください。
製品所有者は、この 方法論に従った評価結果について公開ステートメントを作成することを希望する場合があります。これは、少なくとも任意ではないすべての方法論要件を満たし、 ステップ 1.2: 適合目標を定義するで定義した適合目標を、 評価したすべてのサンプル（ステップ 4: 選択したサンプル セットを評価する）が満たし、かつ製品所有者が、作成した評価ステートメントの有効性を確保し、正確性を維持することを約束する場合に実施できます。
この方法論に従った評価ステートメントには、少なくとも次の情報を含めます。
この方法論に従った評価ステートメントは、WCAG 2 への 部分適合のみを達成した場合にも作成できます。この場合、評価ステートメントには次の情報も含めます。
注記: 評価ステートメントおよび適合性報告書などの付随文書自体を、 アクセシブルな形式で公開することが不可欠です。
方法論要件 5.4: 集計 スコアを提供します（任意）。
集計スコアは、経時的な進捗を伝えるための数値指標となりますが、 現在、必要な信頼性、正確性、および 実用性を満たすと知られている単一の指標はありません。実際、集計スコアは誤解を招くことがあり、 デジタル製品の実際のアクセシビリティを理解するための十分な文脈および 情報を提供しません。これらおよびその他の理由から、WCAG 2 は評価方式を提供していません。W3C のウェブアクセシビリティ 指標に関する調査報告書では、この文書の範囲を超える、進行中の調査、さまざまなアプローチ、およびスコアリング指標の制限に関する 詳しい背景情報を提供しています。スコアを提供する場合は、 透明性および再現性を促進するため、スコアリング手法を文書化し、報告書とともに 評価依頼者が利用できるようにすることが不可欠です。
方法論要件 5.5: 評価結果の 機械可読な報告書を提供します（任意）。
機械可読な報告書は、オーサリングツール、アクセシビリティ 評価ツール、および品質保証ツールによる評価結果の処理を容易にします。Evaluation and Report Language (EARL) は、この目的のために特別に設計された機械可読形式です。 機械可読な報告書を提供するには EARL を使用することを推奨します。EARL などの機械可読な 報告書を含む、メタデータの使用方法についてさらに学ぶには、WCAG 2 の メタデータを 理解するも参照してください。
この文書では、次の用語および定義を適用します。
これには、ホーム、ログイン、およびその他の入口と、該当する場合には、連絡先、 ヘルプ、法的情報、および通常は他のすべてのビューからリンクされる同様のビュー （通常はヘッダー、フッター、またはナビゲーションメニューから）が含まれます。
ビューの定義は以下に示します。
この方法論は、完全で自己完結したデジタル製品に焦点を当てています。デジタル 製品は、それぞれを個別の製品と見なすことができる、より小さなビューの部分集合で構成される場合があります。 例えば、デジタル製品には、オンラインショップ、組織内の各 部門の領域、ブログ領域、およびそれぞれをデジタル製品と見なすことができるその他の領域が含まれる場合があります。
これには、製品の利用者が参照する情報と、この機能を実行するために利用者が行う タスクが含まれます。
その他の機能が評価範囲から除外されるわけではありません。「主要 機能」という用語は、重要なサンプルを特定し、それらを他のサンプルとともに 評価に含めるためのものです。
多くの場合、評価依頼者は製品所有者または製品開発者である場合がありますが、 その他の場合には、調達担当者やアクセシビリティ監視調査の 所有者などの別の主体である場合があります。
アクセシビリティの基礎、評価、および WCAG 2 に関する以下の情報は、この 方法論を使用するうえで重要です。この方法論を使用する評価者は、記載されているすべての リソースを十分に熟知していることが期待されます。
次の文書では、アクセシビリティの主要な構成要素を紹介し、障害のある人が ウェブをどのように使用するかを説明しています。これらは、アクセシビリティ 評価のより広い文脈を理解するうえで不可欠です。
以下は、デジタル製品のアクセシビリティを評価するためのさまざまなアプローチを概説する、特に重要なリソースです。
これは、ウェブコンテンツを障害のある人にとってよりアクセシブルにする方法を説明する、国際的に認められた標準です。 次のリソースは、デジタル製品のアクセシビリティ 評価において特に重要です。
2.0 への更新には、次の貢献者が参加しました。 Shadi Abou-Zahra; Jason Ament; Alastair Campbell; Graeme Coleman; Tamsin Ewing; Wilco Fiers; Mike Gifford; Jan Jaap de Groot; Karl Groves; Umut Gultekin; Shawn Henry; Ian Lloyd; Wendy Meerkerk; Laurie Reynolds; Iacobien Riezebosch; Eric Velleman; Kevin White; Paul van Workum; Kate Zhao.
編集者は、評価者へのインタビューにおいて次の人々からもフィードバックを求めました。 Roel Antonisse; Sacha Bogaers; Bram Duvigneau; Stefan Farnetani; Detlev Fischer; Ronny Hendriks; Sophie Ragas; Savitri Sinnema.
WCAG 2.0 Evaluation Methodology (Eval) Task Forceの過去の積極的な参加者には、次の人々が含まれます。Shadi Abou-Zahra; Frederick Boland; Denis Boudreau; Amy Chen; Vivienne Conway; Bim Egan; Michael Elledge; Gavin Evans; Wilco Fiers; Detlev Fischer; Elizabeth Fong; Vincent François; Alistair Garrison; Emmanuelle Gutiérrez y Restrepo; Katie Haritos-Shea; Martijn Houtepen; Peter Korn; Maureen Kraft; Aurelien Levy; David MacDonald; Mary Jo Mueller; Donald Raikes; Corominas Ramon; Roberto Scano; Samuel Sirois; Sarah J Swierenga; Eric Velleman; Konstantinos Votis; Kathleen Wahlbin; Elle Waters; Richard Warren; Léonie Watson.
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: