Copyright © 2021-2025 World Wide Web Consortium. W3C® liability, trademark and document use rules apply.
W3C アクセシビリティ・ガイドライン（WCAG）3.0は、障害のある利用者がウェブコンテンツをより利用しやすくするための幅広い推奨事項を提供します。これらのガイドラインに従うことで、全盲・弱視などの視覚障害、聴覚障害・難聴、運動や巧緻性の制限、音声障害、感覚障害、認知・学習障害、そしてそれらの組み合わせを持つ利用者の多くのニーズに対応できます。ガイドラインは、デスクトップ、ノートパソコン、タブレット、モバイル端末、ウェアラブル機器、その他のWeb of Thingsデバイスにおけるウェブコンテンツのアクセシビリティに対応しています。静的・動的・インタラクティブ・ストリーミングコンテンツ、音声映像メディア、仮想現実・拡張現実、代替アクセスの表示や操作など、さまざまな種類のウェブコンテンツに適用されます。また、ユーザーエージェント（ブラウザや支援技術）、コンテンツ管理システム、オーサリングツール、テストツールなどの関連ウェブツールにも対応しています。
本標準の各ガイドラインは、障害のある人々の記録された利用者ニーズに対応するアクセシビリティ対応の情報を提供します。ガイドラインは複数の要件や判定基準によってニーズが満たされたかどうか判断されます。また、各要件や判定基準を満たすために技術固有の方法が用意されています。
進化する技術に対応するため、本仕様は定期的に更新され、新しいニーズに対応する方法・要件・ガイドラインが追加される予定です。これらのガイドラインへの適合を正式に宣言する組織向けには、デジタルコンテンツの多様性や実施されるテストの種類に対応した複数の適合レベルが用意されています。
WCAG 3の概要や技術・教育資料へのリンクは、WCAG 3.0イントロダクションをご覧ください。
このセクションは、公開時点での文書のステータスを説明します。現在のW3C 公開物とこの技術報告書の最新改訂版は、 W3C 標準および草案インデックスに掲載されています。
これはW3C アクセシビリティ・ガイドライン（WCAG）3.0の更新です。開発ステータスに到達した全ての要件を含みます。
ご意見は、wcag3 GitHubリポジトリで課題を作成してください。コメントごとに個別のGitHub課題を作成し、1つの課題に複数トピックのコメントは避けてください。GitHubアカウント作成は無料です。GitHubでの課題作成が難しい場合は、public-agwg-comments@w3.org （コメントアーカイブ）までメールしてください。
ガイドラインの進行中の更新は、公開編集者ドラフトで確認できます。
この文書はアクセシビリティ・ガイドライン作業グループが 勧告トラックを用いて作業草案として公開したものです。
作業草案として公開されたことは、W3C およびそのメンバーによる承認を意味しません。
この文書はドラフトであり、随時更新・置換・廃止される可能性があります。進行中の作業以外の目的で引用するのは不適切です。
この文書は W3C 特許ポリシーの下で活動するグループによって作成されました。 W3Cは、 関連する特許開示の公開リストを管理しています。 このページには特許の開示方法も記載されています。個人が該当する特許を知っている場合、その特許に 必須の請求項が含まれていると考える場合は、 W3C特許ポリシー第6節に従って情報開示しなければなりません。
この文書は 2025年8月18日 W3C プロセス文書により管理されています。
このセクション（およびその小セクション）はアドバイスのみを提供しており、ガイドラインを規定するものではありません。つまり、参考または非規定（ノンノーマティブ）です。
はじめにのやさしいまとめ
はじめに
のまとめ終わり
この草案は、開発ステータスに進んだ可能性のあるガイドライン・要件・判定基準（アサーション）の最新リストを含みます。
探索的ステータスの要件や判定基準はこの作業草案には含まれていません。完全なリストを確認したい場合は、編集者ドラフトをご覧ください。
この草案をレビューする際、以下の質問をご検討ください：
さらに、作業グループは要件や判定基準を裏付ける研究も歓迎しています。
フィードバックは、WCAG 3 GitHubリポジトリで新しい課題を作成してください。1課題につき1トピックにし、複数トピックを1つの課題でコメントしないでください。
GitHubの利用が困難な場合は、public-agwg-comments@w3.org （コメントアーカイブ）にメールでご意見を送ってください。本文にご意見を書き、添付ファイルにはしないでください。
要件のリストはWCAG 2の達成基準よりも多くなっています。これは、
WCAG 3.0の最終的な要件セットはこの草案のものとは異なるものになります。要件が追加・統合・削除される可能性があります。また、要件の文言にも変更が加えられる見込みです。基本適合レベルを満たすために使われるのは一部の要件のみです。
WCAG 3.0の草案作成プロセスの一環として、本書の各規定セクションにステータスが割り当てられています。このステータスは、セクションの開発進捗、実験的採用への準備状況、作業グループが求めるフィードバックの種類を示します。
この仕様は、障害のある人々がウェブコンテンツやアプリケーションを利用できるようにするための新しいモデルとガイドラインを提示します。W3C アクセシビリティ・ガイドライン（WCAG）3.0は、多様な利用者ニーズに対応し、新しいテスト手法を導入し、ガイドラインや関連コンテンツを頻繁に更新できるようにして、急速な技術変化に対応しています。WCAG 3.0は、機能的ニーズに焦点を当てることでこの進化を支えています。これらのニーズは、アウトカム文、要件、判定基準、技術固有の方法としてガイドラインにより支援されます。
WCAG 3.0は、Webコンテンツ・アクセシビリティ・ガイドライン2.2 [WCAG22]およびそれ以前のバージョンの後継ですが、廃止するものではありません。また、ユーザーエージェント・アクセシビリティ・ガイドライン2.0 [UAAG20]やオーサリングツール・アクセシビリティ・ガイドライン2.0 [ATAG20]の内容も一部取り込み、拡張します。これら旧バージョンは柔軟なモデルを採用し、15年以上にわたって有用性を保ちました。しかし、技術や障害者ニーズの変化によって、より包括的かつ柔軟にコンテンツアクセシビリティに対応する新しいモデルが必要となりました。
WCAG 2とWCAG 3.0には多くの違いがあります。WCAG 3.0のガイドラインは、デスクトップ、ノートパソコン、タブレット、モバイル端末、ウェアラブル機器、その他のWeb of Thingsデバイス上のウェブコンテンツのアクセシビリティに対応しています。静的・動的・インタラクティブ・ストリーミングコンテンツ、視覚・聴覚メディア、仮想現実・拡張現実、代替アクセスの表示や操作など、さまざまな種類のウェブコンテンツに適用されます。また、ユーザーエージェント（ブラウザや支援技術）、コンテンツ管理システム、オーサリングツール、テストツールなどの関連ウェブツールにも対応しています。
本標準の各ガイドラインは、障害のある人々の記録された利用者ニーズに対応するアクセシビリティ対応の情報を提供します。ガイドラインは複数の要件によってニーズが満たされたかどうか判断されます。また、各要件を満たすために技術固有の方法が用意されています。
WCAG 2.2のAおよびAAレベルに適合したコンテンツは、新しい標準の最低適合レベルのほとんどを満たすと考えられますが、WCAG 3.0では追加のテストや異なる採点方式を採用するため、完全な適合には追加の対応が必要です。新しい標準は異なる適合モデルを採用するため、作業グループは一部の組織が引き続きWCAG 2を使用し、他の組織が新しい標準へ移行することを想定しています。WCAG 3への移行を希望する組織向けに、作業グループはマッピングなどの移行支援資料も提供する予定です。
このセクション（およびその小セクション）は、仕様への適合のために従うべき要件を提供します。すなわち、規定です。
ガイドラインのやさしいまとめ
以下のガイドラインはWCAG 3.0で検討中のものです。現時点では今後の草案でさらに詳細に検討される予定のトピック一覧です。このリストには現行のWCAG 2の指針と追加要件が含まれます。リストは今後の草案で変更されます。
特に記載がない限り、要件は記述されたコンテンツが視覚的にもプログラム的にも提供されることを前提としています。
ガイドライン
のまとめ終わり
WCAGを利用する個人や団体は多岐にわたり、ウェブデザイナー・開発者、政策立案者、購買担当者、教師、生徒などが含まれます。こうした多様なニーズに対応するため、アウトカム文で書かれたガイドライン、テスト可能な要件、判定基準、豊富な方法、リソースリンク、コードサンプルなど、複数層の指針を提供します。
以下のリストは、ワーキンググループが今後検討する予定の初期候補となるガイドライン・要件です。次の作業段階の指針とするためのものであり、WCAG 3.0の最終内容とはみなさないでください。
通常は、探索的な内容には各項目ごとに懸念点や質問を記載した編集者注が付きますが、このガイドラインセクションはWCAG 3.0検討初期段階のため、ほとんどの内容をこの編集者注でカバーします。特に記載がない限り、一覧のすべての項目は現時点で探索的です。検討対象となり得る話題の全リストであり、最終版に全てが含まれるわけではありません。
下記のガイドライン・要件は、ワーキンググループが調査・検討・研究してきた利用者ニーズの分析から得られています。まだ精査されておらず、重要な例外や方法は含まれていません。一部の要件はオーサリングツールやプラットフォームレベルで対応する方が適切な場合もあります。多くの要件は、範囲の定義や多言語・文化・記述体系への適用性をより明確にする追加作業が必要です。これらの課題は今後さらに各要件を検討しながら対応します。
追加調査
このリストを公開する目的のひとつは、現状の研究のギャップを特定し、それを補う支援を求めることです。
編集者注では、ワーキンググループが指針を十分に検証したり対応方法を作成するための研究が十分でない要件や、既存研究の評価に追加作業が必要な要件を示しています。既存の研究をご存知の場合や、当該分野で研究を行いたい場合は、GitHub課題を提出するか、public-agwg-comments@w3.org （コメントアーカイブ）までメールでご連絡ください。
利用者は画像に対して同等の代替手段を得られます。
各画像について：
同等の
画像 はプログラム的に判別可能です。
利用者は音声や映像のコンテンツに対して同等の代替手段を得られます。
説明付きトランスクリプトが音声または映像コンテンツに対して利用可能です。
メディア代替で発話者が識別されます。
メディア理解に必要な音声はメディア代替で識別または説明されます。
コンテンツ作成者はメディア代替に関するガイドを含むスタイルガイドに従います。
コンテンツ作成者はメディア代替が必要な利用者とテストを行い、結果に基づき問題点を修正しました。
コンテンツ作成者は適切なメディア代替をサポートするビデオプレイヤーを提供します。ビデオプレイヤーは以下の機能を備えます（該当するものすべて）:
コンテンツ作成者はメディア代替をレビュー済みです。
利用者は文脈や意味を伝える非テキスト・非画像のコンテンツに対して代替手段を得られます。
このガイドラインの要件・判定基準は探索的段階を超えていないため、ここには記載されていません。 完全な候補リストは編集者ドラフトをご覧ください。
キャプションはすべての録画済み音声コンテンツで利用可能です。ただし、音声コンテンツがテキストの代替であり、その旨が明確にラベル付けされている場合を除きます。
キャプションはメディア全体、および関連する制作物間で例外が必須でない限り一貫して提示されます。これにはキャプションテキストのスタイルや配置、発話者・言語・音声の識別方法の一貫性が含まれます。
キャプションの見た目（関連する視覚的指標を含む）は、フォントサイズ・太さ・スタイル・色・背景色・背景透過・配置などを調整可能です。
360度デジタル環境では、キャプションは常に利用者の正面に表示されます。
音声解説は、メディア理解に必要な視覚コンテンツのため、録画済み映像で利用可能です。ただし、映像コンテンツがテキストの代替であり、その旨が明確にラベル付けされている場合を除きます。
WCAG 3は、音声解説を挿入する隙間がない音声付き映像コンテンツをどう扱うか規定する必要があります。2つの解決策として、コンテンツ作成者が説明付きトランスクリプトを利用する例外を設ける、または拡張音声解説を提供することを求める方法があります。
サウンドトラック内の既存の間が十分に長くない場合、映像を一時停止し、音声トラックを拡張し、メディア理解に必要な視覚情報を説明する拡張音声解説を提供します。
利用者が音声解説の音量を映像の音声音量と独立して調整できる仕組み、および複数言語が提供されている場合は音声解説の言語を変更できる仕組みが利用可能です。
利用者は、図にフォーカスしていなくても図のキャプションを閲覧できます。
このガイドラインの要件・判定基準は探索的段階を超えていないため、ここには記載されていません。 完全な候補リストは編集者ドラフトをご覧ください。
利用者は、単一の感覚や知覚に依存しないコンテンツを利用できます。
このガイドラインの要件・判定基準は探索的段階を超えていないため、ここには記載されていません。 完全な候補リストは編集者ドラフトをご覧ください。
利用者は視覚的にレンダリングされたテキストを読むことができます。
テキストの各語について：
テキストブロックの既定／作成者による提示は、コンテンツの言語（または表記体系が最も類似する言語）の対応する値を満たします。
読みやすいテキストブロック（基本要件）と読みやすいテキストスタイル（基本要件）は一般的な用法に基づき、その補足版は可読性研究に基づいています。これらの言語での可読性研究がさらに必要です。
以下の表の指標は未確定であり、現在の内容は例です。
| 特性 | Arabic | Chinese | English | Hindi | Russian |
|---|---|---|---|---|---|
| インライン余白 | |||||
| ブロック余白 | 段落の周囲に ≥0.5em | ||||
| 行長 | 30～100 文字 | ||||
| 行の高さ | 1.0 ～ 段落の区切りの高さ | ||||
| 行揃え | 左揃えまたは両端揃え |
テキストの既定／作成者による提示は、コンテンツの言語（または表記体系が最も類似する言語）の対応する値を満たします。
読みやすいテキストブロック（基本要件）と読みやすいテキストスタイル（基本要件）は一般的な用法に基づき、その補足版は可読性研究に基づいています。これらの言語での可読性研究がさらに必要です。
以下の表の指標は未確定であり、現在の内容は例です。
| 特性 | Arabic | Chinese | English | Hindi | Russian |
|---|---|---|---|---|---|
| フォント書体 | |||||
| フォントサイズ | 垂直視角 ≥0.2°（一般的なデスクトップ視距離で約 10pt） | ||||
| フォント幅 | |||||
| テキスト装飾 | ほとんどのテキストは太字・斜体・下線ではない | ||||
| 文字間隔 | |||||
| 大文字小文字（Capitalization） | |||||
| ハイフネーション |
テキストブロックの提示は、コンテンツの言語（または表記体系が最も類似する言語）の対応する値を満たすように調整できます。
利用者が見た目を上書きすると情報が失われる可能性があります。可能であれば構造が意味を伝えることを確保する点については [other structural guideline] を参照してください。
以下の表の指標は未確定であり、現在の内容は例です。
| 特性 | Arabic | Chinese | English | Hindi | Russian |
|---|---|---|---|---|---|
| インライン余白 | |||||
| ブロック余白 | |||||
| 行長 | |||||
| 行の高さ | |||||
| 行揃え | 該当なし | 左揃え |
以下の各フォント特性の提示は、コンテンツの言語（または表記体系が最も類似する言語）の対応する値を満たすように調整可能です。
利用者が見た目を上書きすると情報が失われる可能性があります。可能であれば構造が意味を伝えることを確保する点については [other structural guideline] を参照してください。
以下の表の指標は未確定であり、現在の内容は例です。
| 特性 | Arabic | Chinese | English | Hindi | Russian |
|---|---|---|---|---|---|
| 下線 |
|
||||
| 斜体 | 無効 | ||||
| 太字 | 無効 | ||||
| フォント書体 | |||||
| フォント幅 | |||||
| 文字間隔 | |||||
| 大文字小文字（Capitalization） |
|
||||
| 自動ハイフネーション | 無効 |
コンテンツは、調整可能なテキストブロックおよび調整可能なテキストスタイルに従って調整された場合でも、内容と機能が失われません。
テキストブロックの既定／作成者による提示は、コンテンツの言語（または表記体系が最も類似する言語）の対応する値を満たします。
読みやすいテキストブロック（基本要件）と読みやすいテキストスタイル（基本要件）は一般的な用法に基づき、その補足版は可読性研究に基づいています。これらの言語での可読性研究がさらに必要です。
以下の表の指標は未確定であり、現在の内容は例です。
| 特性 | Arabic | Chinese | English | Hindi | Russian |
|---|---|---|---|---|---|
| インライン余白 | |||||
| ブロック余白 | |||||
| 行長 | |||||
| 行の高さ | |||||
| 行揃え | 左揃え |
テキストの既定／作成者による提示は、コンテンツの言語（または表記体系が最も類似する言語）の対応する値を満たします。
読みやすいテキストブロック（基本要件）と読みやすいテキストスタイル（基本要件）は一般的な用法に基づき、その補足版は可読性研究に基づいています。これらの言語での可読性研究がさらに必要です。
以下の表の指標は未確定であり、現在の内容は例です。
| 特性 | Arabic | Chinese | English | Hindi | Russian |
|---|---|---|---|---|---|
| フォント書体 | |||||
| フォントサイズ | 垂直視角 ≥0.2°（一般的なデスクトップ視距離で約 10pt） | ||||
| フォント幅 | |||||
| テキスト装飾 | ほとんどのテキストは太字・斜体・下線ではない | ||||
| 文字間隔 | |||||
| 大文字小文字（Capitalization） | |||||
| ハイフネーション |
利用者は、テキスト読み上げツールを用いてテキストコンテンツおよびその意味にアクセスできます。
数値情報は、日付・気温・時刻・ローマ数字の提示において混乱を避けるために、十分な文脈を含みます。
利用者は、複雑または不明瞭な言語を処理することなくコンテンツを理解できます。
関連：構造（これらのガイドラインは密接に関連しています）。
このガイドラインがさまざまな言語で適切に機能するようにするため、AG、COGA、国際化（i18n）のメンバーは、ガイダンスをストレステストするための初期言語セットに合意しました。
5つの「ガードレール」言語は次のとおりです：
まず国連（UN）の公用語6言語から始めました。その後、英語に類似しているためフランス語とスペイン語を外しました。最も話者が多いにもかかわらずUNのリストにないため、ヒンディー語を追加しました。
これら5言語のグループには、次のような多様な言語特性が含まれます：
このリストはすべての言語を含むわけではありませんが、作業を管理可能に保ちつつ、幅広い対象にとってガイダンスを有用にするのに役立ちます。
W3C の Global Inclusion コミュニティグループ、Internationalization（i18n）タスクフォース、その他と協力し、これらの要件のテストや手法を見直し・洗練します。将来的には、ガイドラインをさらに多くの言語へ翻訳するためのガイダンスも作成する予定です。
文に不要な語や句を含めません。
文に入れ子の節を含めません。
一般的な語句を使用し、一般的でない語には定義を用意します。
略語は初出時に説明または展開します。
慣用句や隠喩などの非直訳的な言語について、説明または曖昧さのない代替を用意します。
統計などの数値情報に対する代替を提供します。
コンテンツ作成者は、プロセス・ワークフロー・関係・年代情報などの複雑な概念について、記述されたコンテンツを見直し、理解を助ける補助的な視覚的要素を追加しています。
一定の長さを超える文書や記事には要約を用意します。
要約が必要となる語数については、さらなる研究が必要です。長さはコンテンツで用いられる言語にも依存する可能性があります。
語の正しい意味を識別するために必要な文字やダイアクリティカルマークを提供します。
これは多くの場合、アラビア語やヘブライ語などの言語に該当します。
コンテンツ作成者は、公開前に明瞭な言語であることを確認するためコンテンツをレビューします。
AIツールを使用してコンテンツを生成または変更する場合、コンテンツが明瞭で意図した意味を伝えていることを人間がレビューし証明するための文書化された手順をコンテンツ作成者が備えています。
コンテンツ作成者は、明瞭な言語に関する指針を含み、編集者にそのスタイルガイドの遵守を求める方針を含むスタイルガイドに従います。
スタイルガイドには、明瞭な語句だけでなく明瞭な数値表記に関する指針も含まれます。例えば、ローマ数字を避けるまたは説明する、必須でない数値情報を削除する、認知アクセシビリティに影響のある障害のある利用者を支援するために必須の数値情報に説明を付す、などです。
コンテンツ作成者は、明瞭な言語に関する指針を含み、編集者が定期的にそのトレーニングを完了することを求める方針を含む研修教材を提供します。
コンテンツ作成者は、使用言語に適した平易な言語ガイダンスに照らして平易な言語レビューを実施します。これには次の確認が含まれます：
利用者はどの要素にキーボードフォーカスがあるかを確認できます。
フォーカス可能な各項目について：
カスタムフォーカスインジケーターは、十分な大きさ、コントラストの変化、隣接コントラスト、明確なスタイルおよび隣接性を備えて使用されます。
フォーカス可能な項目は、ユーザーエージェントの既定インジケーターを使用します。
利用者はポインターのフォーカス位置を確認できます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者は、期待どおりに動作するインタラクティブ要素を利用できます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者は、視覚的にも支援技術でも識別・利用できるインタラクティブ要素に関する情報を得られます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者はキーボードのみでコンテンツをナビゲート・操作できます。
ポインター、音声（声など）、ジェスチャー、カメラ入力、その他の手段で制御・起動できるすべての要素は、キーボードインターフェースからも制御・起動できます。
他の入力モダリティでアクセスできるすべてのコンテンツは、キーボードインターフェースのみでもアクセスできます。
すべてのコンテンツには、ホバー、右クリックなどで利用可能なコンテンツも含みます。
他の入力モダリティには、ポインティングデバイス、音声・音声認識、ジェスチャー、カメラ入力、その他あらゆる入力・制御手段が含まれます。
全要素キーボード操作可能要件は、すべての操作可能な要素へ移動できることを許容しますが、次の要素が5画面分下にある場合には、すべてのコンテンツにアクセスできる必要もあります。また、コンテンツが展開式のセクション内にある場合、セクションを開くだけでなく、その中のすべてのコンテンツ（操作可能要素だけでなく）にアクセスできる必要があります。
作者が生成したキーボードコマンドは、標準プラットフォームのキーボードコマンドと競合しないか、リマップ可能です。
要素へナビゲート・入る・起動した後は、一般的なキーボードナビゲーション手法、またはそのページ/ビュー、もしくはその機能が使われる前の段階のプロセス内のページ/ビューに記載された手法により、常にその要素から離れることが可能です。
キーボードフォーカスが移動した場合、次のいずれかが成り立ちます：
スキップリンクや、キーボードナビゲーションを補助する目的で特別に追加された隠し要素を除き、タブ移動は、タブ操作前には可視でなかったコンテンツへキーボードフォーカスを移動させません。
アコーディオン、ドロップダウンメニュー、ARIA tab panelsは展開可能なコンテンツの例です。この要件によれば、これらは、内部にタブ順序に含まれる要素があるという理由だけでは自動的に展開されません。展開しないか、内部にタブ順序の要素を含まない設計にします。
利用者は、不要な身体的・認知的負担なくキーボードを使用できます。
キーボードフォーカスは、意味と操作性を損なわない順序と方法でコンテンツ内を移動します。
キーボードフォーカスが、ページ/ビュー内のあるコンテキストから別のコンテキストへ自動またはユーザーの要求で移動した場合、利用者が前のコンテキストへ戻ると、当該位置が存在しなくなっていない限り、キーボードフォーカスは以前の位置へ復元されます。
前のフォーカス位置が存在しない場合、ベストプラクティスは削除された位置の直前のフォーカス可能な場所へフォーカスを移すことです。例：ドキュメント中のタグ一覧で、各タグに削除ボタンがある場合。一覧の中程のタグの削除ボタンを押して削除すると、フォーカスは削除されたタグの直前のタグに置かれます。
コンテンツ作成者は、ユーザーインターフェース設計原則に従い、キーボードインターフェースのみを使用する場合に必要な入力コマンド数と、他の入力モダリティを使用する場合に必要なコマンド数の差を最小化します。
他の入力モダリティには、ポインティングデバイス、音声・音声認識、ジェスチャー、カメラ入力、その他あらゆる入力・制御手段が含まれます。
ポインター入力は一貫しており、すべての機能は、時間や圧力に依存しない単純なポインター入力で実行できます。
単純なポインター入力で起動できる機能については、次の少なくとも一つが成り立ちます：
ポインター入力で、単純なポインター入力以外を用いる機能は、単純なポインター入力、またはタイミングを必要としない単純なポインター入力のシーケンスでも操作可能です。
単純なポインター入力ではない例：ダブルクリック、スワイプジェスチャー、ピンチ・スプリットタップ・二本指ローターのようなマルチポイントジェスチャー、可変の圧力やタイミング、ドラッグ動作。
複雑なポインター入力は禁じられてはいませんが、行為を達成する唯一の手段にしてはなりません。
ポインターのキャンセル方法は、一連のページ/ビューにおける各種のインタラクションタイプで一貫しています。ただし、異なることが必須な場合は除きます。
異なることが必須な場合は、その旨を利用者に知らせると有益です。
特定のポインター速度が機能を達成する唯一の手段であってはなりません。特定のポインター速度がその機能に必須な場合を除きます。
音声入力の代替を提供し、音声による制御を容易にします。
音声入力は、機能を達成する唯一の手段であってはなりません。音声入力が機能に必須な場合を除きます。
リアルタイムの双方向音声コミュニケーションがある場合は、リアルタイムテキストの選択肢を提供します。
利用者は、異なる入力手法やその組み合わせを選択して使用し、相互に切り替えることができます。
コンテンツが、ポインターやキーボードフォーカスに対するユーザーエージェントの挙動に干渉する場合、ビュー内の何かをポインターで選択すると、ユーザーが要素からドラッグして（起動しないように）離れた場合でも、そのビューの選択したインタラクティブ要素へキーボードフォーカスが移動します。
ポインターのホバーやキーボードフォーカスを受けて追加のコンテンツが表示され、その後非表示になる場合で、追加コンテンツの視覚的提示が作者により制御され、ユーザーエージェントでは制御されない場合、以下のすべてを満たします：
ユーザーエージェントによって制御される追加コンテンツの例：HTML のtitle属性によって作成されるブラウザーのツールチップ。
これは、インタラクティブ要素自体の起動に加えて表示されるコンテンツに適用されます。たとえば、キーボードフォーカス時に表示される隠しリンク（ページ/ビューの別の部分へスキップするために使うリンクなど）は追加コンテンツを提示しないため、この要件の対象外です。
入力やナビゲーションを含む機能が異なる入力方法で実現可能な場合、利用者はいつでもそれらの入力方法を切り替える選択肢を持ちます。
全身または大きな身体の動きは、機能を達成する唯一の手段であってはなりません。全身または大きな身体の動きがその機能に必須な場合を除きます。
これは、身体の動きの検出と、デバイスへのアクション（シェイクなど）で身体の動きを要するものの両方を含みます。
利用者は代替の認証方法を利用できます。
本人確認や認証は、生体認証のみが手段であってはなりません。
本人確認や認証は、声による認証のみが手段であってはなりません。
利用者はエラーについて知り、修正できます。
エラーが検出された場合、利用者に視覚的およびプログラム的にエラー発生が通知されます。
エラーとなったコンテンツはプログラム的に示されます。
エラーメッセージは問題点を明確に記述します。
明瞭な言語のガイドラインは、理解しやすいコンテンツを書くための要件を示しています。
インタラクティブ要素とのユーザー操作によってエラーが発生した場合、エラーメッセージにはエラーとなった要素の人間可読な名称が含まれます。インタラクティブ要素がプロセスの別の部分にある場合は、そのページ/ビューやプロセスのステップもエラーメッセージに含みます。
エラーメッセージには、自動判定可能な修正案を含みます。ただし、コンテンツのセキュリティや目的を損なう場合は除きます。
エラーメッセージは、以下のうち少なくとも2つの方法で視覚的に識別できます：
エラーを示す記号や色は文化的文脈によって異なるため、適宜変更してください。
エラーメッセージは、利用者が閉じるかエラーが解消されるまで持続します。
エラーメッセージはエラーの原因とプログラム的に関連付けられています。
エラー通知がエラーとなった項目の近くにない場合、エラーへのリンクを提供します。
エラーメッセージは、エラーの原因となる箇所の近くに視覚的に配置されます。
利用者が情報を送信する際、次のうち少なくとも1つが成り立ちます：
送信時、利用者には送信した情報と送信状況が通知されます。
データ入力中、利用者がデータ入力後～フォーム送信前にデータ検証が行われるようにします。
複数ステップのプロセスを完了する際、利用者が次のステップに進む前に検証を行います。
利用者はコンテンツによって身体的危害を受けません。
コンテンツは、動きの感覚を生じさせる目的で急激な音声の変化を含まないか、動きを一時停止または防止できます。
5秒を超える視覚的な動きや疑似的な動きが必須な場合、利用者に警告を出し、同じ情報を視覚動作や疑似動作を避けて取得できる方法を提供します。
コンテンツは、操作によって起動される不要な視覚的な動きや疑似的な動きを含みません。ただし、一時停止または防止できる場合は除きます。
利用者はコンテンツ間の関係性を、視覚的にも支援技術でも把握できます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者は一貫性があり認識しやすいレイアウトを利用できます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者はコンテンツの中での自身の位置を、視覚的にも支援技術でも把握できます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者は構造を用いてコンテンツを理解し、ナビゲートできます。
関連：明瞭な言語（これらのガイドラインは密接に関連しています）。
要素間の関係性はプログラム的に伝達されます。
要素は、ランドマーク内でプログラム的にグループ化されます。
要素のグループには、その目的を示すラベルがあります。
要素のグループは、論理的かつ意味のある見出し階層で整理されています。
関連する要素は視覚的にまとめられています。
利用者は、妨害なくユーザーインターフェース要素やナビゲーションを認識・操作できます。
利用者の作業や理解に必須なコンテンツは、非解除可能・非移動可能な要素によって永続的に覆われません。
コンテンツが他のコンテンツを一時的にオーバーレイする場合、標準的な操作方法で明確に閉じたり移動したりでき、その表示がスクリーンリーダーの重要なアナウンスやキーボードフォーカスを妨げない必要があります。
コントロールが無効化されている場合、なぜ無効化されているのかと有効化に必要な操作についての情報が視覚的かつプログラム的に提供されます。
視覚的に固定されるよう設計された要素は予測可能な位置に配置され、主要なコンテンツと重なって読めないまたは使用できない状態にならないようにします。
利用者は一貫した代替の手法でナビゲーションできます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者は暗記や高度な認知課題を必要とせずに作業を完了できます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者はコンテンツを読む・利用するのに十分な時間があります。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者は不要な手順なく作業を完了できます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者は作業中に欺瞞に遭遇しません。
継続的なプロセス・サービス・作業に関する同意内容の変更は利用者に伝えられ、同意の機会が与えられます。
コンテンツに二重否定、虚偽記載、その他誤解を招く表現を含めません。
プロセスの完了には、タスクに必須でない限り人工的な時間制限を設けません。
「すぐに行動しないと利益を失う」と示唆することは人工的な時間制限です。
コンテンツは、財務・プライバシー・安全性に影響する情報から意図的に注意を逸らすために他の情報を強調する設計になっていません。
コンテンツ作成者は認知・メンタルヘルス関連の障害のある人々とテストし、結果に基づき問題点を修正しました。
利用者は情報の再入力や作業のやり直しを求められません。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者は作業の完了方法を理解できます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者はコンテンツが第三者によって提供されている場合を判別できます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
個人情報・機微情報を提供する際、利用者は以下を理解します：
個人情報・機微情報が表示される場合、利用者に通知し、情報を隠す仕組みを提供します。
利用者は選択肢の利点・リスク・結果を理解します。
法的・財務・プライバシー・セキュリティ関連の結果は、利用者が法的・財務・プライバシー・セキュリティ関連の同意を行う前にコンテンツ内で提供されます。
障害のある人が他の人とは異なる代替/追加のプロセスやコンテンツを利用する必要がある場合でも、代替利用で追加のリスクにさらされません。
法的・財務・プライバシー・セキュリティに関する選択を求めるコンテンツは、選択確定前に利点・リスク・可能な結果を明確に示します。
利用者はアルゴリズムによって不利益や危害を受けません。
コンテンツ作成者はAIモデルを、一般人口に比例した代表的かつ偏りのない障害関連情報で訓練します。
コンテンツ作成者はユーザビリティテストや倫理レビューを実施し、アルゴリズムが障害のある人に不利益を与えないよう努めます。
利用者はヘルプを利用できます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者はコンテンツ作成者にフィードバックを提供できます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者はテキストの表示方法を制御できます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者はコンテンツの表示サイズや向きを変更して、閲覧および利用できるようにできます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者はコンテンツを変換して理解できるようにできます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者はメディアおよびメディア代替を制御できます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者は割り込みを制御できます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
利用者は潜在的な危害の原因を制御できます。
触覚フィードバックは減らしたりオフにしたりできます。
利用者は自身のユーザーエージェントや支援技術を含む設定からコンテンツの設定を制御できます。
このガイドラインの要件および判定基準は、まだ探索段階を超えていないためここには記載されていません。 候補の完全な一覧は編集者ドラフトをご覧ください。
このセクション（およびその小セクション）は、仕様への適合のために従うべき要件を提供します。すなわち、規定です。
非規定と明示されたセクションだけでなく、この仕様のすべての作成指針・図・例・注記も非規定です。それ以外の内容は規定です。
この文書内のキーワード MAY および MUST は、 BCP 14 [RFC2119] [RFC8174] に記載されたとおり、 ここに示すようにすべて大文字の場合のみ、解釈されます。
適合性のやさしいまとめ
あなたのコンテンツや製品がWCAG 3.0の指針を満たしていると主張したい場合があります。指針を満たしていれば「適合」と呼びます。
正式な適合主張をしたい場合は、この文書で説明されている手順を使用する必要があります。適合主張は必須ではなく、主張しなくてもWCAG 3.0に適合することは可能です。
この文書には2種類のコンテンツがあります：
WCAG 3.0ではさまざまな適合アプローチを試行中です。十分な指針が揃ったら、それぞれの有効性をテストします。
適合性
のまとめ終わり
WCAG 3.0は、要件を満たすためにWCAG 2.2とは異なる適合モデルを採用します。適合モデルの開発と検証は、今後数年AGが完了すべき大きな作業です。
AGは基本要件・補足要件・判定基準に基づくモデルを検討中です。
最も基本的な適合レベルは、すべての基本要件を満たすことが必要です。このセットはWCAG 2.2のLevel AAにある程度相当します。
より高い適合レベルは、補足要件や判定基準によって定義され、達成されます。AGは、高レベルの達成方法として、ポイント、割合、または事前定義された要件セット（モジュール）で運用するのが最適かどうかを検討します。
他の適合概念として、適合レベル・課題の重大度・形容詞評価・事前評価チェックなどもAGで引き続き検討します。
詳細は W3Cアクセシビリティ指針（WCAG）3.0の解説をご覧ください。「支援技術に対応」とは、多様なユーザーエージェントや利用状況を考慮する概念です。作成者がある指針を満たす技術的手法が、実際に利用者が使うユーザーエージェントで機能するかどうか、どう判断すれば良いでしょうか？
ユーザーエージェントでのテスト責任は、適合レベルによって変わるよう設計されています。
基本レベルの適合では、作成者はWCAG 3.0で提供される手法・技術が機能するという前提で進めることができます。高い適合レベルでは、作成者が技術の動作をテストしたり、利用可能なユーザーエージェントが要件を満たすか確認したり、その両方を組み合わせる必要がある場合があります。
このアプローチにより、ワーキンググループは、採用する手法・技術が十分広く国際的にユーザーエージェント対応していること、各要件を満たす十分な技術が存在することを保証できます。
WCAG 3.0では、支援情報付きで手法・技術をタグ付けできるコンテンツ管理システムの導入を想定しています。また、関係者が情報を提供できる仕組みも設ける予定です。
「アクセシビリティサポートセット」は、高い適合レベルでテスト対象のユーザーエージェントや支援技術を定義するために使われます。これは適合主張に含めることができ、WCAG 3.0で提供されていない技術を作成者が利用できるようにします。
支援技術で長年存在する不具合への例外は、現在も検討中です。
コンテンツのアクセシビリティ評価には、WCAG 3.0の指針を特定の範囲に適用する必要があります。範囲はデジタル製品全体の場合もありますが、通常は全体の部分集合です。理由は次の通りです：
そのためWCAG 3.0では、コンテンツの範囲を「ビュー」と「プロセス」で定義します。評価は1つ以上の完全なビューまたはプロセス単位で行い、適合は1つ以上の完全なビューまたはプロセス単位で判定します。
適合はプロセスおよびビュー単位で定義されます。主張は1つのプロセスと1つのビュー、一連のプロセスとビュー、または複数の関連するプロセスとビューをカバーすることができます。プロセス内のすべての固有ステップはビューの集合にMUST含める必要があります。プロセス外のビューもMAY範囲に含めることができます。
代表抽出（サンプリング）は、大規模・複雑なサイトでアクセシビリティ評価に重要な戦略であることを認識しています。本書では現時点では扱いませんが、将来的には本書内または別文書で、ガイドラインが勧告候補段階に進む前に取り扱う予定です。WCAG 3.0に代表抽出を組み込む最適な方法について、ご意見・フィードバックを歓迎します。
このセクション（およびその小セクション）は、仕様に適合するために従うべき要件を提供します。つまり、規定です。
ここで定義される多くの用語には一般的な意味があります。用語が定義へのリンクとともに現れる場合、その意味はここで正式に定義されたものです。用語が定義へのリンクなしに現れる場合、その意味はここでの正式な定義と明示的には関連しません。これらの定義は作業中であり、文書の進展に伴い発展する可能性があります。
この用語集には、成熟度レベルが「開発中」以上に到達したコンテンツで使用される用語が含まれます。定義自体にも成熟度レベルが含まれ、参照するコンテンツとは異なるペースで成熟する場合があります。AGWG は他のタスクフォースやグループと連携し、可能な限り文書間で用語の統一を図ります。
その言語の一部として定着していない、単語・語句・名称の短縮形
これには頭字語（initialisms）、アクロニム（acronyms）、ニューロニム（numeronyms）が含まれます。
一部の企業は、かつて頭字語だったものを社名として採用しています。この場合、新しい社名は（例：Ecma）のような文字列となり、その語はもはや略語とは見なされません。
テストに使用するユーザーエージェントおよび支援技術のグループ
AGWG は、ガイドライン検証時に使用するユーザーエージェントと支援技術のデフォルトセットの定義を検討しています。
アクセシビリティサポートセットは、言語・地域・状況に応じて異なる場合があります。
デフォルトのアクセシビリティセットを使用しない場合は、適合報告書に使用しているセットを示してください。
各オペレーティングシステムにおいて、少なくとも 2 つの主要な無償ブラウザでサポートされ、かつ／または各 OS で使用される各種 AT について、それぞれの AT の累計で AT 利用者の 80% によって利用可能であること
ユーザーが読み、含まれる操作可能な項目を使用できる状態で利用可能であること
アクセシビリティ向上のために、コンテンツまたは製品の開発・保守において実践される手順に関し、個人または組織に帰属する事実の正式な主張
ユーザーエージェントとして、または一般的なユーザーエージェントと併用して動作し、一般的なユーザーエージェントが提供するものを超えて、障害のあるユーザーの要件を満たす機能を提供するハードウェアやソフトウェア
支援技術が提供する機能には、代替提示（例：合成音声や拡大表示）、代替入力手段（例：音声）、追加のナビゲーション／把握の仕組み、コンテンツ変換（例：表をよりアクセシブルにする）などが含まれます。
支援技術は、API を利用・監視することで、一般的なユーザーエージェントとデータやメッセージのやり取りを行うことがよくあります。
一般的なユーザーエージェントと支援技術の区別は絶対的ではありません。多くの一般的なユーザーエージェントは、障害のある個人を支援する機能をいくつか備えています。基本的な違いは、一般的なユーザーエージェントは通常、障害の有無を含む広く多様な利用者を対象としている一方、支援技術は特定の障害を持つより狭く定義された利用者集団を対象としている点です。支援技術による支援は、対象ユーザーのニーズにより特化し適切です。一般的なユーザーエージェントは、プログラムオブジェクトからウェブコンテンツを取得したり、マークアップを識別可能な単位に解析したりするなど、支援技術に重要な機能を提供することがあります。
音の再生技術
オーディオは、合成（音声合成を含む）、実世界の音の録音、またはその両方で作成できます。
メインのサウンドトラックだけでは理解できない重要な視覚情報を説明するために、サウンドトラックに追加されるナレーション
視聴覚メディアでは、オーディオディスクリプションは、動作、登場人物、場面転換、画面上のテキスト、その他の視覚的コンテンツに関する情報を提供します。
オーディオディスクリプションは、「ビデオディスクリプション」「デスクリブドビデオ」「ビジュアルディスクリプション」「ディスクリプティブナレーション」と呼ばれることもあります。
標準的なオーディオディスクリプションでは、既存の会話の合間の静止時間にナレーションを追加します。拡張オーディオディスクリプションも参照してください。
重要な視覚情報がすでにメインのオーディオトラックで提供されている場合、追加のオーディオディスクリプショントラックは不要です。
ソフトウェアツールを用いて実施される評価で、通常はコードレベルの特徴を評価し、その他のテストにヒューリスティクスを適用します
自動テストは、人間の判断や経験を伴う他の種類のテストと対比されます。半自動評価は、機械が人間を必要な検査箇所へ導くことを可能にします。機械学習によるテストという新興分野は、この定義には含まれません。
注意を引くことを意図して、2 つの視覚状態の間を行き来させること
flashも参照。十分に大きく、適切な周波数で明るく点滅する場合、フラッシュとしても分類されることがあります。
テキストの複数文
カメラをモーションセンサーとして用い、あらゆる種類のジェスチャ（例：「空中」でのジェスチャ）を検出して制御すること
これは、例えばウェブページ上の静的な QR コード画像は含みません。
視聴覚コンテンツの、音声と言語以外のオーディオ部分の両方に対する、同期された視覚的および／またはテキスト代替
クローズドキャプションは、一部のプレーヤーでオン／オフ可能な同等情報で、しばしば支援技術で読み取ることができます。
オープンキャプションは、プレーヤーでオフにできないキャプションです。例えば、キャプションが動画に埋め込まれたテキストの視覚的同等画像である場合などです。
オーディオディスクリプションは、視覚的にすでに提示されている情報の説明であるため、キャプション化が必要な場合と不要な場合があります。
国によっては、キャプションを字幕と呼ぶことがあります。「subtitles」という用語は、音声コンテンツの翻訳版を提示するキャプションを指す場合にもよく使われます。
ほとんど、またはすべてのアプリケーションやプラットフォームで共通のキーボードナビゲーション手法であり、キーボードのみでナビゲートする必要があるユーザーが依拠できる手法
作成者が用いるのに十分な共通キーボードナビゲーション手法の一覧は、WCAG の共通キーボードナビゲーション手法リストにあります。
単一ポインター入力以外のあらゆるポインター入力
特定の機能のための要素のグループ
ガイドラインのすべての要件を満たすこと。正式な適合主張を行わない場合でも、ガイドラインに従ううえで適合は重要です。
詳細は、適合性セクションを参照してください。
インターフェイスによってユーザーに伝達される情報と感覚的体験。コンテンツの構造・提示・相互作用を定義するコードやマークアップを含む。
美的目的のみに供し、情報を提供せず、機能も持たないもの
テキストは、その目的を変えずに単語を並べ替えたり置き換えたりできる場合にのみ、純粋に装飾的といえます。
通常は特定の代替に置き換えるために、時代遅れで段階的に廃止中であると宣言すること
非推奨の文書は、使用が推奨されず、将来的に存在しなくなる可能性があります。
コンテンツを理解するのに必要な、音声・非音声の音声情報および視覚情報のテキスト版。
ポインターのトリガー刺激が押下されたときに発生するプラットフォームイベント
down イベントはプラットフォームによって名称が異なる場合があります（例：「touchstart」や「mousedown」）。
その方法以外では機能を実行できない、または機能自体を根本的に変えてしまうために設けられる例外
コンテンツがこれらのガイドラインに適合しているかを精査するプロセス
評価のアプローチには、自動評価、半自動評価、人手による評価、ユーザビリティテストがあります。
オーディオディスクリプションを追加する時間を確保するため、動画を一時停止して視聴覚メディアにオーディオディスクリプションを追加する手法
この手法は、追加のオーディオディスクリプションがないと動画の意味が失われ、かつ会話やナレーションの間の停止時間が短すぎる場合にのみ使用されます。
視覚メディア作品に付随し、ページ上で常に表示されるタイトル、短い説明、またはコメント
相対輝度の反対方向の変化の一対で、十分に大きく適切な周波数帯で発生すると、一部の人に発作を引き起こす可能性があるもの
許可されないフラッシュの種類に関する情報は、一般フラッシュおよび赤色フラッシュの閾値を参照してください。
blinking も参照。
個々の能力における特定の不足、または能力と設計された環境や状況との間の特定のミスマッチを記述する文
フラッシュまたは急速に変化する画像シーケンスが、以下のいずれかに該当する場合、その閾値未満（すなわち、コンテンツは適合）となります：
定義：
例外：白色雑音や、1 辺が 0.1 度（典型的な閲覧距離における視野）未満の「正方形」からなる交互のチェッカーボードパターンのような細かく均衡の取れたパターンによる点滅は、閾値に違反しません。
一般的なソフトウェアやウェブコンテンツでは、1024 × 768 ピクセルで表示した際に画面内の任意の場所で 341 × 256 ピクセルの矩形を用いることで、標準的な画面サイズと閲覧距離（例：15–17 インチの画面を 22–26 インチの距離）における 10 度の視野の良い推定が得られます。この 75–85 ppi の解像度は、CSS 仕様の名目上の CSS ピクセル解像度 96 ppi より低く（すなわちより保守的）であることが知られています。同じレンダリングのコンテンツを表示する高解像度ディスプレイでは、より小さく安全な画像となるため、閾値の定義にはより低い解像度が使用されます。
遷移とは、時間に対する相対輝度（赤色点滅の場合は相対輝度／色）の測定値のプロットにおいて、隣接するピークと谷の間の相対輝度（赤色点滅では相対輝度／色）の変化を指します。フラッシュは 2 つの反対方向の遷移で構成されます。
「飽和した赤を伴う反対方向の遷移の一対」（WCAG 2.2 より）に関する分野での新しい作業定義は、一方の遷移が R/(R + G + B) の値が 0.8 以上の状態への遷移（またはその逆）であり、かつ状態間の差が CIE 1976 UCS 色度図において 0.2（無次元）を超える反対方向の遷移の一対です。[ISO_9241-391]
動画の画面キャプチャから解析を行うツールが利用可能です。ただし、任意の 1 秒間の点滅が 3 回以下であれば、この条件の評価にツールは必要ありません。コンテンツは自動的に適合します（上記 #1 および #2 を参照）。
テクノロジーに伝えるために行われる、身体または身体の一部の動き
要件を整理するために用いられる、高レベルで平易な言葉による成果の記述
ガイドラインは、管理者、政策立案者、アクセシビリティ初心者、技術的詳細に踏み込む必要のないその他の人々に向けて、高レベルで平易な言葉による成果の記述を提供します。専門家でなくても概念を学び理解できるよう、要件をわかりやすく整理・提示します。
各ガイドラインには、固有で説明的な名称と、高レベルで平易な言葉による要約が含まれます。ガイドラインは、コントラスト、フォーム、可読性などの特定トピックにおける機能的ニーズに対応します。
ガイドラインは関連する要件をグループ化し、技術に依存しません。
人が実施する評価で、完全には自動評価できないテストに人間の判断を適用するのが一般的です
人による評価は、機械のみで行う自動評価と対比されます（ただし、機械が人間を検査が必要な箇所へ導くことを可能にする半自動評価を含む）。人による評価はコンテンツの特徴を検査するのに対し、ユーザビリティテストは、コンテンツを使用するユーザーの体験を直接テストします。
定義予定。
ユーザー入力に応答し、明確なプログラムによって判定可能な名前を持つ要素
非インタラクティブ要素と対照的。例えば、見出しや段落など。
テスト範囲の最小のテスト可能単位
キーボード操作が影響を与えるcontent内のポイント
ソフトウェアが「キー入力」を取得するAPI（アプリケーションプログラミングインターフェース）
「キー入力」は、「keyboard interface」からソフトウェアに渡され、スキャンプログラム、sip-and-puffモールス信号ソフト、音声認識ソフト、様々なAI、また他のキーボード代替や特殊キーボードなど、多様なソースから提供される場合があります。
結果を達成するためのprocessまたは技法
メカニズムはコンテンツ内で明示的に提供される場合もあれば、ユーザーエージェントや、支援技術などによって提供される場合もあります。
mechanismは、主張された適合レベルのすべての要件を満たす必要があります。
音声、動画、音声動画コンテンツに対する代替形式（通常はテキスト）。例：captions、audio descriptions、descriptive transcripts
技術固有または技術非依存の詳細情報で、requirementを満たす方法や、test・スコア情報を記載する
ユーザー入力に反応せず、サブパーツを含まない要素
段落にリンクが含まれる場合、リンクの両側のテキストは静的要素と見なされますが、段落全体は対象外となります。
テキスト内の文字は「より小さい部分」とは見なされません。
標準的または辞書的な意味を超えて、より深い複雑な考えを表現するために使われる語句
これは比喩的言語とも呼ばれます。
コンテンツを理解するには、ユーザーは単語の文字通りまたは直接的な意味だけでなく、暗示された意味を解釈する必要があります。
例：
適合のために必要な指示が含まれたcontent
HTTPを使って単一のURIから取得された埋め込まれていないリソースと、それと共に表示される、または表示される予定の他のリソース
URIが利用可能で、ユニークなコンテンツセットを表す場合、それが推奨される適合単位となります。
ポインター入力の終点だけでなく、その経路に依存するジェスチャー
Path-based gestureには、時間依存・非時間依存のパスベースジェスチャーの両方が含まれます。
対象ソフトウェアの下位に位置し、サービスを提供するソフトウェアまたはそのレイヤー集合で、対象ソフトウェアをハードウェア、ドライバー、その他下位ソフトウェアから分離する
Platformソフトウェアは、対象ソフトウェアが様々なハードウェアで動作しやすくし、また多くのサービス（関数、ユーティリティ、ライブラリなど）を提供することで、より簡単に開発・更新・他のソフトウェアとの統一的な動作を実現します。
特定のソフトウェアコンポーネントは、状況によってplatformの役割を果たす場合もあれば、clientになる場合もあります。例えば、ブラウザはページコンテンツに対するplatformですが、下位のOSに依存しています。
platformは、productが存在するコンテキストです。
定義予定。
プライベートおよびセンシティブな情報
ユーザーの操作に関連するviewやpageの一連で、活動完了に必要な操作が、順序に関係なく、様々な技術やサイト・ドメインをまたいで行われる場合もある。
テスト範囲であり、items、views、task flowsすべての組み合わせでウェブサイト、ページ群、ウェブアプリなどを構成する。
productのコンテキストはplatformです。
コンテンツの意味や重要な属性が、accessibility supportedなソフトウェア機能で判定できること
ページ上の静的コンテンツが、ユーザーに動きを感じさせるもの
色空間の任意の点の相対的な明るさ。最も暗い黒は0、最も明るい白は1に正規化される。
sRGB色空間では、relative luminanceは次式で定義される：L = 0.2126 * R + 0.7152 * G + 0.0722 * B ここで R、G、Bは以下の通り：
RsRGB、GsRGB、BsRGBは以下の通り：
「^」はべき乗演算子。（式は[SRGB]より）
2021年5月以前は定義値が0.04045ではなく0.03928でした。古い仕様から引用されていましたが、更新されました。このガイドラインの文脈では計算には実質的な影響はありません。
現在ウェブコンテンツの表示に使用されるほぼ全てのシステムはsRGBエンコーディングを前提としています。他の色空間が使われることが分かっていない限り、著者はsRGB色空間で評価すべきです。
配信後にディザリングが発生する場合は、元の色値を使用します。ソースでディザリングされる色は、ディザされる色の平均値（R、G、Bの平均）を使用します。
コントラストやフラッシュのテスト時に計算を自動で行うツールも利用可能です。
WCAG 2.2には、relative luminance定義をMathMLで示す別ページがあります。WCAG3への組み込みにはこれを考慮する必要があります。
障害者が経験する障壁を減らすまたは除去する実践の結果
1つ以上の関連したトピックや考えを扱う自己完結型のコンテンツ部分
sectionは1つ以上の段落で構成され、グラフィック、表、リスト、サブセクションを含む場合もあります。
機械が人間に検査が必要な箇所を案内するevaluation
semi-automated evaluationは、automated evaluationとhuman evaluationの両方の要素を含みます。
単一の「クリック」イベント、または「ボタン押下」と「ボタン離し」イベントのペアのみで間に動きがない入力イベント
simple pointer actionに該当しない例：ダブルクリック、ドラッグ操作、ジェスチャー、マルチポイント入力やジェスチャー、マウスとキーボードの同時使用。
ページや画面上で1度に1箇所のみターゲットとする入力モダリティ（例：マウス、タッチスクリーン上の1本指、スタイラス）
single pointer操作には、クリック、ダブルクリック、タップ、ドラッグ、1本指スワイプなどが含まれます。これに対し、multipoint操作は、タッチスクリーン上の2本指操作や、マウスとスタイラスの同時使用などです。
view上の1点のみをターゲットとする入力モダリティ（例：マウス、タッチスクリーン上の1本指、スタイラス）
single pointer操作には、クリック、ダブルクリック、タップ、ドラッグ、1本指スワイプなどが含まれます。multipoint操作は、タッチスクリーン上の2本指操作や、マウスとスタイラスの同時使用などです。
single pointer inputは、2本指・3本指以上や複数のポインターを同時に表面に触れたり、空中でジェスチャーするmultipoint inputとは異なります。
通常はクリックやタップによるアクティベーションですが、プログラムによるクリックやタップのシミュレーション、またはそれに類似する単純なアクティベーションでも可能です。
ほとんどのプラットフォームで共通であり、キーボードのみで操作する必要があるユーザーが依存するキーボードコマンド
著者が利用できる一般的なキーボードナビゲーション技術の十分なリストは、WCAG標準キーボードナビゲーション技術リストに掲載されています。
特定のユーザー活動をサポートする一連のviewを含むテスト範囲
methodの実装を評価する仕組み
人間の言語を表現する文字列であり、programmatically determinedであること
textが、非テキストコンテンツにprogrammatically associatedで紐付けられるか、そのテキストから参照されること
ポインターのトリガースティミュラスが離された時に発生するプラットフォームイベント
up eventは、プラットフォームによって異なる名前を持ちます（例： “touchend” や “mouseup”）。
productまたはprocessの利用体験を観察・フィードバックで評価するevaluation
外部コンテンツを取得し、ユーザーに提示するソフトウェア
ユーザーがデジタル手段でプロセスを開始する際の最終目標
ユーザーが調整可能なテキスト
これには以下の変更が含まれる場合がありますが、限定されません：
動く、または連続した画像や映像の技術
videoは、アニメーション画像や写真画像、または両方で構成される場合があります。
contentが、actively availableな状態でviewportに表示され、スクロールやパンで到達可能なもの、または展開によって追加されても他のコンテンツが同時にビューポート内で利用可能なもの。
モーダルダイアログボックスは新しいviewとなり、他のビューポート内コンテンツが利用できなくなります。
platformがコンテンツを表示するオブジェクト
著者はviewportを制御できず、ほとんどの場合画面に何が表示されているか分かりません（例：画面上の内容）。これはplatformによって提供され、ブラウザではハードウェアplatformがコンテンツから分離されています。
コンテンツは1つ以上のviewportで表示できます。viewportにはウィンドウ、フレーム、スピーカー、仮想拡大鏡などが含まれます。viewportは他のviewportを含む場合があります（例：ネストされたフレーム）。ユーザーエージェントによって作成されたプロンプト、メニュー、アラートなどのインターフェースコンポーネントはviewportとは見なされません。
この文書の内容は、プライバシーに関する考慮事項を特定するまで十分に成熟していません。 本ドラフトのレビュアーは、適合モデルの要件がプライバシーに影響を及ぼす可能性について検討してください。
この文書の内容は、セキュリティに関する考慮事項を特定するまで十分に成熟していません。 本ドラフトのレビュアーは、適合モデルの要件がセキュリティに影響を及ぼす可能性について検討してください。
このセクションは、2021年1月21日に最初の公開作業草案が発表されて以来、WCAG 3.0に加えられた重要な変更を示します。
WCAG 3.0のコミット履歴およびSilverのコミット履歴は参照可能です。
アクセシビリティガイドライン作業部会（AG WG）への参加に関する追加情報は、作業部会ホームページで確認できます。
Abi James、 Abi Roper、 Alastair Campbell、 Alice Boxhall、 Alina Vayntrub、 Alistair Garrison、 Amani Ali、 Andrew Kirkpatrick、 Andrew Somers、 Andy Heath、 Angela Hooker、 Aparna Pasi、 Ashley Firth、 Avneesh Singh、 Avon Kuo、 Azlan Cuttilan、 Ben Tillyer、 Betsy Furler、 Brooks Newton、 Bruce Bailey、 Bryan Trogdon、 Caryn Pagel、 Charles Hall、 Charles Nevile、 Chris Loiselle、 Chris McMeeking、 Christian Perera、 Christy Owens、 Chuck Adams、 Cybele Sack、 Daniel Bjorge、 Daniel Henderson-Ede、 Darryl Lehmann、 David Fazio、 David MacDonald、 David Sloan、 David Swallow、 Dean Hamack、 Detlev Fischer、 DJ Chase、 E.A. Draffan、 Eleanor Loiacono、 Filippo Zorzi、 Francis Storr、 Frankie Wolf、 Frederick Boland、 Garenne Bigby、 Gez Lemon、 Giacomo Petri、 Glenda Sims、 Graham Ritchie、 Greg Lowney、 Gregg Vanderheiden、 Gundula Niemann、 Hidde de Vries、 Imelda Llanos、 Jaeil Song、 JaEun Jemma Ku、 Jake Abma、 Jan Jaap de Groot、 Jan McSorley、 Janina Sajka、 Jaunita George、 Jeanne Spellman、 Jedi Lin、 Jeff Kline、 Jennifer Chadwick、 Jennifer Delisi、 Jennifer Strickland、 Jennison Asuncion、 Jill Power、 Jim Allan、 Joe Cronin、 John Foliot、 John Kirkwood、 John McNabb、 John Northup、 John Rochford、 John Toles、 Jon Avila、 Joshue O’Connor、 Judy Brewer、 Julie Rawe、 Justine Pascalides、 Karen Schriver、 Katharina Herzog、 Kathleen Wahlbin、 Katie Haritos-Shea、 Katy Brickley、 Kelsey Collister、 Kim Dirks、 Kimberly McGee、 Kimberly Patch、 Laura Carlson、 Laura Miller、 Len Beasley、 Léonie Watson、 Lisa Seeman-Kestenbaum、 Lori Oakley、 Lori Samuels、 Lucy Greco、 Luis Garcia、 Lyn Muldrow、 Makoto Ueki、 Marc Johlic、 Marie Bergeron、 Mark Tanner、 Mary Ann Jawili、 Mary Jo Mueller、 Matt Garrish、 Matthew King、 Melanie Philipp、 Melina Maria Möhnle、 Michael Cooper、 Michael Crabb、 Michael Elledge、 Michael Weiss、 Michellanne Li、 Michelle Lana、 Mike Beganyi、 Mike Crabb、 Mike Gower、 Nicaise Dogbo、 Nicholas Trefonides、 Nina Krauß、 Omar Bonilla、 Patrick H. Lauke、 Paul Adam、 Peter Korn、 Peter McNally、 Pietro Cirrincione、 Poornima Badhan Subramanian、 Rachael Bradley Montgomery、 Rain Breaw Michaels、 Ralph de Rooij、 Rashmi Katakwar、 Rebecca Monteleone、 Rick Boardman、 Roberto Scano、 Ruoxi Ran、 Ruth Spina、 Ryan Hemphill、 Sarah Horton、 Sarah Pulis、 Scott Hollier、 Scott O’Hara、 Shadi Abou-Zahra、 Shannon Urban、 Shari Butler、 Shawn Henry、 Shawn Lauriat、 Shawn Thompson、 Sheri Byrne-Haber、 Shrirang Sahasrabudhe、 Shwetank Dixit、 Stacey Lumley、 Stein Erik Skotkjerra、 Stephen Repsher、 Steve Faulkner、 Steve Lee、 Sukriti Chadha、 Susi Pallero、 Suzanne Taylor、 sweta wakodkar、 Takayuki Watanabe、 Tananda Darling、 Theo Hale、 Thomas Logan、 Thomas Westin、 Tiffany Burtin、 Tim Boland、 Todd Libby、 Todd Marquis Boutin、 Victoria Clark、 Wayne Dick、 Wendy Chisholm、 Wendy Reid、 Wilco Fiers。
これらの研究者はSilverの研究課題を選択し、研究を行い、結果の使用を快く許可してくださいました。
WCAG成功基準のユーザビリティ調査
IoT教育：障害のある学生への影響
UXプロフェッショナルによるWCAG利用
ウェブアクセシビリティ認識（ウースター工科大学の学生プロジェクト）
本出版物は、米国連邦資金の一部を、保健福祉省・障害者・自立生活・リハビリテーション研究所（NIDILRR）から、契約番号ED-OSE-10-C-0067、HHSP23301500054C、現在はHHS75P00120P00168のもとで支援されています。本出版物の内容は、米国保健福祉省や米国教育省の見解や方針を必ずしも反映するものではなく、商品名、商業製品、組織の言及が米国政府による推薦を意味するものではありません。
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: