Explainer for W3C Accessibility Guidelines (WCAG) 3.0 日本語訳

W3C Accessibility Guidelines (WCAG) 3.0 は、Web Content Accessibility Guidelines 2.2 [WCAG22]および以前のバージョンの後継です。これは、WCAG 2を廃止しません。これは、User Agent Accessibility Guidelines 2.0 [UAAG20]およびAuthoring Tool Accessibility Guidelines 2.0 [ATAG20]の内容を取り入れて、著者がガイドラインを満たすのを支援することがあります。これらのバージョンは、10年以上にわたって関連性を維持するモデルを提供しました。テクノロジーの変化と障害のある人のニーズの変化に対応するためには、コンテンツのアクセシビリティをより包括的に扱う新しいモデルが必要です。

このExplainerの内容は次のとおりです：

• WCAG 3の目標
• WCAG 3の背景と開発の歴史
• WCAG 3を作成する現在のプロセス
• WCAG 3の構造
• 適合アプローチ
• ユーザー生成コンテンツに関する情報
• スケジュール

WCAGの目標は、さまざまなプラットフォームで製品のアクセシビリティを向上させるために使用できる情報を提供することです。WCAG 3は、次のことを可能にするモデルを使用します：

• WCAG 2よりも多くの障害者のニーズに対処します。
• XR（拡張現実、仮想現実、複合現実）、音声入力などの出版要件および新興テクノロジーを組み込みます。
• メンテナンスが容易し、テクノロジーが進化しても、新しいモデルが時間の経過とともにより長持ちするようにします。
• ウェブ技術がオーサリングツール、ユーザーエージェント、および支援技術と連携するために必要な方法に関する追加情報を含みます。

WCAG 3の追加の目標は、Requirements for WCAG 3.0に記載されています。これらは、Silver research、Silver Design Sprintの結果、ならびにAccessibility Guidelines Working Group、Silver Task Force、およびSilver Community Groupからのインプットに基づいています。

WCAG 3はもともと"Silver"というプロジェクト名を持っていたので、それに取り組んでいた元のグループと初期の設計作業の多くはそのプロジェクト名を持っています。AG Working GroupのSilver Task ForceとW3C Silver Community groupが提携して、新しいアクセシビリティガイダンスのニーズ、要件、および構造を作成しました。彼らは2017年から2023年にかけてSilverに取り組みました。その間、次の作業を行いました：

1. Web Content Accessibility Guidelinesのstakeholders and their job storiesのリストの作成。
2. Web Content Accessibility Guidelinesの新しいメジャーバージョンのニーズの調査（Silver Research Project）。
3. アクセシビリティガイダンスを改善するために開発されたproblem statements and opportunities。
4. 問題の説明に対処するための指示をinput from industry leadersから受け取りました。完全なFinal Report of the Silver Design Sprintは、ドラフトとして誤ってラベル付けされています。デザインスプリントに関するすべての情報が含まれています。
5. Requirements for WCAG3のドラフト作成。
6. プロジェクトの各側面のプロトタイプの作成およびテスト。
7. WCAG3のFirst Public Working Draftを作成し、7つのワーキングドラフトを更新しました。

Accessibility Guidelines (AG) Working Groupは、WCAG 3の作成に反復的なアプローチを採用しています。各コンテンツは時間の経過とともに進化し、成熟度が高まります。結果として、文書は作業中となります。

文書の異なる部分には異なる成熟度レベルがあるため、各規範的セクションには次を示すステータスが含まれます：

• このセクションが開発プロセスのどこまで進んでいるか、
• 実験的に採用する準備ができているか、そして
• AG Working Groupがどのようなフィードバックを求めているのか。

ステータスインジケーターは、成熟度の低い順に次のとおりです：

• Placeholder（プレースホルダー）：この内容は一時的なものです。ここで期待されるコンテンツの種類を示します。これらはすべて置き換えられる予定です。プレースホルダーの内容に関するフィードバックは不要です。
• Exploratory（探索的）：この内容は洗練されていません。詳細と定義が欠落している可能性があります。ワーキンググループは、このセクションの方向性を検討しています。フィードバックは提案された方向性に関するものであるべきです。
• Developing（開発中）：この内容は、このセクションに必要なものに関してほぼ合意されていますが、すべての高レベルの懸念が解決されているわけではありません。詳細は追加されましたが、まだ解決されていません。フィードバックは、セクションが広く使用可能で合理的であることを保証することに焦点を当てるべきです。
• Refining（洗練）：この内容は、広く一般に公開され、実験的に採用される準備ができています。ワーキンググループは、このセクションについて合意に達しました。フィードバックは、実施の実現可能性に焦点を当てるべきです。
• Mature（成熟）：この内容は、ワーキンググループによって推奨の準備ができていると考えられています。このセクションに関するフィードバックは、ワーキンググループが予想していなかった可能性のあるエッジケースのシナリオに焦点を当てるべきです。

AG Working Groupは、毎年2つの新しいドラフトを公開することを目指しています。各ドラフトには、一般の人々が考慮すべき対象を絞った質問が含まれます。応答は、作業を進めるのに役立ちます。コンテンツは進化し、レイアウトとスタイルに変更が加えられる可能性がありますが、現在のリリースのすべての部分にはまだ反映されておらず、将来のリリースにも反映される予定です。

WCAG 3には、規範的なガイダンスと参考情報のガイダンスの両方が含まれています。このガイダンスは次のように構成されています：

• ガイドライン（アウトカムステートメント）- 規範的
  • コア要件 - 規範的
    • How to 文書 - 参考情報
      • メソッド - 参考情報
  • 補足要件 - 規範的
    • How to 文書 - 参考情報
      • メソッド - 参考情報
  • アサーション - 規範的
    • How to 文書 - 参考情報
  • 推奨されるプラクティス - 参考情報
    • How to 文書 - 参考情報

各タイプのガイダンスの詳細は下記のとおりです。

デフォルトでは、ガイドラインはテスト対象別に編成されています。WCAG 3は、既存のQuickRefと同様に、読者がコンテンツを再編成およびフィルタリングできるようにタグを組み込んだバージョンを提供します。たとえば、読者がWCAG 2と同じ構造でWCAG 3の基準を見ることができるように、コンテンツにはPerceivable（知覚可能）、Operable（操作可能）、Understandable（理解可能）、Robust（堅牢）のタグが付けられています。

Requirements for WCAG 3.0のいくつかは、人々および組織がWCAG 2の適合性をどのように利用してきたかを改善することに関するものです。適合自体は単純な概念です。スコープ内のコンテンツが仕様の要件を満たしているでしょうか？これはバイナリー（2値）であり、人間とデジタルのインターフェイスは複雑で多様であるため、その単純さが作業を困難にする可能性があります。

AG Working Groupは、適合アプローチをシンプルに維持しながらも、テスト、レポート、およびポリシーまたは規制におけるWCAG 3の利用について、より有益なアドバイスを提供するモデルを模索しています。

適合とは、コア要件のすべてを満たすことを意味しますが、それは始まりにすぎません。適合レベルの上下にもレポートの階層があります。適合に至るまでに、進捗状況を示すために満たすことができる一連の要件があります。これらは、「身体的危害の回避」と「基礎的アクセス」です。適合レベルの上には、アクセシビリティの向上を示すWCAG 3の「ブロンズ」、「シルバー」、「ゴールド」のレポート階層があります。これらの階層は、アクセシビリティアサーションと推奨されるプラクティスを含む適合に基づいて構築されています。

適合レベルの代わりにレポート階層を使用すると、次の2つの改善が可能になります：

1. 製品が適合していない場合、進捗状況を測定して表示するために使用できる一連の要件があります。
2. 適合は上限ではなくベースであるため、適合の上の階層は、推奨されるプラクティスの組み込みおよびアクセシビリティの成熟度を示します。規制当局が、一部の種類の組織に対してこれらの階層の使用を奨励または強制するかもしれません。

各コア要件には、適合を満たすために進めることができるレベルに関連するタグがあります。これらのタグは次のとおりです：

