併せて 翻訳 もご覧ください。
Copyright © 2020-2024 World Wide Web Consortium. W3C® liability, trademark and document use rules apply.
ウェブコンテンツアクセシビリティガイドライン (WCAG) 2.2 は、ウェブコンテンツをよりアクセシブルにするための幅広い推奨事項を示しています。これらのガイドラインに従うことで、視覚障害や弱視、聴覚障害や難聴、運動機能の制限、発話障害、光過敏症、これらの組み合わせ、さらに学習障害や認知機能の制限に対する一部の配慮など、より多くの障害を持つ人々にとってコンテンツがアクセスしやすくなります。ただし、これらの障害を持つすべての人のニーズに対応できるわけではありません。これらのガイドラインは、デスクトップ、ノートパソコン、キオスク、モバイルデバイスなど、あらゆる種類のデバイス上でのウェブコンテンツのアクセシビリティに対応しています。これらのガイドラインに従うことで、一般のユーザーにとってもウェブコンテンツの使いやすさが向上する場合があります。
WCAG 2.2 の達成基準は、技術に依存しないテスト可能な文として書かれています。特定の技術で達成基準を満たすためのガイダンスや、達成基準の解釈に関する一般的な情報は、別の文書で提供されています。入門および WCAG の技術的・教育的資料へのリンクについては、ウェブコンテンツアクセシビリティガイドライン (WCAG) 概要をご覧ください。
WCAG 2.2 は ウェブコンテンツアクセシビリティガイドライン 2.1 [WCAG21](2018年6月にW3C勧告として公開)を拡張するものです。WCAG 2.2 に準拠したコンテンツは、WCAG 2.0 および WCAG 2.1 にも準拠しています。WG は、WCAG 2.0 または WCAG 2.1 への準拠を求めるポリシーに対し、WCAG 2.2 が代替手段となることを意図しています。WCAG 2.2 の公開は WCAG 2.0 や WCAG 2.1 を廃止または置き換えるものではありません。WCAG 2.0 および WCAG 2.1 が現行標準のままである一方、W3Cはアクセシビリティの今後の適用性を最大化するため WCAG 2.2 の利用を推奨します。また、ウェブアクセシビリティポリシーの策定や更新時には、WCAG の最新バージョンの利用を推奨しています。
このセクションは、本書が公開された時点での文書のステータスについて説明します。現行のW3C 公開文書や本技術報告書の最新改訂版は、W3C技術報告書一覧(https://www.w3.org/TR/)でご覧いただけます。
ご意見は、W3C WCAG GitHub リポジトリで課題として提出 してください。本書の提案達成基準は議論を追跡する課題を参照していますが、公開コメントは個別の課題として新規提出するようワーキンググループはお願いしています。課題提出のために GitHub アカウントを無料で作成できます。GitHub での提出が難しい場合は、public-agwg-comments@w3.org (コメントアーカイブ) までメールをお送りください。
本書は、アクセシビリティガイドラインワーキンググループによって 勧告トラックを用いて勧告として公開されました。
W3Cは、本仕様をウェブの標準として広く展開することを推奨します。
W3C勧告は、広範なコンセンサス形成の後にW3Cおよび会員によって承認され、 ワーキンググループ会員から ロイヤリティフリーライセンス に対するコミットメントがあります。
本書は、W3C 特許ポリシーの下で活動するグループによって作成されました。 W3Cは、 グループ成果物に関連する特許開示の公開リスト を維持しており、そのページには特許開示方法の案内も掲載されています。個人が本書に関連する特許を実際に知っている場合は、 必須クレーム とみなす場合、W3C 特許ポリシー第6節に従って情報を開示する必要があります。
本書は 2023年11月3日 W3Cプロセス文書 に基づいて管理されています。
このセクションは規範的ではありません。
ウェブコンテンツアクセシビリティガイドライン(WCAG)2.2は、障害のある人々がウェブコンテンツをより利用しやすくする方法を定義しています。アクセシビリティには、視覚、聴覚、身体、発話、認知、言語、学習、神経障害など、幅広い障害が関わります。これらのガイドラインは多くの課題を網羅していますが、すべての種類や程度、組み合わせの障害者のニーズを満たすことはできません。また、高齢化による能力変化を伴う高齢者にもウェブコンテンツをより使いやすくし、一般ユーザーのユーザビリティ向上にも役立ちます。
WCAG 2.2は、W3Cプロセスを通じて、世界中の個人や組織と協力して開発されており、国際的な個人、組織、政府のニーズを満たす共通のウェブコンテンツアクセシビリティ標準の提供を目指しています。WCAG 2.2は、WCAG 2.0 [WCAG20]やWCAG 2.1 [WCAG21]に基づき、さらにWCAG 1.0 [WAI-WebCONTENT]を土台としており、現行および将来のさまざまなウェブ技術に幅広く適用できるよう設計され、機械的なテストと人による評価の組み合わせで検証可能となっています。WCAGについての入門は、ウェブコンテンツアクセシビリティガイドライン(WCAG)概要をご覧ください。
認知、言語、学習障害に対応する追加基準を定義する際には、開発期間の短さ、テスト可能性・実装容易性・国際的合意形成の課題など、重大な困難に直面しました。今後のWCAGのバージョンでもこの分野の作業は継続されます。著者の皆様には、学習・認知障害者、弱視者などのインクルージョン向上のための補足ガイダンスも参照することを推奨します。
ウェブアクセシビリティは、アクセシブルなコンテンツだけでなく、アクセシブルなウェブブラウザやその他のユーザーエージェントにも依存します。オーサリングツールもウェブアクセシビリティに重要な役割を果たします。ウェブ開発とインタラクションの各要素がどのように連携するかの概要は、以下を参照してください:
この文書で「WCAG 2」と記載されている場合は、2で始まるすべてのWCAGバージョンを指します。
WCAGを利用する個人や組織はウェブデザイナーや開発者、政策立案者、購買担当者、教員、生徒など非常に幅広いです。この多様な利用者のニーズを満たすため、全体的な原則、一般的なガイドライン、テスト可能な達成基準、そして豊富な十分な達成方法、助言的達成方法、よくある失敗例(例、参考リンク、コード付き)など、複数の階層のガイダンスが提供されています。
原則 - 最上位にはウェブアクセシビリティの基礎となる4つの原則:知覚可能、操作可能、理解可能、堅牢があります。詳細はアクセシビリティの4原則の理解を参照してください。
ガイドライン - 原則の下にガイドラインがあります。13のガイドラインは、障害の異なるユーザーにコンテンツをよりアクセシブルにするために著者が目指すべき基本目標を提供します。ガイドライン自体はテスト可能ではありませんが、達成基準の理解や達成方法の実装を助ける枠組みと全体目標を提供します。
達成基準 - 各ガイドラインには、要求や適合試験が必要な場面(設計仕様、購買、規制、契約など)で使えるテスト可能な達成基準が設定されています。異なるグループや状況のニーズを満たすため、適合レベルはA(最低)、AA、AAA(最高)の3段階です。WCAGレベルの詳細は適合レベルの理解をご覧ください。
十分な達成方法・助言的達成方法 - WCAG 2.2文書内の各ガイドラインや達成基準に対して、ワーキンググループは多様な達成方法を記載しています。達成方法は情報提供目的であり、十分な方法(達成基準を満たすために十分なもの)と助言的な方法(達成基準を超えてガイドラインにより良く対応するもの)の2つに分類されます。助言的達成方法は、テスト可能な達成基準でカバーされないアクセシビリティの障壁にも対応します。よくある失敗例も記載されています。詳細はWCAG 2.2の十分な・助言的達成方法の理解をご参照ください。
これらすべてのガイダンス階層(原則、ガイドライン、達成基準、十分な・助言的達成方法)は連携して、コンテンツをよりアクセシブルにする方法を示します。著者は、可能な限り全ての階層(特に助言的達成方法も含め)を参照し適用することで、可能な限り幅広いユーザーのニーズに対応することが推奨されます。
最高レベル(AAA)に適合したコンテンツでも、認知・言語・学習分野など、すべての種類や程度、組み合わせの障害者にとってアクセシブルであるとは限りません。著者は、助言的達成方法や認知・学習障害者のための使いやすいコンテンツ作成など幅広い方法の検討、そして最新のベストプラクティスに関する適切な助言を受けることも推奨されます。メタデータは、ユーザーが自身のニーズに最適なコンテンツを見つける際に役立つ場合があります。
WCAG 2.2文書は、安定した参照可能な技術標準を必要とする人々のニーズを満たすよう設計されています。支援文書と呼ばれるその他の文書は、WCAG 2.2文書をもとに、新たな技術への適用方法など、他の重要な目的に対応するために作成されています。支援文書には以下が含まれます:
WCAG 2.2 の達成方法 - WCAG 2.2の全ガイドライン、達成基準、達成方法を著者がコンテンツ開発・評価時に活用できるカスタマイズ可能なクイックリファレンスです。WCAG 2.0、2.1、2.2の内容が含まれており、様々な条件で絞り込み可能です。
WCAG 2.2 の理解 - WCAG 2.2の理解と実装のためのガイド。各ガイドライン・達成基準ごとや主要トピックごとに短い「理解」文書があります。
WCAG 2.2 の達成方法集 - 各達成方法・よくある失敗例ごとに、説明・例・コード・テストが記載された個別文書のコレクションです。
WCAG 2 文書 - WCAG 2支援文書および補足ガイダンスの簡単な紹介です。
WCAG 2.2 の新着情報では、アクセシビリティ課題を示すペルソナの引用とともに新しい達成基準を紹介しています。
WCAG 2.2支援資料の説明については、ウェブコンテンツアクセシビリティガイドライン(WCAG)概要をご覧ください。教育リソースなどWCAG 2関連の補足資料、ウェブアクセシビリティのビジネス目的、ウェブサイトのアクセシビリティ向上のための計画実施、アクセシビリティ政策などの追加リソースは、WAIリソースに掲載されています。
WCAG 2.2は、一連のWCAG 2.2の要件を満たしており、これらは以前のWCAG 2バージョンからの要件を引き継いでいます。要件は全体のガイドライン構成を定め、後方互換性を保証します。ワーキンググループは、達成基準の受け入れ基準というより非公式な基準も用いて、達成基準がWCAG 2.0のスタイルと品質に近いものになるよう配慮しました。これらの要件によって、WCAG 2.2に盛り込める内容が制約されました。この制約は、WCAG 2のマイナーバージョンとしての性質を維持するために重要でした。
WCAG 2.2は、WCAG 2.1の作業を継続する目的で開始されました。主に認知・学習障害者、弱視者、モバイルデバイス利用者のためのアクセシビリティガイダンスの向上です。これらのニーズに対応する多くの方法が提案・評価され、そのうちいくつかがワーキンググループによって精査されました。WCAG 2.0から引き継いだ構造要件、提案の明確さや影響度、開発スケジュールなどによって、今回のバージョンに含まれる達成基準が決まりました。WCAG 2.2は、これらの分野のウェブコンテンツアクセシビリティガイダンスを段階的に前進させるものですが、すべてのユーザーニーズがこのガイドラインで満たされるわけではないことを強調しています。
WCAG 2.2はWCAG 2.1をベースにしており、後方互換性があります。つまり、WCAG 2.2に適合するウェブページは、WCAG 2.1に適合するページと同等以上のアクセシビリティを備えています。2.1や2.0からの要件が追加されており、WCAG 2.2では1つの達成基準(4.1.1 構文解析)が削除されています。ポリシーでWCAG 2.0や2.1への適合が求められる著者は、WCAG 2.2へコンテンツを更新することができますが、4.1.1については引き続きテストと報告が必要な場合があります。複数バージョンのガイドラインに準拠する場合、以下の追加事項に注意してください。
WCAG 2.2は、WCAG 2.1を拡張して新しい達成基準、定義、ガイドラインを追加しています。この追加的なアプローチにより、WCAG 2.2に適合するサイトはWCAG 2.1にも適合することが明確になります。アクセシビリティガイドラインワーキンググループは、形式的な義務が以前のバージョンを参照していても、WCAG 2.2を新しい適合目標として採用し、アクセシビリティ向上と将来の政策変更への備えを推奨しています。
WCAG 2.2で新たに追加された達成基準は以下の通りです:
新しい達成基準は、用語集にも追加された新しい用語を参照しており、これらも達成基準の規範的要件の一部となっています。
WCAG 2バージョンへの後方互換性が重要な実装者の混乱を避けるため、WCAG 2.2の新しい達成基準はガイドライン内の既存達成基準の末尾に追加されています。これにより、既存の達成基準の番号を変更する必要がなくなりますが、各ガイドライン内の達成基準は適合レベルによるグルーピングではなくなります。達成基準の順序は適合レベルに関する情報を示しておらず、適合レベル(A/AA/AAA)は達成基準自体の指標でのみ確認できます。WCAG 2.2 クイックリファレンスでは、達成基準を適合レベルごとに表示するなど、多様な絞り込み・並び替えが可能です。
WCAG 2.2はWCAG 2.0と同じ適合モデルを採用しています。WCAG 2.2に適合したサイトは、WCAG 2.0やWCAG 2.1にも適合することを意図しており、これによりWCAG 2.0や2.1を参照する政策の要件も満たしつつ、現行ウェブのユーザーのニーズにもより良く対応できます。
WCAG 2.2と並行して、アクセシビリティガイドラインワーキンググループは次世代のアクセシビリティガイドラインの開発を進めています。この成果は、WCAG 2のマイナーバージョンでは現実的でないほど大規模なウェブアクセシビリティガイダンスの再構築となる見込みです。研究重視・ユーザー中心の設計方法論に基づき、コンテンツ作成、ユーザーエージェントサポート、オーサリングツールサポートの役割も含め、最も効果的かつ柔軟な成果を目指しています。この作業は複数年に及ぶため、WCAG 2.2は現行ウェブの変化を反映した最新のウェブアクセシビリティガイダンスを提供する中間措置として必要です。ワーキンググループは、主要バージョンの完成まで、WCAG 2.2以降の短期間で追加支援バージョンも開発する可能性があります。
情報およびユーザーインターフェースコンポーネントは、ユーザーが知覚できる方法で提示されなければなりません。
非テキストコンテンツには、テキストによる代替を提供し、必要に応じて大きな文字、点字、音声、記号、より簡単な言語など、他の形式へ変換できるようにします。
(レベルA)
ユーザーに提示されるすべての非テキストコンテンツには、同等の目的を果たすテキストによる代替が提供されます。ただし、以下に挙げる状況を除きます。
非テキストコンテンツがコントロールやユーザー入力を受け付ける場合、その目的を説明する名前が付与されます。(コントロールや入力を受け付けるコンテンツの追加要件については、達成基準 4.1.2を参照してください。)
非テキストコンテンツが時間ベースのメディアの場合、少なくとも非テキストコンテンツの記述的識別をテキストによる代替で提供します。(メディアの追加要件については、ガイドライン 1.2を参照してください。)
非テキストコンテンツがテストや練習問題で、テキストで提示すると無効になる場合、少なくとも非テキストコンテンツの記述的識別をテキストによる代替で提供します。
非テキストコンテンツが主に特定の感覚体験を目的としている場合、少なくとも非テキストコンテンツの記述的識別をテキストによる代替で提供します。
非テキストコンテンツの目的が、コンテンツが人間によってアクセスされていることを確認する場合、非テキストコンテンツの目的を識別・説明するテキストによる代替が提供され、さまざまな感覚認知に対応したCAPTCHAの代替形式も提供されます。
非テキストコンテンツが純粋な装飾のみを目的とし、情報提供や機能を持たない場合、または視覚的フォーマットのみに使用されている場合、あるいはユーザーに提示されない場合、支援技術によって無視できるように実装されます。
時間ベースのメディアに代替手段を提供します。
(レベルA)
事前収録 音声のみ および事前収録の映像のみ メディアについて、以下が当てはまります。ただし、音声または映像がテキストのメディア代替であり、その旨が明確に表示されている場合は除きます。
時間ベースのメディアの代替が提供され、事前収録の音声のみコンテンツに対して同等の情報を提示します。
事前収録の映像のみコンテンツに対して、時間ベースのメディアの代替または音声トラックのいずれかが提供され、同等の情報を提示します。
(レベルA)
字幕 は、すべての事前収録 音声コンテンツが含まれる同期メディアに提供されます。ただし、メディアがテキストのメディア代替であり、その旨が明確に表示されている場合は除きます。
(レベルA)
時間ベースのメディアの代替または音声解説が、事前収録 映像コンテンツが含まれる同期メディアに提供されます。ただし、メディアがテキストのメディア代替であり、その旨が明確に表示されている場合は除きます。
(レベルAA)
(レベルAA)
(レベルAAA)
(レベルAAA)
前面音声の間に音声解説を挿入するための十分な間がない場合は、拡張音声解説が、すべての事前収録 映像コンテンツが含まれる同期メディアに提供されます。
(レベルAAA)
時間ベースのメディアの代替が、すべての事前収録 同期メディアおよびすべての事前収録の映像のみ メディアに提供されます。
(レベルAAA)
時間ベースのメディアの代替が、ライブ 音声のみ コンテンツに対して同等の情報を提示する形で提供されます。
情報や構造を損なうことなく、異なる方法(たとえばより単純なレイアウト)で提示できるコンテンツを作成してください。
(レベルA)
情報、構造、 および関係性が提示によって伝達される場合、 プログラムによって判別可能であるか、テキストで利用可能です。
(レベルA)
コンテンツが提示される順序によって意味が変わる場合、正しい読取順序が プログラムによって判別可能である必要があります。
(レベルA)
コンテンツの理解や操作のための指示は、形状、色、大きさ、視覚的な位置、向き、音など、構成要素の感覚的特徴のみに依存してはなりません。
色に関連する要件については、ガイドライン 1.4を参照してください。
(レベルAA)
コンテンツは、縦向きや横向きなど、特定の表示方向に限定して閲覧・操作できるようにしてはなりません。ただし、特定の表示方向が本質的である場合は除きます。
特定の表示方向が本質的である例としては、銀行の小切手、ピアノアプリ、プロジェクターやテレビ用のスライド、または仮想現実コンテンツ(横向きまたは縦向き表示に必ずしも限定されないもの)などがあります。
(レベルAA)
ユーザー情報を収集する各入力フィールドの目的は、次の場合にプログラムによって判別可能です:
(レベルAAA)
マークアップ言語で実装されたコンテンツでは、ユーザーインターフェースコンポーネント、アイコン、および領域の目的がプログラムによって判別可能です。
コンテンツをより見やすく、聞き取りやすくするために、前景と背景を分離するなど、ユーザーがコンテンツを認識しやすくします。
(レベルA)
情報を伝えたり、動作を示したり、応答を促したり、視覚的要素を識別するために、色のみを視覚的な手段として使用してはなりません。
この達成基準は色の知覚に特化しています。他の知覚手段については、ガイドライン 1.3(色やその他の視覚的提示のコーディングへのプログラム的アクセスを含む)で取り扱われています。
(レベルA)
ウェブページ上で3秒以上自動再生される音声がある場合、手段が提供されていて、音声を一時停止または停止できるか、音量をシステム全体の音量とは独立して調整できる手段が提供されている必要があります。
この達成基準を満たしていないコンテンツは、ページ全体の利用に支障をきたす可能性があるため、ウェブページ上のすべてのコンテンツ(他の達成基準を満たすために使われているかどうかに関わらず)がこの達成基準を満たす必要があります。適合要件 5: 非干渉も参照してください。
(レベルAA)
テキスト およびテキスト画像の視覚的提示は、コントラスト比が少なくとも4.5:1である必要があります。ただし、以下の場合は除きます:
大きなサイズ のテキストおよび大きなテキスト画像はコントラスト比が少なくとも3:1である必要があります。
非アクティブなユーザーインターフェースコンポーネントの一部、純粋な装飾、誰にも見えない、または他の重要な視覚的内容を含む画像の一部としてのテキストやテキスト画像にはコントラスト要件はありません。
ロゴやブランド名の一部であるテキストにはコントラスト要件はありません。
(レベルAA)
字幕 およびテキスト画像を除き、テキストは、支援技術を使わずに200%まで拡大でき、コンテンツや機能が失われない必要があります。
(レベルAA)
使用している技術で視覚的提示が可能な場合は、情報を伝えるためにテキストを使用し、テキスト画像は使用しません。ただし、以下の場合は除きます:
テキスト画像がユーザーの要望に合わせて視覚的にカスタマイズできる場合
特定のテキスト表現が情報伝達に本質的な場合
ロゴタイプ(ロゴやブランド名の一部のテキスト)は本質的とみなされます。
(レベルAAA)
テキスト およびテキスト画像の視覚的提示は、コントラスト比が少なくとも7:1である必要があります。ただし、以下の場合は除きます:
大きなサイズ のテキストおよび大きなテキスト画像はコントラスト比が少なくとも4.5:1である必要があります。
非アクティブなユーザーインターフェースコンポーネントの一部、純粋な装飾、誰にも見えない、または他の重要な視覚的内容を含む画像の一部としてのテキストやテキスト画像にはコントラスト要件はありません。
ロゴやブランド名の一部であるテキストにはコントラスト要件はありません。
(レベルAAA)
事前収録 音声のみのコンテンツで、(1) 主に前面で話し言葉が流れる場合、(2) 音声CAPTCHAや音声ロゴではない場合、(3) 主に歌唱やラップなど音楽的表現を目的とした発声ではない場合、次のいずれかを満たす必要があります:
音声に背景音が含まれていない。
背景音をオフにできる。
背景音が前面の話し言葉より少なくとも20デシベル低い(1~2秒程度の短い音は除く)。
「デシベル」の定義により、この要件を満たす背景音は前面の話し言葉の約4分の1の音量となります。
(レベルAAA)
複数文のテキストの視覚的提示について、以下を達成できる手段が用意されています:
コンテンツがこれらの値を使う必要はありません。要件は、ユーザーがこれらの提示方法を変更可能な手段が利用できることです。手段はブラウザや他のユーザーエージェントによって提供されても構いません。コンテンツ側で手段を用意する必要はありません。
一部の言語の書記体系では、可読性・判読性向上のために異なる提示方法が使われます。この達成基準で使われていない提示方法は、その書記体系のコンテンツでは使う必要はなく、そのまま適合できます。著者は自分の書記体系で可読性・判読性向上のためのガイダンスに従うことが推奨されます。
(レベルAAA)
テキスト画像は、純粋な装飾または特定のテキスト表示がテキストの情報伝達に本質的な場合のみ使用されます。
ロゴタイプ(ロゴやブランド名の一部のテキスト)は本質的とみなされます。
(レベルAA)
コンテンツは、情報や機能の損失なく、かつ2方向のスクロールを必要とせずに提示できます:
ただし、利用や意味のために2次元レイアウトが必要なコンテンツ部分は除きます。
320CSSピクセルは、400%ズーム時で1280CSSピクセル幅の開始ビューポート幅に相当します。横スクロールコンテンツ(縦書き等)の場合、256CSSピクセルは400%ズーム時で1024CSSピクセルの開始ビューポート高に相当します。
2次元レイアウトが必要なコンテンツの例は、理解に必要な画像(地図や図)、動画、ゲーム、プレゼンテーション、データテーブル(個々のセルは除く)、ツールバーを表示しながらコンテンツを操作する必要があるインターフェース等です。こうした部分には2次元スクロールを許可しても構いません。
(レベルAA)
以下の視覚的提示は、隣接する色に対してコントラスト比が少なくとも3:1である必要があります:
(レベルAA)
以下のテキスト スタイルプロパティをサポートするマークアップ言語で実装されたコンテンツにおいて、他のスタイルプロパティを変更することなく、以下すべてを設定してもコンテンツや機能が失われないこと:
例外:人間の言語や書記体系で、これらのテキストスタイルプロパティの一部または全部を使用しない場合は、該当するプロパティのみで適合できます。
コンテンツがこれらのテキスト間隔値を使う必要はありません。要件は、ユーザーが作成したテキスト間隔を上書きしてもコンテンツや機能が失われないことです。
一部の言語の書記体系では段落先頭のインデントなど、異なるテキスト間隔設定を使います。著者は可読性・判読性向上のため、現地のガイダンスに従うことが推奨されます。
(レベルAA)
ポインタのホバーやキーボードフォーカスを受けた際に追加コンテンツが表示・非表示になる場合、以下を満たす必要があります:
例外:追加コンテンツの視覚的提示がユーザーエージェントによって制御され、著者が変更していない場合。
カスタムツールチップ、サブメニュー、ホバーやフォーカスで表示される非モーダルポップアップなどは、この達成基準の対象となる追加コンテンツの例です。
この基準は、トリガーとなるコンポーネント自体に加えて表示されるコンテンツに適用されます。キーボードフォーカスで表示される隠れたコンポーネント(ページ内ジャンプリンク等)は追加コンテンツを表示するものではないため、この基準の対象外です。
ユーザーインターフェースコンポーネントおよびナビゲーションは操作可能でなければなりません。
すべての機能をキーボードで利用できるようにしてください。
(レベルA)
コンテンツのすべての機能は、個々のキー入力に特定のタイミングを求めることなく、キーボードインターフェースを介して操作可能です。ただし、根本的な機能がユーザーの移動経路に依存する入力(たとえば、終点だけでなく経路自体に意味がある操作)は除きます。
この例外は入力手法ではなく根本的な機能に関連します。例:手書き入力で文字を入力する場合、入力手法(手書き)は経路依存ですが、根本的な機能(テキスト入力)は経路依存ではありません。
これによりマウス入力や他の入力方法の提供を禁止・抑制するものではありません。キーボード操作に加えて他の入力方法を提供しても構いません。
(レベルA)
キーボードインターフェースを使ってページ上のコンポーネントにフォーカスを移動できる場合、キーボードインターフェースのみでそのコンポーネントからフォーカスを移動できなければなりません。また、矢印キーやTabキー等の標準的な方法以外で移動が必要な場合は、その方法をユーザーに通知する必要があります。
この達成基準を満たしていないコンテンツは、ページ全体の利用に支障をきたす可能性があるため、ウェブページ上のすべてのコンテンツ(他の達成基準を満たすために使われているかどうかに関わらず)がこの達成基準を満たす必要があります。適合要件 5: 非干渉も参照してください。
(レベルAAA)
コンテンツのすべての機能は、個々のキー入力に特定のタイミングを求めることなく、キーボードインターフェースを介して操作可能です。
(レベルA)
コンテンツで文字(大文字・小文字含む)、句読点、数字、記号のみで実装されたキーボードショートカットがある場合、以下のいずれかを満たす必要があります:
ユーザーがコンテンツを読む・利用するために十分な時間を提供してください。
(レベルA)
コンテンツによって設定された各時間制限について、少なくとも以下のいずれかを満たす必要があります:
ユーザーが時間制限に到達する前にオフにできる;または
ユーザーが時間制限に到達する前に、デフォルト設定の10倍以上の幅で調整できる;または
時間切れ前に警告し、「スペースキーを押す」など簡単な操作で少なくとも20秒延長でき、時間制限を少なくとも10回延長できる;または
時間制限がリアルタイムイベント(例:オークション)に必須であり、代替手段が不可能な場合;または
時間制限が本質的であり、延長すると活動自体が無効化される場合;または
時間制限が20時間を超えている場合。
この達成基準は、時間制限により予期しないコンテンツやコンテキストの変更でユーザーがタスクを完了できなくなることを防ぎます。この達成基準は、達成基準3.2.1(ユーザー操作によるコンテンツ・コンテキスト変更の制限)と併せて考慮してください。
(レベルA)
動き、点滅、スクロール、または自動更新情報について、すべて以下を満たす必要があります:
(1)自動で開始し、(2)5秒以上続き、(3)他のコンテンツと同時に提示される動き・点滅・スクロール情報については、手段が提供されていて、ユーザーが一時停止・停止・非表示できる必要があります(動き・点滅・スクロールが本質的な活動は除く);かつ
(1)自動で開始し、(2)他のコンテンツと同時に提示される自動更新情報については、ユーザーが一時停止・停止・非表示できるか、更新頻度を制御できる手段が提供されている必要があります(自動更新が本質的な活動は除く)。
点滅やフラッシュするコンテンツに関する要件は、ガイドライン2.3を参照してください。
この達成基準を満たしていないコンテンツは、ページ全体の利用に支障をきたす可能性があるため、ウェブページ上のすべてのコンテンツ(他の達成基準を満たすために使われているかどうかに関わらず)がこの達成基準を満たす必要があります。適合要件 5: 非干渉も参照してください。
ソフトウェアによって定期的に更新されたり、ユーザーエージェントにストリーム配信されるコンテンツは、一時停止から再開までに生成・受信された情報を保存・提示する必要はありません。技術的に不可能な場合、また多くの状況で誤解を生む可能性があります。
プリロードフェーズなどで発生するアニメーションは、すべてのユーザーがそのフェーズ中に操作できず、進行状況を示さないとコンテンツが固まったり壊れたと誤解される場合、本質的とみなせます。
(レベルAAA)
タイミングは、コンテンツが提示するイベントや活動の本質的な部分であってはなりません。ただし、非対話型同期メディアおよびリアルタイムイベントを除く。
(レベルAAA)
中断は、緊急事態を除き、ユーザーが延期または抑制できる必要があります。
(レベルAAA)
認証済みセッションが期限切れになった場合でも、再認証後にデータの損失なく活動を継続できます。
(レベルAAA)
データ損失につながるユーザー無操作の期間について、ユーザーに警告が表示されます(ただし、ユーザーが何もしなくても20時間以上データが保存される場合は除く)。
プライバシー規制により、ユーザー認証やデータ保存の前に明示的な同意が必要な場合があります。未成年者の場合、多くの法域・国・地域では明示的な同意取得が認められていません。データ保存でこの達成基準を満たそうとする際は、プライバシー専門家や法律顧問への相談が推奨されます。
発作や身体的反応を引き起こすことが知られている方法でコンテンツを設計しないでください。
(レベルA)
ウェブページには、1秒間に3回を超えて閃光するものが含まれていないか、閃光が一般閃光および赤閃光の閾値未満です。
この達成基準を満たしていないコンテンツは、ページ全体の利用に支障をきたす可能性があるため、ウェブページ上のすべてのコンテンツ(他の達成基準を満たすために使われているかどうかに関わらず)がこの達成基準を満たす必要があります。適合要件 5: 非干渉も参照してください。
(レベルAAA)
ウェブページには、1秒間に3回を超えて閃光するものが含まれていません。
(レベルAAA)
インタラクションによってトリガーされる動きのアニメーションは、アニメーションが本質的である場合や情報伝達に不可欠な場合を除き、無効化できる必要があります。
キーボード以外の様々な入力で機能を操作しやすくします。
(レベルA)
複数点や経路ベースのジェスチャで操作する機能は、経路ベースジェスチャを使わずに単一ポインタで操作できる必要があります。ただし、複数点や経路ベースジェスチャが本質的な場合は除きます。
この要件はポインタ動作を解釈するウェブコンテンツに適用されます(ユーザーエージェントや支援技術の操作に必要な動作には適用されません)。
(レベルA)
単一ポインタで操作できる機能について、以下のいずれかを満たす必要があります:
キーボードやテンキーのキー押下をエミュレートする機能は本質的とみなされます。
この要件はポインタ動作を解釈するウェブコンテンツに適用されます(ユーザーエージェントや支援技術の操作に必要な動作には適用されません)。
(レベルA)
ラベルにテキストやテキスト画像を含むユーザーインターフェースコンポーネントでは、名称に視覚的に提示されるテキストが含まれている必要があります。
ラベルのテキストを名称の先頭に置くことが推奨されます。
(レベルA)
デバイスやユーザーの動作で操作できる機能は、ユーザーインターフェースコンポーネントでも操作でき、誤作動防止のため動作への反応を無効化できる必要があります。ただし、
(レベルAAA)
ポインタ入力のターゲットのサイズが、44×44CSSピクセル以上である必要があります。ただし、以下の場合は除きます:
(レベルAAA)
ウェブコンテンツは、プラットフォームで利用可能な入力方法の利用を制限しません。ただし、制限が本質的である場合、コンテンツのセキュリティ確保に必要な場合、またはユーザー設定を尊重するために必要な場合は除きます。
(レベルAA)
新規
操作にドラッグ動作を使う機能は、ドラッグせずに単一ポインタで達成できる必要があります。ただし、ドラッグが本質的な場合や、機能がユーザーエージェントによって決定され著者が変更していない場合は除きます。
この要件はポインタ動作を解釈するウェブコンテンツに適用されます(ユーザーエージェントや支援技術の操作に必要な動作には適用されません)。
(レベルAA)
新規
ポインタ入力のターゲットのサイズが、24×24CSSピクセル以上である必要があります。ただし、以下の場合は除きます:
位置で値を選択するようなターゲットは、この達成基準上1つのターゲットとみなされます(例:スライダー、色グラデーションのカラーピッカー、編集領域でカーソル位置指定)。
文中ターゲットでは、行間はテキストの流れに対して垂直方向とみなします(例:縦書き言語の場合、行間は水平方向)。
情報およびユーザーインターフェースの操作は理解可能でなければなりません。
テキストコンテンツを読みやすく、理解しやすくします。
(レベルA)
各ウェブページのデフォルトの人間の言語がプログラムによって判別可能です。
(レベルAA)
コンテンツ内の各文や句の人間の言語がプログラムによって判別可能です。ただし、固有名詞、専門用語、言語不明の単語、周囲のテキストで慣用化された単語や句は除きます。
(レベルAAA)
特異な使い方や限定的な意味で用いられる語句(慣用句や専門用語を含む)の定義を特定する手段が提供されています。
(レベルAAA)
(レベルAAA)
固有名詞や肩書きを除いたテキストが中等教育初期レベルを超える読解力を要する場合、補足コンテンツまたは中等教育初期レベル以下の読解力で理解できるバージョンが提供されています。
(レベルAAA)
文脈によって意味が曖昧になる語句の発音を特定できる手段が提供されています。
ウェブページが予測可能な方法で表示・操作されるようにします。
(レベルA)
いずれかのユーザーインターフェースコンポーネントがフォーカスを受けても、コンテキストの変化を起こしません。
(レベルA)
いずれかのユーザーインターフェースコンポーネントの設定を変更しても、事前にその挙動が通知されていない限り、自動的にコンテキストの変化を起こしません。
(レベルAA)
(レベルAAA)
(レベルA)
新規
いずれかのウェブページに以下のヘルプ手段が含まれ、同じウェブページ群で繰り返される場合、ユーザーが変更しない限り他のページ内容との相対的な順序が同じです:
ヘルプ手段はページ上に直接提供されても、情報を含む別ページへの直接リンクで提供されても構いません。
この達成基準では「他のページ内容との相対的な順序」はページをシリアライズした際の順序として考えることができます。同じページバリエーション(例:CSSブレークポイント)では視覚的なヘルプ手段の位置も一貫しています。ユーザーがズームや向きを変更するとページバリエーションが変わることがありますが、この基準は同じバリエーション内のページ間の順序に関するものです。
ユーザーがミスを回避し、修正できるように支援します。
(レベルA)
入力エラーが自動的に検出された場合、エラーのある項目が特定され、そのエラーがテキストでユーザーに説明されます。
(レベルA)
ユーザー入力が必要なコンテンツにはラベルまたは説明が提供されています。
(レベルAA)
入力エラーが自動的に検出され、修正方法の提案が分かる場合、セキュリティやコンテンツの目的を損なわない限り、その修正方法がユーザーに提供されます。
(レベルAA)
ユーザーに法的な約束や財務取引を発生させるウェブページ、データ保存システム内のユーザーが管理可能なデータを変更・削除するページ、ユーザーテストの回答を送信するページでは、少なくとも以下のいずれかを満たす必要があります:
(レベルAAA)
コンテキストに応じたヘルプが提供されています。
(レベルAAA)
ユーザーが情報を送信する必要があるウェブページについて、少なくとも以下のいずれかを満たす必要があります:
(レベルA)
新規
同じプロセス内で再入力が必要な情報(ユーザーが以前入力または提供した情報)は、
ただし、以下の場合は除きます:
(レベルAA)
新規
認証プロセスのいずれかのステップで認知機能テスト(パスワード記憶やパズル解決など)が必要な場合、そのステップで以下のいずれかが提供されています:
「オブジェクト認識」や「個人コンテンツ」は画像、動画、音声で表される場合があります。
(レベルAAA)
新規
認証プロセスのいずれかのステップで認知機能テスト(パスワード記憶やパズル解決など)が必要な場合、そのステップで以下のいずれかが提供されています:
コンテンツは、支援技術を含む様々なユーザーエージェントによって解釈できるほど頑健でなければなりません。
支援技術を含む現行標準および将来のユーザーエージェントとの互換性を最大化してください。
この基準は元々、支援技術がHTMLを直接解析する際の問題を解決するために採用されましたが、支援技術はもはやHTMLを直接解析する必要がありません。そのため、これらの問題は既に解消されたか、他の基準で対処されています。この基準はもはや有用性がなく、削除されました。
(レベルA)
すべてのユーザーインターフェースコンポーネント(フォーム要素、リンク、スクリプト生成コンポーネント等を含む)について、 名称と役割がプログラムによって判別可能であり、状態・プロパティ・値がユーザーによって設定可能であり、これらの変更通知がユーザーエージェントや支援技術に通知されます。
この達成基準は主に、独自にユーザーインターフェースコンポーネントを開発・スクリプトするウェブ著者向けです。例えば、標準のHTMLコントロールは仕様通りに使用すれば既にこの基準を満たしています。
(レベルAA)
マークアップ言語で実装されたコンテンツにおいて、ステータスメッセージが役割やプロパティを通じてプログラムによって判別可能であり、支援技術によってフォーカス移動なしでユーザーに提示できます。
このセクションではWCAG 2.2への適合の要件をまとめています。また、適合宣言(オプション)の方法も案内しています。最後に、技術の利用方法がアクセシビリティ対応であることが必要であり、アクセシビリティ対応な技術利用のみが適合性の根拠となることについて説明します。適合性の理解ではアクセシビリティ対応の概念をさらに詳しく説明しています。
WCAG 2.2の主要な内容は規範的であり、適合宣言に影響する要件を定義します。序文や付録、「非規範」と明記されたセクション、図、例、注意書きは参考情報(非規範)です。非規範情報はガイドラインを解釈する助言を提供しますが、適合宣言に影響する要件にはなりません。
MAY、MUST、MUST NOT、NOT RECOMMENDED、RECOMMENDED、SHOULD、SHOULD NOTなどのキーワードは、[RFC2119]で説明される通りに解釈します。
ウェブページがWCAG 2.2に適合するには、以下すべての適合要件を満たす必要があります:
以下のいずれかの適合レベルを完全に満たします。
適合性は記載されたレベルのみで達成できますが、著者は、達成済みレベル以上の達成基準への進捗も(宣言内で)報告することが推奨されます。
ウェブサイト全体に対しレベルAAA適合を一般方針として要求することは推奨されません。AAA基準は一部の内容で満たすことができないためです。
適合 (および適合レベル)はページ全体についてのみ認められ、ウェブページの一部が除外されている場合は達成できません。
適合判定の目的では、ページ内の一部コンテンツの代替手段(例:動画の代替提示や詳細説明)は、ページから直接取得できる場合はページの一部とみなします。
著者の管理外コンテンツにより適合できない場合は、部分適合宣言を検討できます。
ページ全体には自動的に表示される各画面サイズのバリエーション(例:レスポンシブページのバリエーション)も含まれます。これら全てが適合(または適合する代替版がある)必要があります。
あるウェブページが、プロセス(活動達成に必要な一連のステップ)の一部である場合、プロセス内のすべてのページが指定レベル以上で適合する必要があります。いずれかのページが指定レベル未満の場合はそのレベルで適合できません。
アクセシビリティ対応な技術の利用のみが、達成基準の根拠として根拠とすることができます。アクセシビリティ対応でない方法で提供される情報や機能も、アクセシビリティ対応な方法で提供されている必要があります(アクセシビリティ対応の理解参照)。
技術がアクセシビリティ対応でない方法や非適合な方法で使われる場合でも、ユーザーがページの残り部分にアクセスできることを妨げてはなりません。また、以下の状況下でもウェブページ全体が各適合要件を満たし続ける必要があります:
さらに、以下の達成基準は、ページ上のすべてのコンテンツ(適合根拠外のコンテンツも含む)に適用されます。これらを満たさないとページの利用自体が妨げられる可能性があるためです:
ページが適合できない場合(例:適合テストページや例示ページ)は、適合範囲や適合宣言に含めることはできません。
詳細や例は、適合要件の理解を参照してください。
適合性はウェブページ単位で定義されますが、宣言は1ページ、複数ページ、関連する一連のページに対して行えます。
適合宣言は必須ではありません。宣言せずにWCAG 2.2に適合することもできます。ただし、宣言する場合は、以下の情報を必ず含める必要があります:
宣言対象のウェブページの簡潔な説明(URI一覧や、サブドメインの含有有無を含む)
ウェブページはURIの一覧や、すべての対象URIを表す式で記述できます。
インストール前にURIがないウェブ製品は、設置時に適合する旨の記載も可能です。
適合ロゴを使用する場合、それ自体が宣言となり、上記必要要素を添える必要があります。
必須要素に加え、ユーザーの助けになる追加情報の提供も推奨されます。推奨される追加情報として:
詳細や例は適合宣言の理解を参照してください。
メタデータ利用の詳細はメタデータの理解を参照してください。
後で追加コンテンツが加わるウェブページは「部分適合宣言」を利用できます。例:メールプログラム、ブログ、コメント付き記事、ユーザー投稿対応アプリ、複数の執筆者によるポータル・ニュースサイト、動的広告挿入など自動で他ソースから内容を追加するサイト等。
この場合、初回公開時点で管理外コンテンツが何か分からず、管理外コンテンツが管理下コンテンツのアクセシビリティにも影響し得るため、主に2つの選択肢があります:
最善の知識に基づき適合判定を行う。こうしたページを監視して修正(非適合コンテンツは2営業日以内に削除または適合化)する場合は、外部提供コンテンツの誤りが修正・削除されている限り、ページは適合とみなせます。監視・修正できない場合は宣言できません。
または
「部分適合宣言」:ページは適合しないが、特定部分を除けば適合する旨を宣言できます。宣言文例:「このページは適合しませんが、以下の管理外コンテンツを削除すればWCAG 2.2 レベルXに適合します。」また、宣言対象の管理外コンテンツについて:
「言語による部分適合宣言」は、ページが適合できないが、ページで用いられた言語に対してアクセシビリティ対応が存在すれば適合する場合に使えます。文例:「このページは適合しませんが、以下の言語に対してアクセシビリティ対応が存在すればWCAG 2.2 レベルXに適合します。」
このセクションは非規範です。
この仕様の達成基準のうち、ワーキンググループがプライバシー保護に関する影響がある、またはウェブサイト運営者がプライバシー保護設計時に考慮すべきと判断したものを以下に示します。これは現時点での理解であり、他にも未把握のプライバシー関連基準がある可能性もあります。
プライバシーに関連する可能性がある達成基準:
このセクションは非規範です。
この仕様の達成基準のうち、ワーキンググループがセキュリティ保護に関する影響がある、またはウェブサイト運営者がセキュリティ保護設計時に考慮すべきと判断したものを以下に示します。これは現時点での理解であり、他にも未把握のセキュリティ関連基準がある可能性もあります。
セキュリティに関連する可能性がある達成基準:
略語とは、語・句・名称の短縮形で、その略語が言語の一部として定着していないものを指します。
これには次のような頭字語やアクロニムが含まれます:
頭字語(initialism)は、名称や句の単語や音節の頭文字を取って作られる短縮形です。
すべての言語で定義されているわけではありません。
アクロニム(acronym)は、名称や句の頭文字や他の単語の一部から作られ、単語として発音されることもある略式表現です。
一部の企業は、元々頭字語だったものを会社名として採用しています。この場合、新しい会社名はその文字自体(例:Ecma)となり、単語として略語とはみなされません。
ユーザーの支援技術および、ブラウザーやその他のユーザーエージェントのアクセシビリティ機能によってサポートされていること。
Webコンテンツ技術(または技術の機能)のアクセシビリティ対応の利用と認められるためには、Webコンテンツ技術(または技術の機能)について、以下の1と2の両方を満たす必要があります:
Webコンテンツ技術の利用方法が、ユーザーの支援技術(AT)によってサポートされていなければなりません。 つまり、その技術の利用方法が、コンテンツの人間の言語で、ユーザーの支援技術との相互運用性がテストされていること。
かつ
Webコンテンツ技術には、ユーザーが利用できるアクセシビリティ対応のユーザーエージェントが存在しなければなりません。 これは、次の4つのいずれかの条件を満たしていることを意味します:
その技術が、広く普及しているアクセシビリティ対応のユーザーエージェント(例:HTMLやCSS)でネイティブにサポートされている。
または
その技術が、広く普及しているアクセシビリティ対応のプラグインでサポートされている。
または
コンテンツが大学や企業ネットワークなどの閉じた環境で提供されており、その技術に必要なユーザーエージェントが組織によって利用されていて、かつアクセシビリティ対応である。
または
その技術をサポートするユーザーエージェントがアクセシビリティ対応であり、次のようにダウンロードや購入が可能であること:
Accessibility Guidelines Working GroupおよびW3Cは、特定のWeb技術の利用がアクセシビリティ対応と分類されるために必要な支援技術によるサポートの範囲や量を指定していません。(「アクセシビリティ対応」サポートに必要な支援技術のレベルを参照。)
あるWeb技術が「アクセシビリティ対応」として利用されている場合でも、その技術全体やすべての利用方法がサポートされていることを意味するわけではありません。たとえばHTMLを含むほとんどの技術には、少なくとも1つの機能や利用方法にサポートがありません。WCAGに適合するページは、アクセシビリティ対応の利用方法だけがWCAG要件を満たすために依存できるものとなります。
複数のバージョンが存在するWebコンテンツ技術を引用する場合、サポートされているバージョンを指定する必要があります。
技術のアクセシビリティ対応の利用方法を見つける一つの方法として、アクセシビリティ対応であることが文書化された利用方法の集約を参照することが挙げられます(アクセシビリティ対応のWeb技術利用方法の理解を参照)。著者、企業、技術ベンダー等がWebコンテンツ技術のアクセシビリティ対応の利用方法を文書化する場合がありますが、文書内のすべての利用方法が上記のアクセシビリティ対応Webコンテンツ技術の定義を満たす必要があります。
時間依存の視覚・聴覚情報を正しい順序で記述したテキスト説明を含み、時間依存のインタラクションの目的を達成する手段を提供する文書。
同期メディアコンテンツの作成に利用された脚本は、編集後の最終的な同期メディアを正確に表すように修正されている場合のみ、この定義に該当します。
リンクやWebページで同時に表示されるすべての情報から目的が判断できない場合(すなわち、障害のない読者でもリンクをアクティブにするまで何が起こるかわからない場合)
文字やグリフ(主にASCIIで定義される95個の印刷可能文字)を空間的に並べて作成した絵。
ユーザーエージェントとして動作する、または主流のユーザーエージェントと組み合わせて動作し、障害のあるユーザーのニーズを満たすために主流のユーザーエージェントが提供する機能を超えた機能を提供するハードウェアおよび/またはソフトウェア。
支援技術が提供する機能には、代替表示(例:合成音声や拡大表示)、代替入力方法(例:音声)、追加のナビゲーションや案内機構、コンテンツ変換(例:表をよりアクセシブルにする)などがあります。
支援技術は、主流のユーザーエージェントとAPIを利用してデータやメッセージをやり取りする場合が多いです。
主流ユーザーエージェントと支援技術の区別は絶対的なものではありません。多くの主流ユーザーエージェントは、障害者向けの機能をいくつか提供しています。主流ユーザーエージェントは通常、障害のある人とない人を含む幅広い多様なユーザー層を対象としますが、支援技術は特定の障害を持つユーザーに特化しています。支援技術が提供する支援は、対象ユーザーのニーズにより適合しています。主流ユーザーエージェントは、Webコンテンツの取得やマークアップの解析など、支援技術に重要な機能を提供する場合があります。
音響再生技術
オーディオは、合成的に生成(音声合成を含む)、現実世界の音を録音、またはその両方で作成できます。
主音声トラックだけでは理解できない重要な視覚的情報を説明するためにサウンドトラックに追加されるナレーション
動画の音声解説は、動作、登場人物、場面転換、画面上のテキストおよびその他の視覚的コンテンツについて情報を提供します。
標準的な音声解説では、既存の対話の間のポーズにナレーションが追加されます。(拡張音声解説も参照)
すべての動画情報が既存のオーディオで既に提供されている場合、追加の音声解説は不要です。
「ビデオ解説」や「解説ナレーション」とも呼ばれます。
音声のみで構成される時間依存のプレゼンテーション(動画やインタラクションなし)
注意を引く目的で、2つの視覚状態の間で切り替わること
フラッシュも参照してください。十分な大きさで、十分に明るい点滅が適切な周波数で発生すると、フラッシュに分類されることもあります。
複数の文からなるテキスト
"Completely Automated Public Turing test to tell Computers and Humans Apart" の略称
CAPTCHAテストは、ユーザーに画像や音声ファイルで表示されたテキストを入力させることが多いです。
チューリングテストは、コンピューターと人間を区別するために設計されたシステムです。著名なコンピュータ科学者アラン・チューリングにちなんで命名され、カーネギーメロン大学の研究者によって用語が作られました。
メディアコンテンツの理解に必要な発話および非発話音声情報のための、同期した視覚的またはテキスト代替
字幕は、対話のみの字幕に似ていますが、番組内容の理解に必要な非対話音声情報(効果音、音楽、笑い、話者の識別と位置など)も伝達します。
クローズドキャプションは、一部のプレーヤーでオン/オフ可能な字幕です。
オープンキャプションは、オフにできない字幕です。例えば、動画に埋め込まれたテキスト画像など。
字幕は、動画中の関連情報を妨げたり隠したりしないようにすべきです。
一部の国では、字幕は「サブタイトル」と呼ばれます。
音声解説は、必ずしも字幕化する必要はありません。音声解説は既に視覚的に提示されている情報の説明だからです。
ユーザーがページ全体を同時に表示できない場合、ユーザーを混乱させる可能性のある主要な変更
文脈の変更には、以下の変更が含まれます:
コンテンツの変更が必ずしも文脈の変更となるわけではありません。アウトライン展開、動的メニュー、タブコントロールなどのコンテンツの変更は、上記のいずれか(例:フォーカス)を変更しない限り、必ずしも文脈の変更には該当しません。
新規
ユーザーが情報を記憶、操作、または転記することを求められるタスク。例として、以下が含まれます(これらに限定されません):
特定の標準、ガイドライン、または仕様のすべての要件を満たすこと
以下を満たすバージョン:
以下のいずれかを満たす:
この定義における「しか到達できない」とは、条件付きリダイレクトなどのメカニズムにより、ユーザーが適合バージョンからでなければ非適合ページに「到達」(読み込み)できないことを意味します。
代替バージョンは、元のページとページごとに一致する必要はありません(例:適合する代替バージョンが複数ページで構成されてもよい)。
複数言語バージョンが提供されている場合、それぞれの言語について適合する代替バージョンが必要です。
異なる技術環境やユーザーグループに対応するために代替バージョンを提供する場合があります。各バージョンはできる限り適合している必要があります。適合要件1を満たすには、少なくとも1つのバージョンが完全適合である必要があります。
適合する代替バージョンは、適合範囲内や同じWebサイト内に存在する必要はなく、非適合バージョンと同様に自由に利用できればよいです。
代替バージョンは、元のページを補完し理解を助ける補足コンテンツと混同しないでください。
コンテンツ内でユーザー設定を変更して適合バージョンを表示する方法も、アクセシビリティ対応の方法であれば到達可能なメカニズムとして認められます。
詳細は適合する代替バージョンの理解を参照してください。
ユーザーエージェントを介してユーザーに伝達される情報および感覚体験。これには、コンテンツの構造、提示、インタラクションなどを定義するコードやマークアップも含みます。
現在行っている操作に関連する情報を提供するヘルプテキスト
明確なラベルはコンテキスト依存ヘルプとして機能する場合があります。
(L1 + 0.05) / (L2 + 0.05)、ここで
コントラスト比は1から21までの範囲(一般的に1:1から21:1と表記)です。
著者はテキストのレンダリング方法(例:フォントスムージングやアンチエイリアス)などのユーザー設定を制御できないため、テキストのコントラスト比はアンチエイリアスをオフにして評価できます。
達成基準1.4.3および1.4.6では、コントラストはテキストが通常表示される指定された背景を基準として測定します。背景色が指定されていない場合は白とみなします。
背景色はテキストが通常表示されるコンテンツの指定色です。テキスト色だけが指定されていて背景色が指定されていない場合、ユーザーのデフォルト背景色が不明で十分なコントラストか評価できないため不適合です。逆に背景色だけが指定されていてテキスト色が指定されていない場合も不適合です。
文字の周囲に枠がある場合、枠がコントラストを増加させるため、文字と背景のコントラスト計算に使用されます。細い枠は文字として扱われ、太い枠が文字の内側部分を埋める場合はハローとして背景とみなします。
WCAG適合性は、著者が典型的な表示で隣接すると想定する色の組み合わせで評価します。著者のコード以外によるユーザーエージェントによる色変更など、異例な表示は考慮不要です。
語や段落が意味を変えずに提示される任意の順序
約0.0213度の視覚角度
CSSピクセルはCSSにおける長さや寸法の標準単位です。この単位は密度非依存であり、ディスプレイ上の実際のハードウェアピクセルとは異なります。ユーザーエージェントやOSは、CSSピクセルをCSS Values and Units Module Level 3 reference pixel [css3-values]にできるだけ近づけるべきです。これはディスプレイの物理的寸法や想定視距離(これらはコンテンツ著者が決定できない要素)を考慮します。
ポインタのトリガー刺激が押されたときに発生するプラットフォームイベント
ダウンイベントはプラットフォームによって異なる名称の場合があります(例:"touchstart"や"mousedown")。
新規
ポインタがダウンイベントで要素と接触し、その要素(またはその位置の表現)がアップイベントまでポインタに追従する操作
ドラッグ可能な要素にはリスト項目、テキスト要素、画像などが含まれます。
健康、安全、または財産を守るために即時の対応が必要な、突然かつ予期せぬ状況や出来事
削除するとコンテンツの情報や機能が根本的に変化し、かつ他の方法で適合して情報や機能を達成できない場合
追加の説明を入れるために動画を一時停止して音声解説を追加する方法
この技法は、追加の音声解説がないと動画の意味が失われ、対話の間のポーズが短すぎる場合にのみ使用されます。
相対輝度が反対方向に変化する一対の変化で、十分な大きさと適切な周波数の場合、一部の人に発作を引き起こすことがある
許容されないフラッシュのタイプについては、一般フラッシュ及び赤色フラッシュの閾値を参照してください。
点滅も参照してください。
新規
ユーザーインターフェースコンポーネントがフォーカス状態になったとき、視覚的に示すために変化するピクセル
一連の操作やユーザー操作によって達成可能な結果
フラッシュまたは急速に変化する画像列が、以下のいずれかを満たす場合、閾値以下(つまりコンテンツは合格)です:
ここで:
例外:ホワイトノイズや0.1度未満のチェッカーボードパターンなど、細かく均一なパターンは閾値違反とはなりません。
一般的なソフトウェアやWebコンテンツでは、1024×768ピクセルの表示画面で341×256ピクセルの矩形が標準的な画面サイズ・視距離で10度視野の良い推定値です。75~85ppiの解像度は、CSS仕様上の名目96ppiより低く、より保守的です。同じ内容を高解像度で表示すれば画像はより小さく安全なので、閾値定義には低解像度が使われます。
遷移は、隣接するピークと谷の間の相対輝度(赤フラッシュの場合は相対輝度/色)の変化です。フラッシュは2つの反対方向の遷移で構成されます。
現場での「飽和赤を含む反対方向の遷移の一対」の新しい定義(WCAG 2.2より)は、一方の状態がR/(R + G + B)値0.8以上、かつCIE 1976 UCS色度図で状態間の差が0.2(単位なし)以上の遷移の一対です。[ISO_9241-391]
動画キャプチャから解析を行うツールも利用可能です。ただし、1秒間に3回以下のフラッシュならツール不要で自動的に合格です(上記#1、#2参照)。
人間同士のコミュニケーションのために、話す・書く・視覚や触覚で表す言語
手話も参照してください。
個々の単語の意味から意味を推測できず、構成語を変えると意味が失われる表現
慣用句は直訳すると(文化や言語依存の)本来の意味を失ってしまいます。
特定の視覚効果を得るために、テキストが非テキスト形式(例:画像)で描画されているもの
これは、他の重要な視覚的内容を含む画像の一部であるテキストは含みません。
情報提供のみを目的とし、適合には必須でない
適合に必須なコンテンツは「規定」と呼ばれます。
ユーザーが提供した情報が受け付けられない場合
これには以下が含まれます:
特定の分野の人々が特有の使い方をする語
ソフトウェアがキーストローク入力を受け取るためのインターフェース
キーボードインターフェースがあれば、ネイティブ技術にキーボードがなくてもユーザーはプログラムにキーストローク入力できます。
キーボード操作型マウスエミュレータ(MouseKeys等)でアプリを操作する場合は、プログラムの操作がポインティングデバイスインターフェース経由となるため、キーボードインターフェースによる操作とは認められません。
1つ以上のキーを押すことでアクションを実行するための代替手段
テキスト または、テキスト代替を持つ他のコンポーネントで、Webコンテンツ内のコンポーネントを識別するためにユーザーに提示されるもの
ラベルはすべてのユーザーに提示されますが、名前は非表示で支援技術のみで認識される場合があります。多くの場合(すべてではありません)、名前とラベルは同じです。
ラベルという用語は、HTMLのlabel要素だけに限定されません。
18ポイント以上、または14ポイント以上の太字、もしくは中国語・日本語・韓国語(CJK)フォントで同等サイズとなるフォントサイズ
極端に細いストロークや、文字の形状をわかりづらくする特徴・特性を持つフォントは、特にコントラストが低い場合に読みづらくなります。
フォントサイズはコンテンツが配信された時のサイズです。ユーザーによるリサイズは含みません。
ユーザーが実際に見る文字の大きさは、著者が指定したサイズとユーザーの表示設定やエージェント設定に依存します。多くの主流本文フォントでは、14ポイントや18ポイントは約1.2emや1.5em、または本文デフォルトサイズの120%や150%に相当します(本文フォントが100%と仮定して)。ただし、使用するフォントで確認する必要があります。フォントが相対単位で定義されている場合、実際のポイントサイズはユーザーエージェントが表示用に計算します。評価時にはユーザーエージェントからポイントサイズを取得するか、フォントメトリクスに基づいて計算してください。弱視のユーザーは適切な設定を選択する責任があります。
フォントサイズを指定せずにテキストを使用する場合、主要ブラウザで未指定テキストに使われる最小サイズを、そのフォントのサイズとして想定するのが妥当です。レベル1見出しが主要ブラウザで14pt太字以上で表示されるなら、大きな文字とみなしてよいです。相対スケーリングはデフォルトサイズから同様に計算できます。
ローマ字テキストの18ptと14ptは、大きな文字印刷の最小サイズ(14pt)や標準フォントサイズ(18pt)から取られています。CJKなど他言語フォントの場合は、各言語の大きな文字印刷で使われる最小サイズや次に大きい標準サイズが「同等サイズ」となります。
法的拘束力のある義務や利益が生じる取引
ハイパーリンクを作動させて得られる結果の内容
実世界のイベントから取得した情報が、放送遅延以上の遅れなく受信者に伝送されるもの
放送遅延は短時間(通常は自動化)で、音声や映像をキューイングや検閲するために使われますが、十分な編集時間にはなりません。
情報が完全にコンピューター生成の場合はライブではありません。
6年間の初等教育修了後に始まり、初等教育開始から9年後に終わる、2~3年間の教育期間
この定義は国際標準教育分類[UNESCO]に基づきます。
プロセス または、結果を達成するための技法
メカニズムはコンテンツ内で明示的に提供される場合も、依存技術としてプラットフォームやユーザーエージェント、支援技術によって提供される場合もあります。
メカニズムは、主張する適合レベルのすべての達成基準を満たす必要があります。
テキスト(直接またはテキスト代替経由)で既に提示されている以上の情報を含まないメディア
テキストのメディア代替は、テキストの他の表現が有益な人のために提供されます。音声のみ、動画のみ(手話動画含む)、音声+動画などが含まれます。
状態間に段階を追加して動きや滑らかな遷移の感覚を作り出すこと
新規
形状のすべての点が収まる、水平軸に揃った最小の外接矩形。文や文章ブロックの一部として複数行にまたがるコンポーネント(例:ハイパーテキストリンク)は、1行で表示される場合の外接矩形を基準とします。
ソフトウェアがWebコンテンツ内のコンポーネントをユーザーに識別するためのテキスト
名前は非表示で支援技術のみで認識される場合があり、ラベルはすべてのユーザーに提示されます。多くの場合(すべてではありません)、ラベルと名前は同じです。
これはHTMLのname属性とは関係ありません。
キーボードインターフェースを使って、フォーカスを次の要素へ進めるために定義された順序でナビゲートすること
ソフトウェアによってプログラムで判別できる文字列でない、またはその文字列が人間の言語で何かを表していないコンテンツ
これにはASCIIアート(文字のパターン)、絵文字、文字置換を用いたリート語、テキストを表す画像などが含まれます。
適合のために必須
この文書には、さまざまな明確な方法で適合できます。
最も一般的なサイズのデスクトップ/ノートパソコンディスプレイでビューポートを最大化した状態
多くの人は数年間コンピューターを使い続けるため、評価を行う際は最新のデスクトップ/ノートパソコンのディスプレイ解像度に依存せず、数年にわたり一般的なディスプレイ解像度を考慮するのが望ましいです。
ユーザーの要求によって停止し、ユーザーが再開を要求するまで再開されない状態
新規
形状の境界を形成する連続した線(共有ピクセルは含まない)、または最小バウンディングボックスのうち短い方。
マウス、ペン、タッチ接触など、画面上の特定座標(または座標群)をターゲットにできるデバイスからの入力
情報がライブでない場合
コンテンツをユーザーが知覚できる形でレンダリングすること
5歳~7歳の間に始まり、前段階の教育がない場合もあり得る、6年間の教育期間
この定義は国際標準教育分類[UNESCO]に基づきます。
一連のユーザー操作で、各操作が活動完了に必要なもの
著者が提供したデータを、ユーザーエージェント(支援技術含む)など、異なる環境でソフトウェアが抽出・提示できる形で判別されること
リンクと関係を持つ追加情報が、リンクテキストと組み合わせて、異なるモダリティでユーザーに提示できる形でプログラムで判別できること
スクリーンリーダーは句読点を解釈するため、リンクが文中にある場合はその文の文脈も提示できます。
ユーザーエージェント(支援技術含む)がサポートする方法でソフトウェアにより設定されること
美的な目的のみで、情報や機能を持たないもの
テキストが純粋な装飾になるのは、単語が並び替えや置換されても目的が変わらない場合のみです。
(a)閲覧と同時に発生し、(b)コンテンツにより完全に生成されていないイベント
知覚可能で、プログラムで判別可能なセクションコンテンツ
HTMLではランドマークロールが指定された領域はリージョンです。
異なるコンテンツ間の意味ある関連
色空間の任意の点の相対的な明るさ(最暗の黒で0、最明の白で1に正規化)
sRGB色空間では、色の相対輝度は L = 0.2126 * R + 0.7152 * G + 0.0722 * B で定義され、R、G、Bは以下の通り:
RsRGB、GsRGB、BsRGBの定義:
「^」はべき乗演算子。(式は [SRGB] より)
2021年5月以前は定義値が0.03928でしたが、古い仕様からのものです。実際のガイドラインの計算には影響ありません。
現在Webコンテンツを表示するほとんどのシステムはsRGBエンコーディングを前提としています。他の色空間を使用する場合は、達成基準 1.4.3 の理解を参照してください。
配信後にディザリングが発生する場合は元の色値を使います。ソースでディザリングされる場合は平均値(平均R・G・B)を使います。
コントラストやフラッシュのテスト時に自動計算するツールが利用可能です。
MathMLで式を表示する相対輝度定義の専用ページも提供されています。
ソフトウェアがWebコンテンツ内のコンポーネントの機能を識別できるテキストまたは数値
使用時に同じ結果となること
他の項目との相対的な位置が同じであること
元の順序に項目が追加・削除されても、同じ相対順序とみなされます。例:ナビゲーションメニューの展開で詳細レベルや二次ナビゲーションが追加されることがあります。
達成基準をページに適用した際、「偽」と評価されないこと
1つ以上の関連する話題や考えを扱う、独立した文章部分
セクションは複数段落や画像、表、リスト、サブセクションを含む場合があります。
共通の目的を持ち、同じ著者・グループ・組織によって作成されたWebページの集まり
異なる言語バージョンは別のWebページセットとみなされます。
意味を伝えるために、手や腕の動き、顔の表情、体の姿勢を組み合わせて使う言語
ある言語(通常は話し言葉)を手話に翻訳すること
本来の手話は独立した言語であり、同じ国や地域の話し言語とは関係ありません。
1度にページ/画面上の1点だけをターゲットにできる入力方式(例:マウス、タッチスクリーンの指1本、スタイラス)
単一ポインタの操作にはクリック、ダブルクリック、タップ、ドラッグ動作、指1本のスワイプジェスチャなどがあります。これに対し、複数ポインタ操作は2本指やマウスとスタイラスの同時使用など、複数のポインタを同時に使うものです。
純粋な装飾ではなく、重要な情報を主に伝達したり機能を果たしたりしない感覚体験
ユーザー操作や自動処理に応じて変化するユーザーインターフェースコンポーネントの特徴を表す動的プロパティ
状態はコンポーネントの性質には影響しませんが、コンポーネントやユーザー操作の可能性に関連するデータを表します。例:フォーカス、ホバー、選択、押下、チェック、訪問済/未訪問、展開/折りたたみなど。
文脈の変更でなく、アクションの成功や結果、アプリケーションの待機状態、プロセスの進捗、エラーの有無などをユーザーに知らせるコンテンツの変化
フォント、色、サイズ、位置、パディング、音量、合成音声のプロソディなど、ユーザーエージェントがレンダリングする際のコンテンツ要素の提示を決定するプロパティ
スタイルプロパティにはいくつかの由来があります:
主となるコンテンツを説明・補足する追加コンテンツ
音声または動画が、情報提示用の他形式や時間依存のインタラクティブコンポーネントと同期しているもの。ただし、メディアが明確にそのテキストのメディア代替としてラベル付けされている場合は除く。
ポインタ操作を受け付ける表示領域(例:ユーザーインターフェースコンポーネントのインタラクティブ領域)
複数のターゲットが重なっている場合、重なった領域はターゲットサイズの計測に含めません(ただし、同じ操作または同じページを開く場合は例外)。
メカニズムで、ユーザーエージェントによってレンダリング、再生、実行される指示を符号化するもの
これらのガイドラインでは「Web技術」および単に「技術」という語もWebコンテンツ技術を指します。
Webコンテンツ技術には、マークアップ言語、データフォーマット、プログラミング言語などがあり、著者は単独または組み合わせて静的Webページから同期メディア、動的Webアプリまで様々な体験を作成できます。
プログラムで判別可能な文字列の並びであり、その並びが人間の言語で何かを表している場合
テキストが非テキストコンテンツにプログラムで関連付けられているか、非テキストコンテンツに関連付けられたテキストから参照されているもの。プログラムで関連付けられたテキストとは、その位置が非テキストコンテンツからプログラムで判別可能なもの。
詳細はテキスト代替の理解を参照してください。
ポインタのトリガー刺激が離されたときに発生するプラットフォームイベント
アップイベントはプラットフォームによって異なる名称の場合があります(例:"touchend"や"mouseup")。
正確な定義を知っていないと、内容を正しく理解できないような使い方をしている語
ユーザーのためにWebコンテンツを取得・提示するソフトウェア全般
ユーザーがアクセスすることを意図したデータ
これにはインターネットログや検索エンジンのモニタリングデータなどは含みません。
ユーザーが特定機能のための単一のコントロールとして認識するコンテンツの一部
複数のユーザーインターフェースコンポーネントが一つのプログラム的要素として実装される場合があります。「コンポーネント」はプログラミング技法に限定されず、ユーザーから見て別々のコントロールと認識できるものです。
ユーザーインターフェースコンポーネントにはフォーム要素やリンク、スクリプトで生成されたコンポーネントなどが含まれます。
本項でいう「コンポーネント」「ユーザーインターフェースコンポーネント」は「ユーザーインターフェース要素」と呼ばれることもあります。
ユーザー操作が発生しない連続した任意の時間
追跡方法はWebサイトやアプリケーションによって定められます。
動く画像や連続した画像・映像技術
動画はアニメーション画像や写真画像、またはその両方で構成されます。
動画のみで構成される時間依存のプレゼンテーション(音声やインタラクションなし)
ユーザーエージェントがコンテンツを提示するオブジェクト
ユーザーエージェントは1つ以上のビューポートを通じてコンテンツを提示します。ビューポートにはウィンドウ、フレーム、スピーカー、拡大鏡などが含まれます。ビューポートは他のビューポート(例:ネストされたフレーム)を含み得ます。プロンプト、メニュー、警告などユーザーエージェントが作成するインターフェースコンポーネントはビューポートではありません。
この定義はUser Agent Accessibility Guidelines 1.0 用語集 [UAAG10]に基づきます。
フォント、サイズ、色、背景などを設定できること
HTTPで単一のURIから取得され、ユーザーエージェントによるレンダリングに使われる、または一緒に表示されることを意図した追加リソースを含む非埋め込み型のリソース
「追加リソース」は主要リソースとともにレンダリングされますが、必ずしも同時に表示されるとは限りません。
これらのガイドラインへの適合のためには、リソースが適合範囲内で「非埋め込み型」である必要があります。
このセクションでは、一般的なユーザーインターフェースコンポーネントの入力目的一覧を示します。以下の用語は、必ず使用しなければならないキーワードではなく、ウェブページで採用される分類法に捕捉されるべき目的を表します。該当する場合、著者は選択した分類法でコントロールをマークアップし、意味的な目的を示します。これにより、ユーザーエージェントや支援技術がパーソナライズされた表示を適用できる可能性が生まれ、より多くの人がコンテンツを理解・利用できるようになります。
入力タイプ目的の一覧はHTML現行標準のAutofillセクションで定義されたコントロール目的に基づいていますが、他の技術でも同じ概念を定義している場合があります。ここで示す意味と対応付けされている概念のみが必要です。
以下の入力コントロール目的は、コンテンツのユーザーに関連し、その個人に関する情報のみを対象としています。
name
- 氏名(フルネーム)honorific-prefix
- 敬称・タイトル(例:「様」、「氏」、「博士」、「Mlle」など)given-name
- 名(西洋文化ではファーストネームとも呼ばれる)additional-name
- 中間名(西洋文化ではミドルネーム、ファーストネーム以外の名前)family-name
- 姓(西洋文化ではラストネームまたは苗字)honorific-suffix
- 接尾辞(例:「Jr.」、「B.Sc.」、「MBASW」、「II」など)nickname
- ニックネーム、スクリーンネーム、ハンドル:フルネームの代わりによく使われる短い名前organization-title
- 役職(例:「ソフトウェアエンジニア」、「上級副社長」、「副社長」など)username
- ユーザー名new-password
- 新しいパスワード(アカウント作成やパスワード変更時など)current-password
- username
フィールドで指定されたアカウントの現在のパスワード(ログイン時など)organization
- 会社名(他のフィールドの人物、住所、連絡先に対応)street-address
- 住所(複数行、改行保持)address-line1
- 住所(1行ごと、1行目)address-line2
- 住所(1行ごと、2行目)address-line3
- 住所(1行ごと、3行目)address-level4
- 4階層ある住所の最も細かい行政区分address-level3
- 3階層以上ある住所の第3行政区分address-level2
- 2階層以上ある住所の第2行政区分。2階層の場合は通常、該当する住所が存在する都市、町、村などaddress-level1
- 住所の最も広い行政区分(例:都道府県、州、カントン、ポストタウンなど)country
- 国コードcountry-name
- 国名postal-code
- 郵便番号、ZIPコード、CEDEXコード(CEDEXの場合は「CEDEX」とarrondissementをaddress-level2
フィールドに追記)cc-name
- 支払手段上の氏名(フルネーム)cc-given-name
- 支払手段上の名(西洋文化ではファーストネーム)cc-additional-name
- 支払手段上の中間名(西洋文化ではミドルネーム、ファーストネーム以外の名前)
cc-family-name
- 支払手段上の姓(西洋文化ではラストネームまたは苗字)cc-number
- 支払手段の識別コード(例:クレジットカード番号)cc-exp
- 支払手段の有効期限cc-exp-month
- 支払手段の有効期限(月)cc-exp-year
- 支払手段の有効期限(年)cc-csc
- 支払手段のセキュリティコード(CSC、CVC、CVV、SPC、CCID等とも呼ばれる)cc-type
- 支払手段の種類transaction-currency
- ユーザーが希望する取引通貨transaction-amount
- ユーザーが希望する取引額(例:入札額や販売価格入力時)language
- 希望言語bday
- 誕生日bday-day
- 誕生日の日bday-month
- 誕生日の月bday-year
- 誕生日の年sex
- 性別(例:女性、Fa’afafineなど)url
- 会社、人物、住所、連絡先に対応するホームページや他のWebページphoto
- 会社、人物、住所、連絡先に対応する写真、アイコン、その他画像tel
- 国コードを含む電話番号(全体)tel-country-code
- 電話番号の国コード部分tel-national
- 国コードを除いた電話番号(必要に応じて国内プレフィックス付き)tel-area-code
- 電話番号の市外局番部分(国内プレフィックス付きの場合あり)tel-local
- 国コード・市外局番を除いた電話番号tel-local-prefix
- 市外局番に続く電話番号部分が2つに分かれる場合の前半tel-local-suffix
- 市外局番に続く電話番号部分が2つに分かれる場合の後半tel-extension
- 電話番号の内線番号email
- メールアドレスimpp
- インスタントメッセージプロトコルのURL(例:「aim:goim?screenname=example
」や「xmpp:fred@example.net
」など)このセクションでは、WCAG 2.2に組み込まれたWCAG 2.1以降の実質的な変更点と、2023年10月5日の初版以降に加えられた2.2への変更点を示します。WCAG 2.1への正誤表修正もWCAG 2.2に組み込まれています。
WCAG 2.2の全コミット履歴も参照できます。
ドラッグ(後にドラッグ操作に改名)を追加。
ヘルプの発見性(後にヘルプの一貫性に改名)、
ポインタターゲット間隔(後にターゲットサイズ(最小)に改名)、冗長入力を追加。
フォーカス外観(最小)(後にフォーカス外観に改名)を追加。
アクセシブル認証(例外なし)(後にアクセシブル認証(強化)に改名)を追加。
encloses定義の削除
このセクションは規定ではありません。
アクセシビリティガイドラインワーキンググループ(AG WG)への参加情報は、ワーキンググループホームページでご覧いただけます。
Paul Adam、Jenae Andershonis、Wilhelm Joys Andersen、Andrew Arch、Avi Arditti、Aries Arditi、Tom Babinszki、Mark Barratt、Mike Barta、Sandy Bartell、Kynn Bartlett、Chris Beer、Charles Belov、Marco Bertoni、Harvey Bingham、Chris Blouch、Paul Bohman、Frederick Boland、Denis Boudreau、Patrice Bourlon、 Andy Brown、Dick Brown、Doyle Burnett、Raven Calais、Ben Caldwell、Tomas Caspers、Roberto Castaldo、 Sofia Celic-Li、Sambhavi Chandrashekar、Mike Cherim、Jonathan Chetwynd、Wendy Chisholm、Alan Chuter、 David M Clark、Joe Clark、Darcy Clarke、James Coltham、Earl Cousins、James Craig、Tom Croucher、Pierce Crowell、Nir Dagan、Daniel Dardailler、Geoff Deering、Sébastien Delorme、Pete DeVasto、Iyad Abu Doush、 Sylvie Duchateau、Cherie Eckholm、Roberto Ellero、Don Evans、Gavin Evans、Neal Ewers、Steve Faulkner、 Bengt Farre、Lainey Feingold、Wilco Fiers、Michel Fitos、Alan J. Flavell、Nikolaos Floratos、Kentarou Fukuda、Miguel Garcia、P.J. Gardner、Alistair Garrison、Greg Gay、Becky Gibson、Al Gilman、Kerstin Goldsmith、Michael Grade、Karl Groves、Loretta Guarino Reid、Jon Gunderson、Emmanuelle Gutiérrez y Restrepo、Brian Hardy、Eric Hansen、Benjamin Hawkes-Lewis、Sean Hayes、Shawn Henry、Hans Hillen、Donovan Hipke、Bjoern Hoehrmann、Allen Hoffman、Chris Hofstader、Yvette Hoitink、Martijn Houtepen、Carlos Iglesias、Richard Ishida、Jonas Jacek、Ian Jacobs、Phill Jenkins、Barry Johnson、Duff Johnson、Jyotsna Kaki、Shilpi Kapoor、Leonard R. Kasday、Kazuhito Kidachi、Ken Kipness、Johannes Koch、Marja-Riitta Koivunen、Maureen Kraft、Preety Kumar、Kristjan Kure、Andrew LaHart、Gez Lemon、Chuck Letourneau、 Aurélien Levy、Harry Loots、Scott Luebking、Tim Lacy、Jim Ley、Alex Li、William Loughborough、N Maffeo、 Mark Magennis、Erich Manser、Kapsi Maria、Luca Mascaro、Matt May、Sheena McCullagh、Liam McGee、Jens Oliver Meiert、Niqui Merret、Jonathan Metz、Alessandro Miele、Steven Miller、Mathew J Mirabella、Matt May、Marti McCuller、Sorcha Moore、Charles F. Munat、Robert Neff、Charles Nevile、Liddy Nevile、Dylan Nicholson、Bruno von Niman、Tim Noonan、Sebastiano Nutarelli、Graham Oliver、Sean B. Palmer、Charu Pandhi、evarshi Pant、Nigel Peck、Anne Pemberton、David Poehlman、Ian Pouncey、Charles Pritchard、 Kerstin Probiesch、W Reagan、Adam Victor Reed、Chris Reeve、Chris Ridpath、Lee Roberts、Mark Rogers、 Raph de Rooij、Gregory J. Rosmaita、Matthew Ross、Sharron Rush、Joel Sanda、Janina Sajka、Roberto Scano、 Gordon Schantz、Tim van Schie、Wolf Schmidt、Stefan Schnabel、Cynthia Shelly、Glenda Sims、John Slatin、 Becky Smith、Jared Smith、Andi Snow-Weaver、Neil Soiffer、Mike Squillace、Michael Stenitzer、Diane Stottlemyer、Christophe Strobbe、Sarah J Swierenga、Jim Thatcher、Terry Thompson、Justin Thorp、David Todd、Mary Utt、Jean Vanderdonckt、Carlos A Velasco、Eric Velleman、Gijs Veyfeyken、Dena Wainwright、 Paul Walsch、Daman Wandke、Richard Warren、Elle Waters、Takayuki Watanabe、Gian Wild、David Wooley、Wu Wei、Kenny Zhang、Leona Zumbo。
この出版物は、米国保健福祉省・障害者・自立生活・リハビリテーション研究所(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:
Referenced in: