【2025年版】WCAG 2.2 AA基準に準拠したWebサイトの制作・改善方法

皆さんこんにちは。
taneCREATIVEの「ちほうタイガー」です。

この記事は2025年1月8日に執筆しています。

今年の春に改正障害者差別解消法が施行されてから半年が過ぎました。
改正障害者差別解消法とウェブアクセシビリティに関する基本情報については、当社コラム「【2025年版】ウェブアクセシビリティと改正障害者差別解消法の関係」にて解説していますので、もしよろしければご覧ください。

さて、上記コラムでは、「例えば、中小企業にとって、自社コーポレートサイトで即座にJIS X 8341-3規格のAA基準をクリアすることなどは、『負担が過重』であるケースが多いのではないかと現場の感覚としては感じています。それぞれの企業にとって過重ではない費用負担、実装期間内にて達成を目指していくことが重要ではないでしょうか。」等と、ちょっと現場感を出した記載をしていたのですが、企業様、特に特例子会社をグループ企業にお持ちの上場企業様より、待ったなしでJIS X 8341-3規格ないしWCAG 2.2基準AA準拠での納品を求められることが続いております。

しかしながら、企業のWeb担当者の皆様からすると、何をどのようにクリアすればAA準拠となるのか分かりにくいのではないでしょうか。

そこで、本記事では、企業のWeb担当者の皆様に向けて、WCAG 2.2 AA基準に準拠したWebサイト制作とチェック方法について解説してみようと思います（なお、WCAGの原文は英文であり、英語が苦手なちほうタイガーが意訳しつつ、Web制作会社の観点から記載していますので、翻訳ミスや分かりにくい点があるかもしれない点、ご了承ください。）

少しでも皆様のお役に立てる記事にできればと思います。
どうぞよろしくお願い致します。

WCAGとはWeb Content Accessibility Guidelinesの略（以下「WCAG」とします）で、障がいをお持ちの方でもWebコンテンツにアクセスできるようにするための国際的なガイドラインです。

JIS（日本産業規格）が、その名の通り日本の国家規格であるのに対し、WCAGは、Webの相互運用性を確保するための統一的な規約を制定しているWorld Wide Web Consortium（以下「W3C」とします）の作業部会であるWeb Accessibility Initiative（以下「WAI」とします）が制定したガイドラインであることから、一般的には、日本国内向けビジネスをしている企業はJISに、日本国内だけでなく世界に向けてもビジネスをしている企業はWCAGに合わせている傾向があります（とはいえ、JIS X 8341-3自体がWCAG 2.0のガイドラインに基づいているためほぼ重なり合っています）。

WCAG 2.2は、これまでの2.0および2.1のガイドラインを引き継ぎつつ、新しいニーズや技術進化に対応するためのアップデートであり、2023年10月5日に正式に勧告されました。
特に、モバイルデバイスやインタラクティブなコンテンツに関するアクセシビリティの向上に焦点を当てており、具体的には9つの新しい達成基準が追加され、ユーザーインターフェースの使いやすさや認知障害を持つユーザーの支援が強化されています。

このWCAGのガイドラインは、A、AA、AAAの3つの準拠レベルで構成されており、これまで行政サイトなどのWebサイトにおいて標準として採用されてきたのがAA準拠レベルとなります。

A準拠は最低限のアクセシビリティ要件を満たし、AA準拠はより多くの障壁を取り除くための基準であり、特に視覚・聴覚障害を持つユーザーに対する対応が強化されています。AAA準拠は、可能な限りの配慮が求められる最も厳しい基準です。

WCAG 2.2では、特にAA準拠レベルでの強化が行われており、Webデザインやコーディングにおける新たな要件に対応する必要があります。

日本においても、障害者差別解消法が2024年（令和6年）4月1日付けで施行され、これまで障がいを持たれている方に対する「合理的配慮の提供」について、民間企業では努力義務を負っていたに過ぎなかったものが、法的義務を負うことが明記されました。

ウェブアクセシビリティへの対応は「環境の整備」であって「合理的配慮の提供」には該当しないとして、法的義務ではない以上対応しなくてもよいという考え方もありえますが、当社のクライアントである多くの上場企業グループ様の対応を見る限り、むしろ厳しい社内基準を定められているところが多い状況です。

合理的配慮は、障害の特性や社会的障壁の除去が求められる具体的場面や状況に応じて異なり、多様かつ個別性の高いものですので、環境の整備に該当するウェブアクセシビリティへの対応状況に応じて、合理的な配慮義務違反が個別具体的に判断されるものと当社では理解しています。
※合理的配慮義務と環境の整備の関係については、【2025年版】ウェブアクセシビリティと改正障害者差別解消法の関係をご参照ください。

その為、各企業の法務部の皆様においても、AA準拠レベルに適合するようにWebサイトを制作・運用することが、コンプライアンスの観点から重要であると判断されているのではないかと推察しております。

なお、AA準拠に適合するためには、基本的に、Webサイトの全てのページにおいて、A及びAA達成基準のすべてを満たすか、AA に適合している代替版を提供する必要があります。

これらの達成基準は、A（32）及びAA（23）で合計55の達成基準があり、ウェブアクセシビリティの土台となる4つの原則である「1.知覚可能」「2.操作可能」「3.理解可能」「4.堅牢」と13のガイドラインに分類されています。

以下各ガイドラインにおけるA及びAA達成基準を具体的に見ていきましょう。

※本記事は、基本的にウェブアクセシビリティ基盤委員会（WAIC）のサイトにて公開されている「WCAG 2.2（日本語訳）」を参考にしつつ、Web制作会社の観点から分かりやすく書き換えている部分があります。その為正確性については担保できないことをご了承ください。
※企業のWeb担当の方は本文を読めば概略がつかめるように記載しているつもりですが、Webエンジニア、Webデザイナー向けには情報が不足していると思います。そこで、各達成基準ごとにWCAG 2.2解説書へのリンクを掲載していますが、WCAG 2.2解説書の日本語ページの翻訳が間に合っていない場合には、WCAG 2.1解説書へのリンクを掲載しています。
※ユーザーインターフェースコンポーネントとは、画面上に表示されるユーザーインターフェース（UI）のパーツの総称で、ボタンやチェックボックス、ダイアログ（ポップアップ）、テキストフィールド（文字入力欄）などが該当します。本記事ではUIコンポーネントと記載します。
※コンテキスト（context）という言葉が使用は「コンテンツ（content）」そのものを指しているわけではなく、ページ内の文脈や、画面・UI の状態などを含む「利用者の操作環境全体」を指すイメージで使用しています。

「1.1 テキストによる代替」は、画像や音声などの非テキストコンテンツに対して、テキストによる代替情報（alt属性やテキスト説明など）を提供することで、スクリーンリーダーなどを使用するユーザーを含め、すべての利用者が非テキストコンテンツの意味や目的を理解できるようにするためのガイドラインです。

ユーザーに提示されるすべての非テキストコンテンツ（画像・音声・動画など）には、以下に示す例外を除いて、同等の目的を果たすテキストによる代替手段（alt属性やテキスト説明など）を用意する必要があります。
これにより、スクリーンリーダーを使用するユーザーや、一時的に画像・音声を確認できないユーザーにも、同じ情報や機能を利用できるようになります。

①　コントロール、入力
ボタンやチェックボックス、フォームなど、ユーザーが操作したり、情報を入力するためのUIコンポーネントで、既に視覚的に役割を示すテキストが付いている場合（たとえば、「送信」ボタンに「送信」というテキストがある場合）や、入力フィールドに明確なラベルが関連付けられていて機能が十分に説明されている場合（たとえば入力フィールドの前に「名前」「メールアドレス」などがつけられている場合）には、別途テキストによる説明が不要とされます。

なお、ラベルが不十分な場合や見た目だけで意味を伝えている場合には、aria-label属性やtitle属性などを使って、スクリーンリーダーが正しく役割を認識できるように補完する必要があります。

②　時間依存メディア
収録済みの音声や映像など、特定の時間に沿って変化するコンテンツであり、そのメディア自体が「何の音声・映像であるか」を識別する短いテキスト（タイトル等）があれば十分な場合には、別途テキストによる説明が不要とされます。

ただし、達成基準1.2（キャプションや音声解説など）で追加の対応が必要なシーン（会話や視覚情報が含まれる動画など）は別途考慮が必要な場合もあります。

③　テスト
テストやクイズ、試験などで、非テキストコンテンツがユーザーの反応や能力を測定するために使われる場合には、別途テキストによる説明が不要とされます。
たとえば、図形やパズルを認識する力をテストする場合や、図形そのものをテキストで説明してしまうとテストの意義が失われるような場合、聴覚的な反応をテストする場合で音声をテキストで説明するとテストが成り立たなくなるような場合には、この例外に該当します。

④　感覚的
ユーザーが特定の感覚（視覚・聴覚など）でコンテンツを認識または操作する必要があり、その代替テキストを提供することが不適切・意味がないと判断される場合には、別途テキストによる説明が不要とされます。
たとえば、視覚的な芸術作品やデザイン作品の場合、最低限の情報（作品タイトルや作者名など）を伝えることは推奨されますが、作品の芸術的意図やビジュアルを完全にテキスト化することは不可能であるか、意図を損なう場合が多いことから例外とされます。
また、音楽や楽器の演奏など、聴覚的な体験そのものが本質であるコンテンツについても、曲名・演奏者などの基本情報を伝えることは推奨されますが、聴覚的な体験をテキストで代替することは困難であることから例外とされます。

⑤　CAPTCHA
CAPTCHAは、人間とコンピュータを区別するための自動化されたテストの一種で、「人間であることを証明する」ために、特定の視覚や聴覚的な認識能力を必要とすることから、その性質上代替テキストの提供は不要とされます。
たとえば、画像の中の文字を「テキストとして提示」すると、CAPTCHAとしての意味がなくなるため、alt属性などによるテキスト代替は提供しなくてもよいことになります。なお、WCAGの考え方としては、CAPTCHAそのものを多様な手段で代替（音声CAPTCHAや質問形式など）することが求められており、単純にテキスト代替しなくてよいということではありません。

⑥　装飾、整形、非表示
ウェブページ内で使用される視覚的な要素が、装飾やレイアウトの整形、または非表示にするためだけに使われる場合には、コンテンツの理解や操作に影響を与えないため、別途テキストによる説明が不要とされます。

【例1】単にページのデザインを美しく見せるために使われている背景画像などは、情報を伝える役割を持たないため、代替テキストを提供する必要はありません。

【例2】セパレーターやボーダーとして使われる線や図形、余白を作るための透明画像なども、単にレイアウトを整えるためのものであり、情報を伝達していないため、代替テキストの提供は不要となります。

【例3】ウェブページに非表示の状態で挿入されている要素も、表示されないためユーザーには影響がなく、代替テキストを提供する必要はありません。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.1.1 非テキストコンテンツを理解する

「1.2 時間依存メディア」は、動画や音声コンテンツなど「時間的に変化するメディア」に、キャプションや音声解説、テキストによる代替情報などの提供を求めることで、視聴・聴取が難しいユーザーにも同等の情報を確保するためのガイドラインです。

収録済みの音声のみのメディアおよび収録済みの映像のみのメディアについては、以下の条件を満たす必要があります。

①　収録済みの音声のみのコンテンツ
収録済みの音声のみのコンテンツ（ポッドキャストやラジオ番組の録音など）については、その内容をテキストとして提供する必要があります。
これは文字起こし（トランスクリプト）と呼ばれ、これを提供することで、聴覚に障害があるユーザーでも音声コンテンツの内容を理解できるようになります。

②　収録済みの映像のみのコンテンツ
映像のみで音声が含まれていないコンテンツ（たとえば無音のタイムラプス動画など）の場合、その映像の内容を説明するために音声による解説、またはテキストによる説明を提供する必要があります。

ただし、その音声または映像がテキストの代替メディアであり、そのように明確に表示されている場合（たとえばすでにテキストマニュアルがあり、無音アニメーションは文章の説明を補足しているだけの場合）には、これらの条件を満たす必要はありません。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.2.1 音声のみ及び映像のみ(収録済)を理解する

同期したメディア（音声付きの映像、いわゆる動画）に含まれているすべての収録済の音声コンテンツ（会話、音声ガイドだけでなく、効果音、BGMであっても意味を持つ情報すべて）については、キャプション（字幕）が提供されている必要があります。
聴覚障害のあるユーザーや環境的に音を再生できないユーザーにも、音声情報を文字で伝えるための基準です。

ただし、その同期したメディアがテキストの内容を視覚的または聴覚的に補完する役割であり、そのように明確に表示されている場合（たとえばテキスト教材が主で、動画は単なる補足教材であるような場合や、会話、効果音、BGMであっても例えば雰囲気を作り出すためだけのもので意味のある情報が増えない場合）には、キャプションは不要とされています。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.2.2 キャプション(収録済)を理解する

収録済みの同期したメディア（音声付きの映像、いわゆる動画）に、視覚のみに依存する重要な情報（映像でのみ提供される重要な場面や動作など）が含まれる場合、その内容を伝えるために音声解説またはメディアの代替手段（テキストによる説明文書など）を提供する必要があります。
一般的には、映像そのものの進行と同時に解説が必要な場合は音声解説を、事前又は事後的にまとめられた文書でも理解できるようならテキストによる代替手段を、選択することが多いと思います。

【例1】映画やドラマにおいて、登場人物の行動や場面の切り替え、感情表現などが重要な場合、映像の進行に沿って音声解説による説明を追加することで、視覚に障害のあるユーザーにもリアルタイムでストーリーを理解できるようにします。

【例2】オンライン講座において、講師が黒板に書き込む内容やスライドの内容が映像で表示される場合、それらの視覚的な情報を事前ないし事後にテキストを配布し説明することで、視覚障害のあるユーザーも同じ内容を理解できるようにします。

ただし、その同期したメディアがテキストの内容を視覚的または聴覚的に補完する役割であり、そのように明確に表示されている場合（たとえばテキスト教材が主で、動画は単なる補足教材であるような場合）には、音声解説やメディアの代替手段は不要です。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.2.3 音声解説、又はメディアに対する代替(収録済)を理解する

ライブで配信される同期メディア（ライブ配信の動画、オンラインウェビナーなど）については、下記具体例のように、キャプション（字幕）が提供されている必要があります。
配信中に視覚だけではなく、聴覚情報もリアルタイムに補う必要があるためです。
人力（同時字幕オペレーター）を使う方法と、自動音声認識（ASR）を使う方法があります。

【例1】インターネットでのニュースのライブ番組では、アナウンサーの話している内容や重要な音響をキャプションでリアルタイムに表示し、聴覚に障害があるユーザーにも情報を提供します。

【例2】オンラインウェビナーでは、プレゼンターが話す内容や質疑応答をリアルタイムでキャプションとして表示し、聴覚に障害がある参加者でも内容を理解できるようにします。

これは、「達成基準 1.2.2 キャプション (収録済)」の強化された基準です。
達成基準 1.2.2は録画済みのコンテンツに適用されるのに対し、1.2.4はリアルタイムでキャプションを提供するための技術的な対応が必要なライブ配信のコンテンツに適用されます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.2.4 キャプション(ライブ)を理解する

収録済みの同期したメディア（音声付きの映像、いわゆる動画）に、視覚のみに依存する重要な情報（映像でのみ提供される重要な場面や動作など）が含まれる場合、その内容を伝えるために音声解説を提供する必要があります。
映像だけで示されている動作や表情・雰囲気など、視覚情報に頼る部分を音声で説明しないと、視覚障害のあるユーザーに重要な情報が伝わらない場合をカバーする基準です。

また、この基準は、「達成基準 1.2.3 音声解説、又はメディアに対する代替 (収録済)」が強化された基準です。
達成基準 1.2.3と異なり、テキストの代替手段は許容されず、視覚のみに依存する重要な情報がある場合には必ず音声解説を提供する必要があります。

ただし、音声解説が必要になるのは、映像だけでしか得られない重要情報が残っている場合ですので、もしナレーションや音声トラックが、画面上の重要な動きや情報を十分に言葉で伝えているなら、追加の音声解説は不要となります。

【例1】ニュース映像
アナウンサーが読んでいる原稿だけで、画面に映っているテロップや映像をほとんど説明しており、視覚情報が丸ごと音声でわかる場合は、追加の音声解説が不要となるケースに該当します。

【例2】インタビュー動画
画面に映る人の動きが会話の内容を補足するほど重要でない、あるいは口頭で「今、資料を手渡しています」などを説明しているなら、追加の音声解説は必要ないケースがあります。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.2.5 音声解説(収録済)を理解する

「1.3 適応可能」は、コンテンツの情報やユーザーインターフェース要素を、支援技術や異なる画面サイズ・表示方法でも失われることなく利用できるようにすることで、スクリーンリーダーなどを使う人を含め、誰もが必要な情報を把握しやすくするためのガイドラインです。

コンテンツ内の情報（テキスト）や構造（見出し、リスト、テーブル、フォームフィールドなど）が、下記具体例のように、プログラム上で正しく解釈できるように適切にマークアップされているか、テキストで提供されている必要があります。
見出しやリスト、テーブルなどを適切にマークアップし、視覚効果や位置だけで情報を伝えないことで、スクリーンリーダーにも情報構造が正しく伝わるようになります。

【例1】意味を持つ要素の適切なマークアップ
見出し（h1〜h6）、リスト（ul、ol）、段落（p）など、情報の構造や意味を表す要素には、適切なHTMLタグを使用してマークアップします。
これにより、スクリーンリーダーがページの情報を正しく伝えることができ、ユーザーがコンテンツの順序・内容を認識しやすくなります。

【例2】テーブルの適切な構造化
テーブルには、見出し（th）やセル（td）が適切に使用され、行や列の関係性を正しくマークアップします。
また、<caption>をつけたり、複数の行・列がある場合にscopeやheaders属性を活用したりします。
これにより、スクリーンリーダーがテーブルの情報を正しく読み上げ、ユーザーが情報を理解しやすくなります。

【例3】フォームの適切なラベリング
フォームフィールドには、対応するラベルを適切に関連付けます（label要素とinput要素の関連付けなど）。
なお、入力目的を特定するためのautocomplete属性については、達成基準 1.3.5 入力目的の特定【レベルAA】をご確認ください。
これにより、スクリーンリーダーが正しく読み上げ、視覚に障害のあるユーザーがフォームを正確に利用できるようになります。

【例4】テキストの視覚的提示を制御するためにCSS を使用
テキストの装飾や配置を制御するために、画像ではなくCSSを使用して、テキストの視覚的な提示を行います。
これにより、スクリーンリーダーがテキストを正しく読み上げ、視覚に障害のあるユーザーがコンテンツを理解しやすくなる他、ユーザーはテキストの拡大・色変更をしやすくなります（テキストの可変性については、達成基準 1.4.5 文字画像【レベルAA】をご確認ください）。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.3.1 情報及び関係性を理解する

コンテンツの内容が特定の順序で提示されることに意味がある場合、下記具体例のように、その順序が正しく維持され、支援技術（スクリーンリーダーやキーボード操作など）でも正しく解釈できるようにする必要があります。
文章やフォームなどの並び順が狂うと、利用者が情報を取り違えたり、誤入力したりするリスクがあるためです。

【例1】段落の並び順
文章の一部が特定の順序で並んでいる場合、その順序に依存して意味が伝わることがあります。
たとえば、ステップを説明する文章の場合、その順序が重要であることから、HTMLのマークアップもその順序を反映します。

【例2】順序付きリスト
順序付きリスト<ol>は順序が重要な場合に使われますが、CSSで順序をビジュアル的に変更した場合でも、HTMLコード自体の順序が意味のある順序を保ちます。
CSS で順番を変えても、あくまでソースコード上の順序が本質的に重要です。

【例3】複数段階の入れ子リスト
手順書などで、メイン手順→サブ手順と複数の階層を持つリストを使う場合には、HTML 上で <ol> や <ul> を正しく入れ子にし、階層構造が崩れないようにします。

【例4】表の順序
テーブルで行や列の順序に意味があるデータ（スケジュール表や多段階の見出し付き表など）を提示する場合には、テーブル内の行や列の順序、見出しセル<th>とデータセル<td>の対応関係を正しくマークアップして、スクリーンリーダーが行や列を移動した際に情報を誤読しないようにします。

【例5】フォーム内のラベルと入力フィールドの順序
フォームのラベルや入力フィールドの順序が、視覚的なレイアウトとHTML構造の両方で正しく整列されていることが必要です。
たとえば、見た目上はラベルがフィールドの右側に配置されているが、HTML上でラベルの要素が正しく関連付けられていない場合に、読み上げの順序がズレてしまうなど、スクリーンリーダーを利用するユーザーが困る状態にならないように設計することが求められます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.3.2 意味のあるシーケンスを理解する

ユーザーがコンテンツや操作を理解するために、下記具体例のように、視覚、聴覚、位置、形状、色などの感覚的な特徴だけに依存しないようにする必要があります。
色覚障害や視覚障害、聴覚障害、あるいはレイアウトが変化する環境（モバイル表示など）では、位置や色、形状など特定の情報のみでは情報を取得しにくいためです。

【例1】色のみに頼らない例
「必須項目は赤で表示されます」という指示だけではなく、「*必須」と記号を使って、色覚障害のあるユーザーにも必須項目が分かるようにします。

【例2】位置のみに頼らない例
「右側のボタンを押してください」ではなく、「送信ボタンを押してください」とボタンの機能を明示します。

【例3】形状のみに頼らない例
「矢印アイコンのボタンを押してください」ではなく「送信ボタンを押してください」とボタンの機能を明示します。

【例4】音のみに頼らない例
音での合図を出すのではなく、画面にテキストも表示します。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.3.3 感覚的な特徴を理解する

下記具体例のように、ユーザーがデバイスの表示向きに関わらず、コンテンツを横向きまたは縦向きのどちらでも自由に閲覧できるようにする必要があります。
たとえば、デバイスを固定して利用する方（車いすやスタンドに取り付けているなど）が物理的に画面の向きを回転できない場合など、ユーザーが縦向き・横向きを選択できる必要があるケースがあるからです。

【例1】Webページ・モバイルアプリのレイアウト
Webページやモバイルアプリが縦向きで閲覧されることを前提に設計されている場合でも、デバイスを横向きに回転させた場合に、同じ情報や機能が正しく提供される必要があります。
また、コンテンツ制作者側が画面を固定するロック機能を用いないことが求められます。

ただし、特定のディスプレイの向きが必要不可欠な場合は除かれます。

【例2】銀行の小切手を表示するディスプレイの場合には、小切手のサインを確認するために、横向きであることが必要不可欠な場合となります。

【例3】ピアノのアプリケーションの場合には、鍵盤が横長かつ演奏操作の都合上、横向きであることが必要不可欠な場合となります。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.3.4 表示の向きを理解する

下記具体例のように、Webページやアプリケーションのフォームにおいて、ユーザーが入力するフィールドの目的（名前、住所、クレジットカード番号など）をプログラム上で提供し、かつ入力データの意味を特定するのに適切なサポート技術を用いて実装される必要があります。

【例1】名前入力フィールド
ユーザーが名前を入力するフィールドにautocomplete="name"を設定します。
これにより、支援技術やブラウザはそのフィールドが名前を入力する場所であると認識し、適切な自動補完や入力支援を行います。

【例2】住所入力フィールド
住所を入力するフィールドにautocomplete="address-line1"やautocomplete="postal-code"を設定すると、ユーザーが以前に入力した住所情報が自動的に補完されるか、支援技術がユーザーのために入力支援を提供することが可能になります。

【例3】メールアドレス入力フィールド
メールアドレス入力フィールドにtype="email"を設定すると、対応ブラウザや支援技術が最適なキーボードレイアウトを表示したり、入力を補助したりできるようになります。

【例4】電話番号入力フィールド
電話番号入力フィールドにtype="tel"を設定すると、対応ブラウザや支援技術が数字パッドを優先表示したり、入力を補助したりできるようになります。

【例5】クレジットカード情報入力フィールド
クレジットカード番号の入力フィールドにtype="text"とautocomplete="cc-number"を組み合わせて設定することで、ユーザーが安全に入力を行う際に自動補完を使用できます（ただしセキュリティポリシーによってはCVVコードなどの特定の秘密情報については自動補完を無効化する場合もあります）。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.3.5 入力目的の特定を理解する

「1.4 判別可能」は、利用者がコンテンツのテキストや要素を視覚的・聴覚的に認識しやすくするためのガイドラインです。

下記具体例のように、「色の使用」は、Webコンテンツの情報が色のみに依存して伝達されないようにする必要があります。
色だけで情報を伝えると、色覚特性を有するユーザーやモノクロの表示環境を使用しているユーザーに情報を正確に伝えられないことがあるからです。

【例1】リンクのテキストを青色にするだけではなく、下線を引くことでリンクであることを視覚的に強調します。

【例2】入力フォームにおいて、必須項目を赤色アスタリスク (*) だけで表現せず、明示的に『必須』と書くなど、誰でも分かるようにします。

【例3】チャートやグラフについては、データの差異を色だけで表現するのではなく、異なるパターンやラベルを使用することで、色が識別できないユーザーにも理解できるようにします。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.4.1 色の使用を理解する

Webページで自動的に再生される音声コンテンツが3秒以上続く場合には、ユーザーがその音声を停止、一時停止（一時停止・再生ボタンなど）、または音量を調整できる手段（音量調整スライダー、ミュート機能など）を提供することが必要です。
3秒以内の短い音声コンテンツであればユーザーの集中をそこまで阻害しませんが、それを超える音声が勝手に流れ続けるとスクリーンリーダーを利用するユーザーであったり、音声が再生されているときに視覚的なコンテンツに集中することが困難なユーザーにとって、邪魔になることがあるからです。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.4.2 音声の制御を理解する

テキストや画像内のテキストの視認性を確保するため、前景色（文字の色など）と背景色の間に十分なコントラスト（少なくとも 4.5:1）を提供することが必要です。

ただし、次の例外が認められます。

①　大きな文字
大きなテキスト（18pt以上のテキストや14ptの太字、約24px以上の文字、または約18.5pxの太字が目安）については、コントラスト比が3:1以上であれば基準を満たします。