• 身体的危害（Physical harm） - 要件を満たさないと、障害のある人が直ちに身体的危害を受ける可能性があります。
• リスク（Risk） - 要件を満たさないと、障害のある人の経済的、医学的、法的、プライバシー、またはセキュリティ上のリスクが不当に増加します。
• 障壁（Barrier） - 要件を満たしていないと、障害のある人が手続きを進めることができなくなります。この一部は必要な支援技術のサポートによるものである可能性があり、一部は設計に固有のものである可能性があります。
• 摩擦（Friction） - 要件を満たさないことは、障害のある人を妨げる可能性があります。複数の失敗が発生すると、障害のある人が続行できなくなる可能性があります。

「身体的危害の回避」の階層に到達するには、「身体的危害」と「リスク」でタグ付けされたすべてのコア要件を満たす必要があります。「基礎的アクセス」の階層するには、身体的危害の回避の階層のコア要件および「障壁」とマークされた要件を満たす必要があります。

適合より上の階層は、補足的な要件およびアサーションを使用して定義され、満たされます。補足的な要件およびアサーションの特定の数または割合を満たせば、その階層を主張することができます。

ウェブコンテンツ発行者は、そのデジタル製品のユーザーによって提供されるコンテンツを含んでもよいです。このようなコンテンツを「ユーザー生成コンテンツ」と呼びます。

ユーザー生成コンテンツには、次のようなものがあります：

• ソーシャルメディアへの投稿およびコメント
• アップロードされた写真
• アップロードされた映像またはその他のマルチメディア。

ユーザー生成コンテンツは、コンテンツプラットフォームが特に歓迎して奨励する場合に、訪問者による公開のために提供されます。ユーザー生成コンテンツとは、一般ユーザーおよび顧客向けに特別に設計されたユーザーインターフェイスを通じて送信されるコンテンツです。発行者の代理として行動する発行者のエージェント（従業員、契約者、承認されたボランティアなど）がコンテンツを公開するためのオーサリングツールとして同じユーザーインターフェイスを使用しても、そのコンテンツはユーザー生成コンテンツにはなりません。ユーザー生成コンテンツの適合セクションの目的は、WCAG 3のガイドラインおよびメソッドで、ユーザー生成コンテンツのアクセシビリティを向上させるために追加または異なる手順を要求できるようにすることです。

WCAG適合の重要な部分は、個々のWCAG 3ガイドラインに関連する特定のガイダンスです。すべてのWCAG 3ガイドラインが、ユーザー生成コンテンツに対して独自のアウトカムおよびテストを持つわけではありません。ユーザー生成コンテンツの要件が特定のガイドラインで指定されていない限り、コンテンツがユーザー生成コンテンツであるかどうかに関係なく、そのガイドラインは記載されているとおりに適用されます。

ウェブコンテンツの発行者は、ユーザー作成コンテンツのすべての場所（ホストされたコンテンツの解説、販売用個人間取引リストの製品説明、レストランのレビューなど）を特定し、それぞれについて標準的なアクセシビリティ評価分析を実行するべきです。アクセシビリティの問題がなければ、ユーザー生成コンテンツは完全に適合しています。

AGは現在、2026年8月までチャーターされています。この期間のスケジュールは、WCAG 3 Timelineで維持されています。

ワーキンググループは、有益な裏付けとなる文書とともに、単一の規範文書の中で繰り返し作業を続けます。コンテンツをモジュールに分割するなどの他の選択肢を検討した結果、ワーキンググループは、現時点で最も迅速な方法は、さまざまな成熟度レベルで単一のドキュメントを作成し続けることであると判断しました。コンテンツがより成熟した次のチャーター期間の一部として、成熟したコンテンツを参考情報となるモジュールとして公開できるかどうかを再検討します。

最終的なスケジュールは、このチャーター期間の一部として提供されます。WCAG 3は、少なくともWCAG 2.2と同程度の範囲をカバーするまでは発行されません。

支援技術（Assistive technology）

障害のある人の要件を満たす機能を提供する、オーサリングツールとは別のソフトウェア（またはハードウェア）。

オーサリングツール（Authoring Tool）

他のユーザー（他の著者もしくはエンドユーザー）が使用するウェブコンテンツを作成または変更するために、著者が（単独もしくは共同で）使用できるウェブベースまたは非ウェブベースのアプリケーション。