②　文字が付随的な場合
文字が、アクティブではないUIコンポーネントの一部である場合、純粋な装飾である場合、スタイルシートで画面外に配置されているなど誰も視覚的に確認できない場合、重要な他の視覚的なコンテンツを含む写真の一部分である場合については、最低限のコントラスト比は求められません。

③　ロゴタイプ
ロゴやブランド名の一部である文字には、ブランドイメージに関わり色や形状を変更できないことがあるため、最低限のコントラスト比は求められません。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.4.3 コントラスト(最低限)を理解する

ユーザーがテキストのサイズ拡大（Text-Only Zoom）機能やページ全体の拡大（Full-Page Zoom）機能などを使って、テキストサイズを200%まで拡大しても、コンテンツの機能や情報が失われないように設計することが必要です。

ただし、次の例外が認められます。

①　キャプション
キャプションは、動画や音声コンテンツで提供される「音声情報のテキスト表現」です。
たとえば、YouTubeの字幕・キャプションは、プレイヤーの設定で文字サイズや背景色を変更できるようになっていますが、それはユーザーエージェントや再生ソフト側の機能によるもので、コンテンツ制作者が任意にコントロールできない部分であることから、例外として扱われます。

②　文字画像
文字画像は、文字をテキストではなく「画像」として埋め込んでいるケースを指します。
通常、ブラウザの「テキストサイズ変更」機能では拡大されず、画像のままなので本来は拡大・色変更が困難であることから、例外として扱われます。
なお、文字画像については、達成基準 1.4.5 文字画像【レベルAA】にて、文字画像自体を原則避けるように求められています。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.4.4 テキストのサイズ変更を理解する

装飾や特別な理由がない限り、テキストを画像で表現せず、HTMLなどでテキストを直接記述することが必要です。
テキストを画像で表示すると、テキストの拡大や色変更が困難になり、視覚的な調整ができなくなる（可変性が損なわれる）からです。

【例1】ナビゲーションメニューを画像で作成するのではなく、CSSやHTMLを使ってテキストを表現します。

【例2】ボタンやバナーに特定のフォントを使用している場合でも、@font-faceやWebフォントなどを利用して、デザイン性を保ちながらテキスト表示を行います。

ただし、次の例外が認められます。

①　カスタマイズ可能な場合
画像で表現された文字でも、利用者が色やサイズなどを自由に変更できるような仕組みが備わっていれば、通常の文字と同等の可変性があるため例外として許容されます。

②　ロゴや特別な効果で文字画像であることが必要不可欠な場合
ブランドロゴなどのデザイン上不可欠な文字画像や、法律によって表示方法が指定されている場合など、文字画像であることが必要不可欠な場合には例外的に許容されます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.4.5 文字画像を理解する

下記具体例のように、ユーザーがデバイスやブラウザの画面サイズを変更しても、2次元スクロール（縦横両方向への同時スクロール）を必要とせずにWebコンテンツを閲覧できるように設計する必要があります。

2次元スクロールというのは、非常に分かりにくい表現ですが、例えば横書きのコンテンツなど、縦スクロールで閲覧されることが予定されている場合には、ユーザーが横スクロールを強いられないようにすることが求められます。

一方で、例えば縦書きのコンテンツ（Kindleの一部日本書籍などがイメージしやすいと思います）など、横スクロールで閲覧されることが予定されている場合には、ユーザーが縦スクロールを強いられないようにすることが求められます。

①　横書きのコンテンツ（通常のケース）
画面の幅が 320 CSS ピクセル（スマートフォン縦向き程度の幅）になっても、縦スクロールだけでコンテンツが問題なく閲覧できるようにする必要があります。
たとえば、ニュース記事やブログのような主にテキストが主体のコンテンツでは、リフロー（改行や段組の再配置）を行うことで横スクロールバーが出ないデザインにします。

【例】テキストや画像が画面幅に合わせて自動的に段組みされ、折り返されるようにすることで、横スクロールバーが表示されず、縦スクロールだけで内容を読み進められるようにします。

②　縦書きのコンテンツ（例：縦書きの日本語テキストなど）
通常の横書きとは逆に、横スクロールが前提となるため、今度は高さが 256 CSS ピクセル（スマートフォンを横向きにしたときなど）になっても、縦スクロールが不要になるように設計する必要があります。

【例】電子書籍の縦書きビューアのように、横方向へページ送りする想定の場合、縦スクロールをせずにすむレイアウトに設計します。

ただし、以下のようなケースでは「リフロー」によってコンテンツの意味や機能が損なわれるため、2次元スクロールがやむを得ず必要となっても例外的に認められます。

①　地図やフローチャートなどの複雑なレイアウト
地図や複雑なグラフ、設計図など、位置関係が重要なもので、リフローすると要素同士の位置関係が崩れてしまい、正しい情報を提供できなくなる場合については、この基準は適用されません。

②　2次元スクロールが不可欠なコンテンツ
表やスプレッドシートのように、横方向にも多くの列があるテーブルなどでは、リフローで無理に折り返すと、かえって内容の関連性が分かりにくくなる場合については、この基準の例外として認められます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.4.10 リフローを理解する

UIコンポーネントやグラフィカルなオブジェクトにおいては、前景色と背景色のコントラスト比を少なくとも 3:1 にする必要があります。

①　UIコンポーネント
ボタン、フォームコントロール（チェックボックス、テキストフィールドなど）、アイコンを用いたボタン、グラフ内の操作要素などのUIコンポーネントは、前景色と背景色のコントラスト比が少なくとも 3:1であることが求められます。

②　グラフィカルなオブジェクト
アイコン、インフォグラフィックス、グラフ（棒グラフ、折れ線グラフなど）内のデータを表す色付きエリア・線などグラフィカルなオブジェクトは、前景色と背景色のコントラスト比が少なくとも 3:1であることが求められます。

ただし、装飾的な要素（単なる背景模様や飾り線、情報伝達に関わらない装飾イラストなど）、非アクティブなUI要素（「無効」状態のボタンや読み取り専用フィールドなど、操作対象にならないもの）、視認性に影響を与えない要素（ロゴやブランディングなど、コントラスト比を強制することで意味が損なわれるもの）については、十分なコントラスト比は必要とされません。

なお、非アクティブなUI要素については、ユーザーが認識する必要がある状態表示（有効／無効の区別）をデザインする場合は、他の要素とのコントラストにも配慮することが望ましいとされています。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.4.11 非テキストのコントラストを理解する

次の4つの要件をすべて満たすことで、ユーザーが、ブラウザやOSの拡大機能、ユーザースタイルシート、アクセシビリティ支援ツールなどで行間や文字間を変更してもレイアウトが崩れたり（ボタンやリンクのテキストが折り返されてしまって押しにくくなる、ツールチップやフォームのラベルが重なるなど）、コンテンツや機能が損なわれる（行間を拡大したら文字が重なる、文字間を広げたらボタンやリンクが隠れるなど）ことがないようにする必要があります。

①　行間(line-height)
行間は、テキストのフォントサイズの少なくとも1.5倍にします。

【例】文字サイズが16pxの場合、line-heightを24px（1.5倍）以上にします。

②　段落間隔
段落間のスペースは、テキストのフォントサイズの少なくとも 2倍にします。

【例】文字サイズが16pxの段落では、段落と段落の間を32px（2倍）以上にします（marginやpaddingで指定）。

③　文字間隔(letter-spacing)
文字間は、文字のフォントサイズの少なくとも0.12倍にします。

【例】文字サイズが16pxの場合、letter-spacingを1.92px（16×0.12）以上にします。

④　単語間隔(word-spacing)
単語間は、単語のフォントサイズの少なくとも0.16倍にします。

【例】文字サイズが16pxの場合、word-spacingを2.56px（16×0.16）以上にします。

ただし、アイコンフォントやロゴ、固定レイアウトの画像テキストには、この基準は適用されません。
アイコンフォントやロゴは、実質的には画像・記号として扱われ、文字情報を伝えるものではないからであり、固定レイアウトの画像テキストについては、ユーザーが文字間隔などを調整できないからです。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.4.12 テキストの間隔を理解する

マウスホバーまたはキーボードフォーカスによって表示されるポップアップやツールチップなどの追加コンテンツに関しては、次の3つの要件をすべて満たす必要があります。

①　非表示にすることができる
ホバーまたはフォーカスで表示された追加コンテンツについては、ユーザーが自分で消去できる仕組みを提供する必要があります。
具体的には、ポップアップを閉じるための明示的な「閉じる」ボタンや閉じるためのキーボード操作などです。

ただし、エラー通知で、ユーザーが内容をきちんと確認するまで自動的に消さないほうが望ましい場合や、そもそも追加コンテンツの表示が他のコンテンツを妨害しない場合については、本要件を満たす必要はありません。

②　ホバーすることができる
表示された追加コンテンツ内でユーザーがポインタを動かしても、そのコンテンツが消えないようにする必要があります。
たとえば、マウスを重ねるとサブメニューが出現し、サブメニュー内をクリックできるようにしたり、サブメニュー内にカーソルがある限り消えないようにするなどです。

③　表示が継続される
ユーザーがホバーまたはフォーカスを外したり、追加コンテンツを自発的に消去したり、あるいはその追加コンテンツの情報が有効でなくなる（例えば、操作方法の説明が追加コンテンツとして表示された後に、実際に操作が完了した場合）までは、追加コンテンツの表示が継続される必要があります。

なお、追加コンテンツの視覚的な表示がユーザーエージェントによって制御されており、コンテンツ制作者がその表示方法を変更できない場合（例えば、HTMLのtitle 属性を用いて作られているブラウザのツールチップなど）には、達成基準 1.4.13の要件は適用されません。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準1.4.13 ホバー又はフォーカスで表示されるコンテンツを理解する

「2.1 キーボード操作可能」は、すべての機能をキーボードから利用できるようにすることで、多様な利用者がサイトを円滑に使えるようにするためのガイドラインです。

Webコンテンツのすべての機能が、個々のキーストロークに特定のタイミングを要することなく、キーボードだけで操作可能な状態である必要があります。
キーボードを使ったナビゲーションや操作ができることは必須ですが、「キーボードのみ」に限定するわけではなく、他の入力方法（マウス入力など）も併用することは禁じられていません。

【例1】Tabキーを使用してフォーカスを移動し、EnterキーまたはSpaceキーを押すことでリンクやボタンをクリックできるようにします。

【例2】キーボードのみでフォームの各フィールドへアクセスし、正しく入力して送信ボタンを押せるようにします。

【例3】「短い時間のうちに複数回キーストロークを行わなければいけない」仕様や「キーを長押しし続ける必要がある」仕様など、タイミング依存の操作を強要する仕様は本基準に適合しません。

ただし、その根本的な機能が「ユーザーの動作による終点だけではない軌跡」を必須とする場合（一連の連続的な動きがなければ機能の目的を果たせない場合）には、この基準は適用されません。

【例4】手書き認識や筆圧・軌跡に依存する描画ツールは、筆で描くような動きを忠実に取り込むことが機能の本質であり、キーボードだけで代替操作が難しいため、この基準の例外となります。

【例5】テキスト入力を手書き入力で行うケースでは、文書（テキスト）という最終アウトプットは、キーボードによる文字入力が可能なため、「根本的に連続的な軌跡」を必要とするわけではありません。
この場合には、テキスト入力という機能自体はキーボードで代替できるので、この場合は本基準が適用されます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準2.1.1 キーボードを理解する

Webコンテンツにおいてキーボードを使用しているユーザーが、ある要素にフォーカスを当てたときに、その要素からキーボード操作で抜け出せなくなるような状況（キーボードトラップ）を防止する必要があります。

なお、その他の標準的な方法（Escキー、Tabキー、Shift+Tabキーなど）でキーボードトラップから抜け出せないことが避けられない場合には、ユーザーにその状況から抜け出すための手段が明示されているか、抜け出すための操作が提供されていること（ダイアログウィンドウが開く際に「Escキーを押すと閉じることができます」とツールチップやヘルプテキストで伝えるなど）が求められます。

【例1】ダイアログボックスやモーダルウィンドウを開いた際、キーボード（通常はTabキーですが他のキーでも可能）を使ってボックス内の要素にフォーカスを移動でき、かつ適切なキー操作（通常はEscキーが使われますが他のキーでも可能）でモーダルを閉じられるようにします。この時、ダイアログを閉じたあとに画面内を探し回らなくて済むように、モーダルを開いたきっかけとなったボタンにフォーカスを戻すことが推奨されます。

【例2】キーボードを使ってページ内のあるボタンにフォーカスした際に、次の要素にフォーカスが移動できずそのボタンから出られなくなる状況は、キーボードトラップに該当し本基準に違反します。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準2.1.2 キーボードトラップなしを理解する

単一の印字キー（アルファベット、数字、記号、スペースキーなど文字・数字・記号などを入力するためのキー）を使って実行されるショートカットがコンテンツに実装されている場合、次の3つの要件のいずれかを満たしている必要があります。

①　解除
ユーザーがショートカットを無効化するためのメカニズムをオプションなどで提供します。

②　再割り当て
非印字キー（Ctrl、Alt、Shift、Tab、Functionキーなど）と組み合わせたショートカットへの再割り当てが可能であるメカニズムを提供します。

【例】「S」キーで検索バーが開くショートカットが実装されている場合、入力の最中で「S」キーを押されただけで意図しない操作が発動しないように、「Ctrl+S」にショートカットを再設定することができるオプションを提供します。

③　フォーカス中にのみ有効化
UIコンポーネントがフォーカスされているときのみショートカットを有効化するメカニズムを提供します。

【例】対象のボタンやテキストエリアなどにフォーカスがあるときだけショートカットが動くようにすることで、他の文書入力の最中には誤って発動しないようにします。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準2.1.4 文字キーのショートカットを理解する

「2.2 十分な時間」は、利用者がコンテンツを読み、使用するために十分な時間を確保するためのガイドラインです。

時間制限のあるコンテンツに関しては、ユーザーが十分な時間でコンテンツを利用できるように、次の3つの方法 (①～③) のいずれかを提供する必要があります。
ただし、特定の例外 (④～⑥) に当てはまる場合は、必ずしもそれらを提供しなくても構いません。

①　解除
ユーザーがコンテンツを利用する前に、制限時間を無効化できる機能を提供します。

【例】制限時間のあるアンケートで、「制限時間なしで回答する」オプションを開始前に選べるようにします。

②　調整
制限時間が設定されている場合、ユーザーがその制限時間を大幅に（デフォルトの少なくとも10倍）延長できるようにします。

【例】セッションタイムアウトが近づいたら、ユーザーに通知し、「延長する」ボタンを押して続行できるようにします。

③　延長
時間切れの前に警告し、少なくとも20秒間の猶予を与えて、簡単な操作（例：Spaceキーを押す）で制限時間を延長できるようにします。
制限時間は少なくとも10倍まで延長可能にします。

【例】オンラインショッピングの決済ページで、デフォルトの制限時間として5分（300秒）が設定されている場合、制限時間の終了が近づいたときに、ユーザーに「残り20秒です。延長しますか？」といった警告メッセージを表示します。ユーザーが「延長」ボタンをクリックするかSpaceキーを押すと、少なくとも猶予時間の10倍である200秒（3分20秒）まで延長可能にします。

④　リアルタイムの例外
リアルタイムのイベントにおいて、制限時間がそのイベントの本質的な要素であり、代替手段が存在しない場合は例外となります。

【例】オンラインオークションで、終了時間が定められており延長できない場合。

⑤　必要不可欠な例外
制限時間を取り除くとコンテンツの目的が損なわれる場合、例外となります。

【例】Web上の試験で制限時間があること自体が評価方法の一部である場合。

⑥　20時間の例外
制限時間が20時間を超える場合、事実上ほとんどのユーザーにとって時間切れにならないと想定されるため、例外となります。

【例】アカウントが20時間以上使用されないとログアウトされるWebサービス。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準2.2.1 タイミング調整可能を理解する

動くコンテンツ、点滅するコンテンツ、スクロールするコンテンツ、または自動的に更新されるコンテンツがある場合、以下の要件をすべて満たす必要があります。
これらは、ユーザーが並行して表示される他のコンテンツを閲覧したり操作したりする際に、注意を奪われたり混乱したりしないよう配慮することを目的としています。

①　動く、点滅する、スクロールするコンテンツ
動く、点滅する、スクロールするコンテンツで、それらが自動的に開始し、5秒以上続き、かつその他のコンテンツと同時に表示される場合（スライダー・バナー広告・連続スクロールするテキストなど）、ユーザーに、それらを一時停止、停止、または非表示にすることができる機能を提供することが求められます。

ただし、その動き、点滅、スクロールが必要不可欠な場合（たとえば、警報システムの点滅やオンラインテストのカウントダウンなど、動き自体が機能の本質であり、停止させると目的を果たせない場合）には例外となります。

点滅の頻度が1秒間に3回を超える場合は、達成基準2.3.1 3回の閃光、又は閾値以下にも関わるため、そちらも併せて遵守する必要があります。

②　自動更新されるコンテンツ
自動的に開始し、他のコンテンツと並行して提示される更新情報（ニュースフィードやSNSタイムライン、株価リストなど）の場合、利用者がそれを一時停止、停止、非表示、あるいはその更新頻度を調整できる機能を提供することが求められます。

ただし、その自動更新が必要不可欠な場合（たとえば、監視システムや金融取引プラットフォームなど、リアルタイム更新が不可欠で、更新を止めたり頻度を変えたりすると機能の目的を果たせなくなる場合）には例外となります。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準2.2.2 一時停止、停止、非表示を理解する