自動評価（Automated evaluation）

ソフトウェアツールを使用して実施される評価。通常、コードレベルの機能を評価し、他のテストにヒューリスティックを適用します。

自動テストは、人間の判断や経験を伴う他のタイプのテストとは対照的です。半自動評価により、機械は検査が必要な領域に人間を導くことができます。機械学習を介して実施される新しいテスト分野は、この定義には含まれていません。

適合（Conformance）

ガイドラインのすべての要件を満たすこと。適合は、正式な適合表明を行わない場合でも、ガイドラインに従うことの重要な部分です。

適合アプローチを参照してください。

非推奨（Deprecate）

古く、段階的に廃止される過程にあるものを宣言すること。通常、特定の代替品を支持します。

非推奨の文書の使用は推奨されなくなり、将来的には存在しなくなる可能性があります。

公平性（Equity）

人間の現実の範囲が、単にアクセスするだけでなく、参加するために必要なものを確実に得られるようにするプロセスと行動のアウトカム。公平性はWCAGに関連しているので、それは、実際の障害のある人を仕事に含めることとともに、基準/ガイドラインが障害のある人に与える影響に関するものです。

評価（Evaluation）

これらのガイドラインへの適合についてコンテンツを検査するプロセス。

評価のさまざまなアプローチには、自動化評価、半自動評価、人間による評価、ユーザーテストなどがあります。

機能的ニーズ（Functional need）

自分の能力の特定のギャップ、または能力と設計された環境またはコンテキストとの間の特定の不一致を説明するステートメント。

人間による評価（Human evaluation）

人間が実施する評価。通常、完全に自動的に評価できないテストに人間の判断を適用します。

人間による評価は、完全に機械によって行われる自動評価とは対照的ですが、機械が検査が必要な領域に人間を導くことができる半自動評価が含まれています。人間による評価には、コンテンツに対するユーザーのエクスペリエンスを直接テストするユーザーテストとは対照的に、コンテンツ機能の検査が含まれます。

参考情報（Informative）

情報提供を目的として提供され、適合のために必要とされないコンテンツ。

メソッド（Method）

要件を満たす方法、テストおよびスコアリング情報に関する、技術固有か技術に依存しないかのいずれかの詳細情報

規範的（Normative）

適合のために指示が必要なコンテンツ。

プログラムによる（Programmatically）

編集者の注記

未定義。

プロセス（Process）

アクティビティ/タスクをエンドツーエンドで達成するために完了する必要がある一連のステップ。

信頼性（Reliability）

スコアの再現性と一貫性、すなわち、同じリソースの評価が異なるコンテキスト（異なるツール、異なる人々、異なる目標、異なる時間）で実施された場合に、そのスコアがどの程度同じであるか。これは、さまざまなテスターによって同様の結果が確実に達成されるようにする場合に特に役立ちます。また、異なるテスターが同じパスまたはパス外の決定を選択するかどうかを確認することも役立ちます。代表的なサンプリング試験もこの範疇に入ります。Benchmarking Web Accessibility Metrics, Vigo, Lopes, O Connor, Brajnik, Yesilada 2011.

半自動評価（Semi-Automated Evaluation）

検査が必要な領域に人間を誘導する、機械を使用して実施される評価。

半自動評価には、自動評価と人間による評価のコンポーネントが含まれます。

重要な変更（Significant change）

編集者の注記

未定義。

技術に依存しない （Technology agnostic）

編集者の注記

未定義。

テスト（Test）

メソッドの実装を評価するメカニズム。

ユーザーアクティビティ（User activity）

編集者の注記

未定義。

ユーザエージェント (user agent)

エンドユーザーとウェブコンテンツ（ウェブブラウザー、ブラウザープラグイン、メディアプレーヤーなど）とのやり取りを取得、レンダリング、および促進するソフトウェア。

ユーザーテスト（User testing）

特定の機能的ニーズを持つユーザーがプロセスをどのように完了できるか、およびコンテンツが関連するガイドラインをどのようにサポートしているかを観察することによるコンテンツの評価。