「2.3 発作と身体的反応」は、発作や身体的反応を引き起こすようなコンテンツを設計・実装しないようにするためのガイドラインです。

Webページのコンテンツは、1秒間に3回を超える閃光がないか、または閃光が一般閃光閾値（コントラストの強いフラッシュや変化が視覚的に刺激を与えない基準）及び赤色閃光閾値（特に強い刺激を与える赤色フラッシュについての基準）を下回ることが必要とされます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準2.3.1 3回の閃光、又は閾値以下を理解する

「2.4 ナビゲーション可能」は、利用者がサイト内を効率的に移動し、必要なコンテンツを見つけられるようにするためのガイドラインです。

主にキーボードを利用しているユーザーやスクリーンリーダーを使用しているユーザーが、スクリーンリーダーやキーボード操作を行っている場合に、毎回長いナビゲーションやサイドバーなどの繰り返しブロックを一つひとつ読み飛ばす必要があると不便であることから、主要コンテンツにすばやく移動できる手段（「メインコンテンツへスキップ」リンクなど）を提供することが必要とされます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準2.4.1 ブロックスキップを理解する

ページタイトルには、そのページが扱うトピックや目的を簡潔かつ正確に示す必要があります。
これにより、ユーザーは、ブラウザのタブ切り替えなどの状況で、どのページを開いているかを即座に把握できるほか、スクリーンリーダーなど支援技術を使用する際にもページ内容を予測しやすくなります。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準2.4.2 ページタイトルを理解する

キーボード操作などでページ内を移動する際に、フォーカスが論理的かつ予測可能な順序で移動する必要があります。
フォーカス移動の順序を考慮することで、ユーザーはWeb制作者が意図した通りの手順でコンテンツを利用でき、操作ミスや混乱を防ぐことができます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準2.4.3 フォーカス順序を理解する

リンク先の内容や機能をユーザーが正確に把握できるようにする必要があります。
リンクテキストや周辺の文脈から「何のためのリンクか」をわかりやすく伝えることで、支援技術を使用している方やキーボード操作を中心に利用する方が、目的の情報へスムーズにアクセスできるようになります。

ただし、元々リンク先の目的自体がはっきりしておらず、どのように説明しても多くのユーザーにとって曖昧なままになってしまうような場合には除外されます。

なお、本記事におけるコンテキストとはページ内の文脈や、画面・UI の状態などを含む「利用者の操作環境全体」を意味するものとします。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準2.4.4 リンクの目的 (コンテキスト内) を理解する

ユーザーが特定のページや情報にアクセスするための「複数の経路」を提供する必要があります。
例えば、グローバルナビゲーションからの経路の他にも、検索機能からの経路、フッターのサイトマップからの経路など、複数の移動手段を用意することで、支援技術を使う方を含め、ユーザーがスムーズに目的のコンテンツを見つけられるようになります。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準2.4.5 複数の手段を理解する

ページ内のセクション見出しやフォームのラベルなどに、目的や内容をわかりやすく示すテキストを用いる必要があります。
見出しやラベルが適切であると、支援技術のユーザーが、どこにどのような情報があるのか素早く把握しやすくなります。
また、ページ内の構造や内容の関連性が明確になるため、利用者は必要な情報に効率よくアクセスできるようになります。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準2.4.6 見出し及びラベルを理解する

キーボードなどで操作中にフォーカスの位置が視覚的にわかるようにする必要があります。
フォーカスがどこにあるかが明確に示されることで、支援技術を使う方やキーボード操作が中心のユーザーが、入力や操作を正確かつ効率的に行えるようになります。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準2.4.7 フォーカスの可視化を理解する

キーボード操作時などに表示されるフォーカスが、画面上で隠されることなく十分に視認できる必要があります。
フォーカスの視認性を維持することで、支援技術を利用する方やキーボード操作が中心のユーザーが、どの要素が選択されているかを正確に把握しやすくなります。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.2解説書 達成基準2.4.11 隠されないフォーカス(最低限)

「2.5 入力モダリティ」は、多様な入力方法（キーボードやマウス、タッチ、音声入力など）を用いるユーザーが、サイトの機能を問題なく利用できるようにするためのガイドラインです。

複雑なポインタ操作（例えば、ドラッグやマルチタッチなど）を伴う機能には、単純なクリックやタップなどでも同等の操作が行える手段を提供する必要があります。
これにより、障害のあるユーザーや操作デバイスに制約のあるユーザーも、同等の操作を行いやすくなります。

ただし、たとえば「指で軌跡を描く」「複数本の指で操作する」「手書きで署名を入力する」などの複雑なジェスチャ自体が不可欠な機能である場合や、目的の本質になっている場合には、単一タップやクリックでは代替できないため、そのジェスチャを必須とすることが許容されます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準2.5.1 ポインタのジェスチャを理解する

ポインタ（マウスやタッチ操作など）によるアクションが誤って開始・実行されないようにする仕組みを実装する必要があります。
こうした対策により、誤ったクリックやタップでユーザーが意図しない動作を実行してしまうことを避けることができます。
具体的には、ドラッグ・ドロップの操作を確定する前に「キャンセル」できたり、長押しの操作を行う場合でも誤操作を防いだりするような配慮として、次の4つの要件のうち、少なくとも一つを満たす必要があります。

①　ダウンイベントがない
ポインタを押し下げる（マウスダウン・タッチダウン）操作だけで機能が発動しないようにする方法です。

②　中止又は元に戻すことができる
ダウンイベントで操作を開始しても、機能が完了するのはアップイベントのタイミングにし、完了前に操作を「中止」できる、あるいは完了後に操作を「元に戻す」手段を提供する方法です。

③　アップイベントで反転
アップイベントが発生した時点で、先に行われたダウンイベントによる操作内容を「取り消す（反転する）」手段を提供する方法です。

④　必要不可欠
「ダウンイベントで即実行する」こと自体が機能の本質であり、代替が難しい場合は例外とされます。
たとえば、楽器アプリの鍵盤を押し下げた瞬間に音が鳴るなど、ダウンイベントによる即時動作が不可欠な機能が該当します。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準2.5.2 ポインタのキャンセルを理解する

画面上に表示されるテキスト（ラベル）が、そのUIコンポーネントのプログラムで利用される「名前（accessible name）」にも含まれる必要があります。
視覚的なラベルと音声入力などで使われる「名前」が一致していないと、支援技術のユーザーが思った通りのコマンドを実行できないなど、操作性に影響が出てしまうためです。
したがって、ボタンやリンクなどのラベルは、見た目とプログラム上の名前を揃えて指定する必要があります。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準2.5.3 ラベルを含む名前 (name) を理解する

物理的な動作（例えば、デバイスを振る、回す、傾けるなど）で機能を起動できる場合、同じ操作を物理的な動き以外でも行える代替手段を提供する必要があります。
また、意図しない動作（誤操作）を防ぐため、動きによる入力をオフにしたり、キャンセルしたりできる仕組みの用意も求められます。
なお、次の2つの場合には除外されます。

①　サポートされたインタフェース
特殊なセンサーや専用デバイスによって、支援技術ユーザーも支障なく利用できるインタフェースが既に確立しているようなケースを指します。

②　必要不可欠
アプリがスマホの回転や加速度センサーを利用して運動データを計測するような機能を提供しており、動きがなければその機能自体が成り立たない場合などを指します。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準2.5.4 動きによる起動を理解する

ドラッグ＆ドロップ操作など「ポインタを長押ししながら移動する」動作に代わる操作手段を提供する必要があります。
例えば、キーボードや単純なクリック（タップ）のみで同様の操作が行えるようにすることで、支援技術を利用する方やマウス操作が困難な方など、あらゆる利用者が正確に操作を行えるよう配慮することが求められます。

ただし、ドラッグ操作そのものが機能の本質・目的であり、代替操作を提供できない場合（例えば、ペイントツールの筆を動かして描画する機能など）や、ブラウザやOS側の制御によって、ドラッグ操作が固定的に決まっている機能で、制作者自身では変更や代替手段の提供ができない場合には、ドラッグ以外の方法で同じ操作を実現することが難しく、例外扱いとなります。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.2解説書 達成基準2.5.7 ドラッグ動作

リンクやボタンなど、ユーザーがポインタ操作で選択するターゲットの領域を一定の最小サイズ以上に保つ必要があります。
タップやクリックなどの誤操作を減らし、操作しやすくするための要件であり、少なくとも 24×24 CSSピクセルが求められます。

ただし、次の5つの場合は除外されます。

①　間隔
複数の小さなターゲット（24×24 CSS ピクセル未満）が隣接している場合において、それぞれのターゲットの「中心」に直径 24 CSS ピクセルの円を想定したときに、その円が他のターゲットや他のターゲットの円と重ならない程度に充分なスペースが確保されているケースでは、ターゲットそのものは小さいままでも、誤タップ・誤クリックが起きにくいため許容されます。

②　同等
例えば、小さいアイコンが押しにくい状態であったとしても、同じ操作を別の大きなボタンで代替できるなら、この小さなターゲット単体は必ずしも要件を満たさなくても許容されます。

③　インライン
リンクやボタンなどが文章中に埋め込まれており、テキストの行間・行の高さなど、デザイン上の制約でターゲットサイズを大きくできない状況下では、許容されます。

④　ユーザーエージェントのコントロール
ターゲットのサイズ自体がブラウザやOSなどユーザーエージェントのデフォルト挙動によって決定され、コンテンツ制作者が変更できない場合には、例外として許容されます。

⑤　必要不可欠
例えば、公式書類や法的文書において「原本通りの表示」が求められており、レイアウト変更自体が不可能なケースでは、ターゲットを特定のサイズ・形状で提示することが機能・コンテンツの本質であり、例外として許容されます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.2解説書 達成基準2.5.8 ターゲットのサイズ (最低限)

「3.1 読み取り可能」は、テキストコンテンツを利用者が理解しやすい形で提供することで、支援技術を使う方や言語能力が異なる方を含め、すべての利用者が読みやすく理解しやすい状態を保つためのガイドラインです。

各ページにおいて、使用されている主な言語をプログラムで特定可能にする必要があります。
具体的には、HTML の言語属性（lang属性）を正しく設定し、支援技術がテキストを適切に読み上げたり、言語特有の機能を正しく適用したりできるようにすることが求められます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準3.1.1 ページの言語を理解する

各ページにおいて、一部だけ別の言語で書かれている場合、その部分を適切な言語属性（lang属性）でマークアップする必要があります。
これにより、支援技術が言語ごとに正しく読み上げを切り替えたり、翻訳ツールが正確に処理したりできるようになり、利用者がコンテンツをより理解しやすくなります。

ただし、次の場合には別言語としてのマークアップ（lang属性）を必ずしも付与しなくてもよいとされています。

①　固有名詞
地名、人名、ブランド名など、そのまま他言語由来であっても、固有名詞として扱われるもの。

②　技術用語
「Homo sapiens」「hertz」のように、元が外国語でも、専門分野で一般的に使われていて、その分野の人にとっては日常的かつ専門用語として機能しているもの。

③　言語が不明な語句
ネット用語のように、どの言語か判別しにくい、または特定の言語に属さない造語・スラングなど。

④　すぐ前後にあるテキストの言語の一部になっている単語や語句
日本語の文章中に普通に使われる英語由来のカタカナ語のように、一時的に別の言語を使っていても、周辺の文脈から「その言語の一部」として自然に組み込まれている場合。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準3.1.2 一部分の言語を理解する

「3.2 予測可能」は、Webページの操作や挙動について予測しやすい状態を保つことで、ユーザーが混乱せずに操作を続けられるようにするためのガイドラインです。

リンクやフォームなどの要素にフォーカスが移っただけで、自動的にコンテキストの変更が起こらないようにする必要があります。

コンテキストの変更とは、単にコンテンツのテキストや画像が少し変わるというものではなく、次の例ように、利用者が操作中に思わぬ状況変化が起こり、混乱を招くような画面変更全般を指します。

【例1】リンクやフォームなどの要素にフォーカスが移ると、自動で新しいページへ遷移してしまう

【例2】リンクやフォームなどの要素にフォーカスが移ると、ポップアップウィンドウが表示されるなど、重要なコンテンツ領域が変更される

【例3】リンクやフォームなどの要素にフォーカスが移ると、フォーカスが更に予期せぬ移動をする

【例4】リンクやフォームなどの要素にフォーカスが移ると、スクリーンリーダーが読み上げる順序が大きく変わるような切り替えがおこる

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準3.2.1 フォーカス時を理解する

フォームの入力フィールドやドロップダウンメニューなどでユーザーが値を変更した際に、ユーザーの意図に反して予期しないコンテキスト変更が起こらないよう配慮する必要があります。
たとえば、ドロップダウンメニューにて選択した直後に自動的に画面が切り替わるのではなく、ユーザーが「送信」ボタンを押すなど、明示的なアクションを起こして初めて画面遷移が行われる設計にする必要があります。
※コンテキスト変更については、上記「達成基準3.2.1 フォーカス時【レベルA】」を参照してください。

ただし、事前にユーザーに対して「このボタンを押すと画面が切り替わる」「このフィールドに入力すると即座にページが更新される」などの挙動を明示的に説明されていればコンテキスト変更が起こってもよいとされています。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準3.2.2 入力時を理解する

サイト内で共通するナビゲーション要素（ヘッダーメニューやサイドバーなど）の配置や項目の順序を、ページ間で一貫して提供する必要があります。
これにより、利用者は操作の流れを学習しやすくなり、別のページへ移動しても迷わずに必要な情報へ素早くアクセスできるようになります。

ただし、たとえばユーザーがマイページにログインした場合や言語設定を切り替えた場合など、ユーザーが意図的にコンテンツ及びそれに付随するメニュー構成を変えた場合には、この達成基準の対象外となります。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準3.2.3 一貫したナビゲーションを理解する

同じ機能や目的を持つボタンやアイコンなどのUIコンポーネントを、ページ間で一貫したデザインやラベルで示すことが必要です。
検索アイコンや送信ボタンといった機能がページによって違うラベル・アイコンを使っていると、ユーザーは混乱しやすくなることから、同じ機能には同じ見た目やテキストを用いることで、ユーザーが直感的に操作方法を理解しやすくなります。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準3.2.4 一貫した識別性を理解する

サイト内に、「電話番号」「問い合わせフォーム」「（担当者がリアルタイムで担当する）チャットボット」（「人間への連絡先」「人間への連絡メカニズム」の例）や「FAQ（Q&A）」「オンラインマニュアル」「ユーザーガイド」「サポート記事の検索機能」ないし「チュートリアル動画」（「自己解決のためのオプション」の例）あるいは「AIによるチャットボット」「自動音声応答システム 」「自動化されたサポートチケット発行システム」（「完全に自動化された連絡メカニズム」の例）などのサポート機能のいずれかがある場合、それらを各ページで一貫した方法・位置・ラベルなどで提供する必要があります。
これにより、ユーザーが別のページへ移動しても、ヘルプや問い合わせ先を迷わず見つけることができ、操作の継続やトラブル解決をしやすくなります。

ただし、次の場合にはこの基準の対象外とされています。

①　そもそもヘルプや問い合わせ機能自体が存在しない場合
この達成基準は「ヘルプやサポートを用意すること」自体を義務付けているわけではありません。
機能がない場合には、当然ながら適用対象外となります。

②　ユーザーが意図的に表示設定を変更した場合
ユーザーが自身のカスタマイズや表示設定で配置を変えたときや、ユーザーがページ内のUIコンポーネントの相対的な順序を変更することが合理的に予想されるアクションを開始したときは、この基準の対象外となります。
たとえば、単なるログインまたはログアウトでは「変更が利用者によって行われた場合」には当たらないとされていますが、ユーザーがマイページにログインしたような場合には、ページ内のUIコンポーネントの相対的な順序を変更することが合理的に予想されるアクションを開始したときにあたるため、この基準の対象外となります。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.2解説書 達成基準3.2.6 一貫したヘルプ

「3.3 入力支援」は、ユーザーがフォームなどに入力するときのミスや混乱を防ぎ、正しくスムーズに操作できるようサポートするためのガイドラインです。

入力フォームなどでユーザーが誤った情報を入力した場合、次の2点に配慮する必要があります。
これにより、どの部分をどう修正すればよいかをユーザーが正確かつ速やかに把握でき、特に視覚障害や色覚特性に配慮が必要なユーザーもスムーズに操作を続けることができるようになります。

①　エラー箇所の特定
どの欄でエラーが起きているかを明確に示すことが求められます。
たとえば、エラーとなっている入力欄の見た目を変える（枠線や背景色を変えるなど）だけでなく、スクリーンリーダーなどが読み取れるよう、プログラム上でエラーの欄であることを示す仕組みが必要です。

②　エラー内容をテキストで説明
エラーの原因や修正方法をテキストでわかりやすく伝えることが求められます。
単に赤い文字を表示するだけではなく、「◯◯の入力形式が正しくありません」「◯◯は必須項目です」といった、スクリーンリーダーでも読み上げ可能なメッセージを提供する必要があります。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準3.3.1 エラーの特定を理解する

入力フォームやインタラクティブな要素には、ユーザーが「どのような情報を入力すればよいか」や「どのような操作をすればよいか」を正しく理解できるようにするためのラベルや説明（テキスト）を付ける必要があります。
たとえば、フォーム入力欄に「お名前」「メールアドレス」といったラベルを明示するとともに、「記入のしかた」や「必須かどうか」などの説明も必要に応じて提供し、視覚的にもスクリーンリーダーなどでも分かりやすく伝わるようにすることが求められます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準3.3.2 ラベル又は説明を理解する

入力フォームなどでユーザーが誤った値を入力し、エラーが検出された場合、そのエラー原因と修正方法を具体的に提案する必要があります。
たとえば、メールアドレス欄に「@」が含まれていない場合は「メールアドレスには@を含めてください」と示すなど、ユーザーがどのように入力を修正すればよいのかをわかりやすいテキストで案内することが求められます。
これにより、ユーザーの入力ミスの再発や修正の手間を減らし、より円滑にフォームを完了できるようになります。

ただし、次の場合にはこの基準の対象外とされています。

①　ユーザーの入力ミスに対する詳しすぎるアドバイスを提示すると、外部からの不正アクセスや情報漏洩につながる可能性がある場合
たとえば、「管理画面へのログインフォーム」や「CAPTCHA」、「パスワード再設定フォーム」など、詳細なエラー情報を表示すると、攻撃や推測を行う手がかりになり、セキュリティ上リスクが高まるような情報を与えるべきではない入力フォームがあります。
このようなセキュリティ面が優先される場合は、この基準の対象外とされます。

②　作品やテストなど、内容や意図を学習者自身が考えて導き出すことが本来の目的となっている場合
たとえば、テストの問題文に対するヒントとなるアドバイスを教えてしまうと、テストとしての意義が失われる場合があります。
このような場合には、この基準の対象外とされます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準3.3.3 エラー修正の提案を理解する

ユーザーに法律行為又は金融取引が生じるページや、ユーザーが試験の回答を送信するページなど、エラーによって大きな影響が生じる可能性がある場合では、ユーザーが意図しないミスを防いだり、ミスを修正できる仕組みを提供する必要があります。
具体的には、以下のような手段のうち1つ以上を用いることで、誤った操作を確定してしまうリスクを下げることが求められています。

①　取り消し可能（Reversible）
送信後や操作完了後でも、一定の手順で取り消したり元に戻せるようにします。

②　チェック（Checked）
入力内容にエラーや抜け漏れがあれば検出し、修正を促します。

③　確認（Confirmed）
送信や操作の最終段階で「本当にこの内容で進めてよいか」という確認画面を提示します。

たとえば、オンライン購入手続きや契約締結フォームなどで送信する前に内容の最終確認画面を表示したり、送信後に取り消しの猶予を設けるなどが挙げられます。
こうした配慮により、大きな金銭的損失や個人情報の誤送信など、取り返しのつかないミスを防止することができます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準3.3.4 誤り防止(法的、金融、データ)を理解する

ユーザーが同じフォームや一連の手続きの中で、すでに入力した情報を再度入力しなくても済むように、自動的に表示したり、ユーザーが選択できる形で提示したりする必要があります。
たとえば、ECサイトで、配送先住所を入力したあと、同じ手続きの別ステップで再度「お届け先住所」を手入力させるのではなく、前のステップで入力した内容を自動的に反映するか、以前に入力した請求先住所と同じにするというチェックボックスにチェックを入れることで、ユーザーが選択できるようにするなどです。

ただし、次の場合にはこの基準の対象外とされています。

①　セキュリティ上の理由がある場合
たとえば、パスワードやクレジットカード番号など、「あえて再入力させる」ことが本人確認や不正利用防止に役立つ場合は、再度入力を求めても許容されます。

②　フォーム本来の目的を損なう場合
たとえば、ユーザーが前のステップで入力した内容に誤りがないかを確認するために、再入力（再確認）を必須とする仕組みが不可欠なケースでは、あえて再入力を求めても許容されます。

③　情報更新の必要がある場合
前回と同じ情報が使えない（引っ越しで住所が変わる可能性があるなど）場面では、ユーザーに更新を促すために再入力を要求することは許容されます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.2解説書 達成基準3.3.7 冗長な入力項目

認証（ログイン）を行う際に、過度な暗記や複雑な手順・推論などを要求せず、ユーザーがアクセスできるようにする必要があります。
特に、記憶力や注意力の面で負担が大きい認証方法だけしか用意されていないと、障害のあるユーザーを含め、多くの人がログイン自体を困難に感じる可能性があることから要求されているルールです。

ただし、次の場合にはこの基準の対象外とされています。

①　代替手段
複雑な認証手続きであっても、ユーザーが、暗記や複雑な推論を必要としない別の認証方法（ブラウザやOSの自動入力、ワンタイムリンク認証、生体認証など）を選択できるようになっている場合には許容されます。

②　メカニズム
複雑な認証手続きであっても、認知機能テストを完遂できるように支援するメカニズム（コピー＆ペーストなど）を利用できる場合には許容されます。

③　物体の認識
認知機能テストが、画像などの物体を視覚的に認識させる形式であり、複雑な文字入力や暗記より容易である場合（たとえば、「バスの写真を選んでください」といったレベルの判別で済む場合）には許容されます。

④　個人特有のコンテンツ
テストに使われる非テキストコンテンツが、ユーザー本人が事前にアップロードした写真や画像などで、「自分の投稿したものを選べばよい」という形になっている場合には許容されます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.2解説書 達成基準3.3.8 アクセシブルな認証 (最低限)

「4.1 互換性」は、WebコンテンツやUI要素がさまざまなユーザエージェント（ブラウザや支援技術など）で正しく認識され、操作できるようにするためのガイドラインです。

ユーザーインターフェース要素（ボタン・テキストフィールドなど）を支援技術で正しく扱えるようにするため、以下の名前 (name)、役割 (role)、値 (value)はプログラム的に決定される必要があります。
この名前 (name)と役割 (role)の初期値(value)は、ユーザーが任意に変更するものではなく、マークアップやスクリプトで定義され、ブラウザや支援技術が取得できるようにする必要があるということを意味しています。

①　名前 (name)
要素を示すアクセシブルネームです。スクリーンリーダーなどが読み上げる要素のラベルでもあります。

【例】ボタン要素に「検索」や「送信」といったテキストを設定し、支援技術が正しく読み取れるようにします。

②　役割 (role)
要素が持つ機能・種類を表します。

【例】ボタンかリンクか、あるいはチェックボックスかなど、要素の働きを明示します。

③　値 (value)
要素の現在の状態や入力値です。

【例】テキスト入力欄の文字、スライダーの位置、チェックボックスのオン／オフ状態などです。

また、状態（state）やプロパティ（property）、並びに動的に変わる値（value）については、ユーザーの操作やスクリプトによる変化が起こりうるため、その変化をプログラムで適切にハンドリングしARIA属性などを更新して支援技術へ確実に伝える（変更通知を送る）ことが必要とされます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準4.1.2 名前 (name)・役割 (role)・値 (value) を理解する

ユーザーの操作とは直接関係なく画面に表示される「ステータスメッセージ」（例：フォーム送信後の「送信が完了しました」などの通知）が、スクリーンリーダーなどの支援技術でも自動的に読み上げられ、利用者が気づけるように設計される必要があります。

具体的には、たとえば ARIA の role="status" や aria-live 属性を用いてメッセージの変化を支援技術へ通知し、ユーザーがフォーカス移動や画面読み直しをしなくても新しい情報に気づけるようにすることが求められます。

詳細については、下記参考サイトをご確認ください。

参考：WCAG 2.1解説書 達成基準4.1.3 ステータスメッセージを理解する

自動ツールを用いてマークアップの構造やARIAの設定ミス、コントラスト不足などを機械的にスキャンする方法です。
プログラム的に判定可能なエラーを効率的に洗い出せるため、大量のページを一括で検証できる点が利点です。

ただし、自動チェックだけでは検知できない問題（文脈のわかりやすさや操作フロー上の課題など）もあるため、あくまでも最初の一手として用います。

当社では、Siteimprove Accessibility Checkerをよく利用していますが、他のツールでも構わないと思います。

WCAGでは「キーボード操作が可能であること」が基本要件とされています。
Tabキーや矢印キーによるフォーカス移動が意図した順序・挙動になっているか、キーボードだけで操作が行き詰まらないかを手動で確認します。

自動ツールではフォーカス遷移の正確な文脈や操作感までは評価しきれないことがあるため、実際に操作しながら検証することが不可欠です。

コントラスト比や見出し構造、デザイン上の配置がわかりにくくないかといった「視覚面」での課題は、自動ツールだけでは判断が難しい場合があります。
また、支援技術の表示・読み上げ結果と実際の画面表示が整合しているか、レイアウトが崩れていないかなども、人間の目でしか正確に検証できません。

そのため、実際の画面を確認して「見た目のわかりやすさ」や「要素が隠れていないか」などをチェックする必要があります。

前述のように、WCAG 2.2規格に準拠することは、コンプライアンス面でも重要と考えられる時代になってきました。

しかしながら、WCAG 2.2規格のAA基準をクリアしたWebサイトを制作しようとしても、あるいは既存サイトを同基準にクリアするように改善しようとしても、なかなか対応できる制作会社が少ないなどの問題に直面することもあるかと思います。