入力支援のガイドライン

3.3.1 エラーの特定 (レベル A)

入力フォームのエラー箇所と内容を、色だけでなく「テキスト」で明確に伝える

作成日: 2024.4.10 / 最終修正日: 2026.5.12

この達成基準は、利用者がお問い合わせ、会員登録、決済フォームなどに入力ミスをした際、「どこが間違っているか」と「何がエラーの原因か」をテキストで明確に伝えることを目的としています。画面を見ずに操作する利用者や、エラー内容の理解に時間がかかる利用者が、エラーに気づかずに操作に行き詰まってしまうのを防ぎます。

実践すべきこと

エラー内容のテキストによる提示

• 入力が必要な項目の未入力や、形式の間違い（メールアドレスに「@」がない等）が自動的に検出された場合、エラーとなった項目を特定し、その内容をテキスト形式で利用者に提供する。

運用者への注意

利用者目線でのメッセージ確認

• 「システムエラー001」や「入力値が不正です」といったシステム側の都合による不親切なメッセージではなく、「メールアドレスが入力されていません」「電話番号はハイフンなしの半角数字で入力してください」など、利用者が原因を理解しやすい言葉になっているかを定期的にチェックする。

開発者への注意

エラーメッセージの配置とマークアップ

• エラーメッセージは、入力フィールドのすぐ近くに配置し、視覚的に見落としにくいようにする。
• スクリーンリーダーにエラーを確実に関連付けるため、aria-describedby 属性を用いて入力欄（<input>）とエラーメッセージのテキストをプログラム的に紐付ける。

色やアイコンだけに依存しない

• 入力欄の枠線を「赤色」にするだけ、または「！」アイコンを横に置くだけでは、テキストによる特定ができていないため不十分である。具体的なテキストメッセージも併記する。

今のWeb環境で気をつけたい点

• リアルタイムバリデーションと読み上げ： 入力のたびにエラーメッセージを出し続けると、スクリーンリーダーの読み上げが何度も割り込まれ、本文の入力に集中しにくくなることがあります。即時に出す場合は、判定を blur など入力が一段落したタイミングに寄せる、aria-live の領域や更新頻度を抑える、といった調整を検討するとよいです。
• 送信後のエラー一覧： 縦に長いフォームでは、送信後に画面上部へエラーの件数や概要をまとめて示し、各項目へジャンプできるリンクを付けると、どこを直せばよいかを把握しやすくなります（関連する達成基準 3.3.3「エラー修正の提案」や 3.3.4「エラー回避 (法的、金融及びデータ)」と併せて設計するとよいです）。

参考リンク

解説書 達成基準 3.3.1: エラーの特定

3.3.2 ラベル又は説明 (レベル A)

入力ミスを減らせるよう、入力フォームの項目名と入力方法の説明を明確にする

作成日: 2024.4.10 / 最終修正日: 2026.5.12

この達成基準は、利用者が入力欄、チェックボックスなどのフォームに入力する際に、何をどのように入力すればよいのかを明確に示し、入力ミスを未然に防ぐことを目的としています。適切な項目名や、必須マーク、パスワードの文字数制限などの説明を事前に提供することで、すべての利用者が迷わずに手続きを進められるようにします。

実践すべきこと

明確なラベルと説明の提供

• すべてのフォーム入力項目に対して、何を目的とした入力欄なのかが明確にわかるラベルを配置する。
• 特定のデータ形式（例：「半角英数字で入力」「YYYY/MM/DD形式」）が求められる場合は、入力例や説明文を事前に提示する。

入力が必要な項目の明示

• 入力が必要である項目には「入力が必要です」などのテキストを明記し、利用者が見落とさないようにする。

運用者への注意

入力ルールの見直し

• 新しいフォームを作成する際は、項目のラベルが前提知識がなくても誤解のない言葉になっているか確認する。また、「全角で入力してください」といった細かな入力ルールを減らし、システム側で自動的に半角/全角を変換するなど、利用者に負担をかけない設計を検討する。

開発者への注意

HTMLによるラベルと入力欄の紐付け

• <label for="..."> と入力欄の id 属性を使用して、視覚的なラベルとフォームコントロールをプログラム的に関連付ける。これにより、ラベルのテキストを選択（クリックやタップ）しても入力欄にフォーカスが当たるようになり、操作領域が広がる利点もある。

説明テキストの紐付け

• 入力欄の近くに書かれた「※半角英数字8文字以上」などの説明テキストは、aria-describedby 属性を用いて入力欄と紐付け、スクリーンリーダーが入力欄にフォーカスした際にその説明も自動的に読み上げられるようにする。

今のWeb環境で気をつけたい点

• placeholder をラベル代わりにしない： 入力中は消えるため、何の欄かを常に確認したい利用者には不向きです。本達成基準で求められるラベルや説明は、欄の外などに残るテキストとして置くのが無難です。placeholder は入力例の補足程度にとどめるとよいです。
• 「*」や記号だけの入力必須表示： アスタリスクや「※」だけでは、支援技術や表示設定によっては伝わりにくいことがあります。上の「入力が必要な項目の明示」のとおり「入力が必要です」などのテキストを添えるほか、HTML の required 属性や aria-required="true" でプログラム的にも示すと、取りこぼしを減らせます。

参考リンク

解説書 達成基準 3.3.2: ラベル又は説明

3.3.3 エラー修正の提案 (レベル AA)

入力エラーが起きた際、正しい入力形式などどう直せばよいかの修正案を提示する

作成日: 2024.4.10 / 最終修正日: 2026.5.12

この達成基準は、利用者がフォーム入力でエラーを出してしまった際に、エラーの事実を伝えるだけでなく、「どのように修正すればシステムに受け入れてもらえるか」という具体的な修正候補を提供することを目的としています。これにより、利用者が何度もエラーを繰り返して挫折してしまうのを防ぎ、スムーズに目的を達成できるように支援します。

実践すべきこと

具体的な修正候補・フォーマットの提示

• 入力データがシステムで決められた形式と合わずにエラーになった場合、「正しい入力形式」や「有効な値の例」をテキストで提供する。
• （例）日付入力でエラーになった際、「日付の形式が間違っています」だけでなく、「YYYY/MM/DDの形式で入力してください（例：2026/05/12）」と具体的な修正案を提示する。

運用者への注意

不親切なエラーメッセージの改善

• 単に「無効な入力です」「許可されていない文字が含まれています」と突き放すのではなく、「ハイフン（-）を抜いて数字のみで入力してください」といった、利用者が次のアクションを迷わず取れるような具体的な修正指示になっているかを定期的に確認する。

開発者への注意

例外事項の理解

• システムが修正候補を推測できない場合や、提示することでセキュリティ上のリスクが生じる場合（例：「そのパスワードは間違っています。正しいパスワードは〇〇です」などと提示すると危険な場合）は、修正案を提供しなくても例外として認められる。

サジェストUIのアクセシビリティ

• 検索窓で「りんご」と打ち間違えて「ろんご」と検索した際に「もしかして: りんご」と修正案を出す機能もこの基準に該当する。この修正案がキーボードやスクリーンリーダーでも適切に操作できるかを確認する。

今のWeb環境で気をつけたい点

• 3.3.1（エラーの特定）との違い： 3.3.1 が「どこがどう間違っているか」をテキストで伝えることに重点があるのに対し、3.3.3 は可能な範囲でどう直せばよいか（例や候補）を示すことが中心です。メッセージには、原因の説明に加え、入力形式の例や置き換え案など、次の操作が想像しやすい情報を含めるとよいです。
• 入力の正規化（寛容な受け入れ）： 全角・半角の違いやハイフンの有無など、システム側で整形して受け入れられる内容であれば、エラーにせず自動で揃える方法も検討できます。エラー表示そのものを減らす設計は、本達成基準とあわせて運用しやすくなることが多いです。

参考リンク

解説書 達成基準 3.3.3: エラー修正の提案

3.3.4 エラー回避 (法的、金融及びデータ) (レベル AA)

決済や契約など「やり直しができない重要な操作」の前に、内容を確認・修正できる機会を作る

作成日: 2024.4.10 / 最終修正日: 2026.5.12

この達成基準は、法的な契約、金銭のやり取り、データの削除など、一度実行すると取り消しが困難な「重大な結果を招く操作」において、利用者がうっかりミスをしないように守ることを目的としています。最終的な決定を下す前に、自分の入力した内容をもう一度見直し、間違いがあれば修正できる仕組みを設けることで、深刻なトラブルを未然に防ぎます。

実践すべきこと

「確認・取り消し・チェック」のいずれかの提供

• 以下のいずれか少なくとも1つを実装する。
  • 取り消し: 送信後、一定期間内であれば操作を取り消しできる。
  • チェック: 入力されたデータが正しいか自動的にチェックし、エラーがあれば修正の機会を与える。
  • 確認: 最終送信の前に、入力内容を一覧で表示し、利用者が内容を確認・修正できる「確認画面」を提供する。

運用者への注意

対象となる操作の特定

• 自社サイト内のどの操作が「法的、金融、データ削除」に該当するかを正しく把握する。
  • （例）商品の購入（決済）、銀行振込、会員退会、重要な書類の送信、プロフィールの削除など。

開発者への注意

確認画面と修正機能の実装

• 確認画面では、利用者が入力した情報を読みやすい形で要約して表示する。
• 確認画面から、前の入力画面に「内容を保持したまま」戻れる修正ボタンを設置する。

明確なボタンラベルの使用

• 「送信」や「OK」といった曖昧な言葉ではなく、<input type="submit" value="注文を確定する"> や <button> のテキストに「契約を締結する」「データを削除する」など、アクションの結果を明確に示す言葉を使用する。

今のWeb環境で気をつけたい点

• 確認画面以外の満たし方： 1回の操作で確定する UI でも、送信後に一定時間はキャンセルできる「取り消し」を用意すれば、上の「実践すべきこと」のパターンの一つとして説明されることがあります。確認画面を挟むか、取り消しやツールによるチェックのどれを主に使うかはサービスに合わせて選べます。金融や契約など誤操作の影響が大きい場面では、内容を一覧できる確認ステップが理解されやすい手段の一つです。
• 削除など取り消しが難しい操作： 完全削除などは元に戻せないことが多いので、確定前の確認、実行後の短時間だけの「元に戻す」、ごみ箱への移動のように後から復旧できる経路など、誤操作時の余地を検討するとよいです。実装の形は一つに限りません。

参考リンク

解説書 達成基準 3.3.4: エラー回避 (法的、金融及びデータ)

3.3.5 ヘルプ (レベル AAA)

フォーム入力などで迷わないように、その項目専用の「ヘルプ（入力のヒントや詳しい説明）」を用意する

作成日: 2024.4.10 / 最終修正日: 2026.5.27

この達成基準は、複雑な手続きやフォーム入力が苦手な利用者、記憶を保持するのが難しい利用者、または言葉の意図を汲み取るのが苦手な利用者が、入力エラーを起こして挫折してしまうのを防ぐことを目的としています。「この項目には何を書けばいいのか」「なぜこの情報が必要なのか」「どこを見れば自分の番号がわかるのか」といった疑問に対して、その場で解決できる「状況に応じたヘルプ」を提供することを求めています。

実践すべきこと

状況に応じたヘルプの提供

• テキスト入力や選択操作が求められる場面において、入力内容が複雑であったり、専門的な知識が必要であったりする場合、その項目専用のヘルプを利用者がいつでも確認できるようにする。

運用者への注意

「つまずきやすいポイント」の先回り

• 「お客様番号」や「証券番号」の入力欄のそばに、「※番号は郵便物右上の10桁の数字です」といった具体的なヒントを配置する。
• 利用者が迷いそうな項目には、「年齢確認のためだけに利用します」など、なぜこの情報が必要なのかという安心材料となる説明文を用意する。

開発者への注意

アクセシブルなヘルプUIの実装

• ヘルプテキストが長くなる場合は、入力欄のすぐそばに「？（ヘルプ）」ボタンを置き、選択すると詳細が開くアコーディオンUIや、アクセシブルなダイアログを実装する。
• aria-describedby 属性を使用して、入力欄とヘルプテキストをプログラム的に紐付け、スクリーンリーダー利用者が入力欄にフォーカスした際に自動でヒントが読み上げられるように工夫する。

今のWeb環境で気をつけたい点

• レベルAAAの難易度と優先度： すべての入力項目に対して詳細な専用ヘルプを用意することは、画面の情報量が増えすぎて逆に煩雑になったり、コンテンツ制作の負担が大きくなったりするため、「レベルAAA」に設定されています。まずは 3.3.2（ラベル又は説明）で基本的な入力指示を満たすことから取り組むとよいですが、確定申告、補助金の申請、保険の契約など、専門用語が多く「一度エラーになると修正が難しいシステム」においては、この文脈依存のヘルプが利用者のセーフティネットとなります。
• なんでも「よくある質問（FAQ）」への誘導を防ぐ： 「わからないことがあればFAQページを見てください」と別のページへリンクを張るだけでは、利用者は現在入力中の作業を中断してページを移動しなければならず、元の画面に戻れなくなるリスクがあります。利用者が「今いる画面から離れずに」その場で疑問を解決できる設計にすることが、この基準の重要なポイントです。

参考リンク

解説書 達成基準 3.3.5: ヘルプ

3.3.6 誤り防止 (すべて) (レベル AAA)

すべてのデータ送信において、送信前の「確認」や送信後の「取り消し」ができるようにする

作成日: 2024.4.10 / 最終修正日: 2026.5.27

この達成基準は、手元の操作が不安定でミスタッチをしやすい利用者や、注意力が散漫になりやすく衝動的にボタンを押してしまう利用者が、意図しないデータを誤って送ってしまうのを防ぐことを目的としています。レベルAA（3.3.4）では「お金や契約に関わる重大な送信」だけが対象でしたが、このレベルAAAでは、ちょっとしたコメントの投稿やプロフィールの更新など、ウェブサイト上で行う「すべてのデータ送信」に対して、誤りを防ぐためのセーフティネットを求めています。

実践すべきこと

あらゆる送信に対するセーフティネットの提供

• 利用者が何らかの情報を送信するすべての場面で、以下のいずれかを提供する。
  • 取り消し： 送信を完了した後でも、そのアクションを取り消すことができる。
  • チェックと修正： 入力されたデータに誤りがないかシステムが自動でチェックし、エラーがあれば送信前に修正を促す。
  • 確認： 最終的な送信ボタンを押す前に、入力したすべての内容を一覧で確認し、修正できる画面を挟む。

運用者への注意

「戻しにくい操作」への備え

• SNSの投稿、社内システムでのステータス変更、アンケートの回答など、あらゆる利用者の操作に対して「間違えて押してしまった時にどう復帰できるか」を仕様決定の段階から組み込んでおく。

開発者への注意

取り消しのできるUIの実装

• すべての操作に「確認画面」を挟むと操作性が悪くなる場合、Gmailの「送信しました（[取り消す]）」のように、ボタンを押した直後の数秒間だけ送信を保留し、その間に「元に戻す」ことができるUIを実装するアプローチが有効です。

今のWeb環境で気をつけたい点

• レベルAAAの難易度と優先度： ウェブサイト上のいいねボタンや、一言コメントの送信などあらゆる小さなアクションにまで確認画面や取り消し機能を実装することは、スピーディで直感的な操作を損なう場合もあるため、この基準は「レベルAAA」に設定されています。まずは金銭や契約に関わる重大な操作を守る 3.3.4（誤り防止 (法的、金融、データ)）から取り組むとよいですが、複雑な社内システムや、一つのミスが業務上の大きなトラブルにつながるツールにおいては、このAAA基準の「確認・取り消し可能」な設計が利用者を支えます。
• 日本の「確認画面」文化と世界のトレンド： 日本のウェブサイトは昔から「入力画面 → 確認画面 → 完了画面」という3ステップを好む文化がありますが、「確認画面をなくして1回の操作で送信し、間違えたら取り消しで戻す」というアプローチもあります。利用者の操作回数を減らしつつエラーを防ぐという意味で、現代のWebの技術にマッチしたアクセシビリティ対応と言えます。

参考リンク

解説書 達成基準 3.3.6: 誤り防止 (すべて)

3.3.7 冗長な入力 (レベル A)

同じプロセスの中で、一度入力した情報を何度も再入力させない

作成日: 2024.4.10 / 最終修正日: 2026.5.12

この達成基準は、WCAG 2.2 から新たに追加されました。フォームへの入力などの一連のプロセスにおいて、利用者が前に一度入力した名前や住所などの情報を、別の画面や項目で再度入力する状況を避けることを目的としています。同じ情報を記憶して何度も入力し直す作業は、記憶しながら作業するのが難しい利用者や、手元の細かな操作に時間がかかる利用者にとって大きな負担となります。

実践すべきこと

自動入力または選択の提供

• 同じ手続きの中で利用者に以前と同じ情報の入力を求める場合、以下のいずれかを提供する。
  • 自動入力: 該当する入力欄にあらかじめ以前の入力内容を入れておく。
  • 選択: チェックボックスやドロップダウンなどを使い、利用者が以前の情報を簡単に選んでコピーできるようにする（例：「配送先住所を請求先住所にコピーする」チェックボックス）。

例外事項の理解

• セキュリティ上の理由から再入力が必要な場合（例：パスワードの確認入力）や、前に入力した情報がもはや有効ではない場合は、例外として再入力を求めてもよい。

運用者への注意

フォーム設計時の見直し

• 新しい会員登録や申し込みフォームを作成する際、「この情報は前のステップでも入力させていないか？」を常に意識し、重複入力が発生する設計になっていないかをテストする。

開発者への注意

データの保持と画面遷移

• 複数ページにまたがるフォーム（例：ステップ1で個人情報、ステップ2で詳細入力…）を実装する場合、セッション等の仕組みを用いて入力データを保持し、後続のページで同じ情報が必要になった際は自動入力する処理を組み込む。

戻るボタン時の状態復元

• 確認画面から「入力画面に戻る」ボタンを押した際、それまで入力したデータが消去されてしまい、最初から手入力をやり直さなければならない実装は、この基準が防ごうとしている「冗長な入力負担」のケースとなるため避ける。

今のWeb環境で気をつけたい点

• パスワードの再入力： セキュリティ上、確認用フィールドで二度入力させるのは、上の例外として扱われます。一方で、表示の切り替えで内容を確認できるようにし、確認欄をなくす設計もありますが、導入するかどうかはポリシーと合わせて決めます。
• 1.3.5（入力目的の特定）との違い： 1.3.5 は、氏名や住所などの欄に autocomplete などを付け、ブラウザやパスワードマネージャーが適切に補完できるようにすることを主眼とします。3.3.7 は、同一の手続きのなかで、すでに入力した内容を別画面や別項目で繰り返し求めないことに主眼があります。併用すると入力負担を別の角度から下げられます。

参考リンク

解説書 達成基準 3.3.7: 冗長な入力

3.3.8 アクセシブルな認証 (最低限) (レベル AA)

ログイン時に「パスワードの記憶」や「パズル」「文字の書き写し」に頼らない

作成日: 2024.4.10 / 最終修正日: 2026.5.12

この達成基準は、WCAG 2.2 から新たに追加されました。ログインの際に、パスワードを自分の記憶から引き出させたり、読みにくい文字を書き写させたり、計算などのパズルを解かせたりといった記憶や書き写しを求める認証テストに頼らないことを目的としています。パスワードの暗記や複雑な認証コードの手入力に時間がかかる利用者を、入力支援や別の認証手段でサポートします。

実践すべきこと

認証における代替手段・支援メカニズムの提供

• 認証のプロセスにおいて、利用者に「暗記」や「転記」「スペリングの正確さ」など、記憶や書き写しを求める認証テストを要求する場合、以下のいずれかを利用できるようにする。
  • 支援メカニズム: パスワードマネージャーや、コピー＆ペーストによる入力を許可し、記憶やタイピングの負担をなくす。
  • 代替手段: 生体認証や、メールで送られるログインリンク、外部アカウント連携など、記憶や転記を伴わない別のログイン方法を用意する。

最低限（レベルAA）の例外事項

• 一般的な画像の中から「信号機」や「横断歩道」を選ぶような「画像CAPTCHA」や、利用者自身が過去にアップロードした画像を選ばせる「個人特有のコンテンツの認識」は、レベルAAにおいては例外として許容される。レベルAAAの達成基準 3.3.9「アクセシブルな認証 (高度)」では、これらも含めてより厳しい要件が示される。

運用者への注意

2要素認証（ワンタイムパスワード）の見直し

• SMS やメールで送られてくる「ワンタイムパスワード」を入力させる機能は「転記」という、記憶や書き写しを求める認証テストに該当します。このコードを利用者がクリップボードからそのままペースト（貼り付け）できる仕様になっているか、公開前にキーボード操作で確認するとよいです。

開発者への注意

パスワードマネージャーを妨げない（重要）

• セキュリティを高める目的で、JavaScript等を用いて入力欄のペースト機能を無効化したり、サードパーティ製パスワードマネージャーの自動入力をブロックしたりする実装は、この基準を満たしにくくなります。
• HTML の autocomplete 属性を正しく設定し（例：autocomplete="current-password"）、ブラウザや支援技術がパスワードを自動入力できるようにマークアップするとよいです。

今のWeb環境で気をつけたい点

• ペースト制限と支援： パスワード欄でコピー＆ペーストを禁じる実装は、パスワードマネージャーや支援的な入力のしやすさとぶつかりやすく、本達成基準が想定する「支援メカニズム」と両立しにくいことがあります。セキュリティ要件がある場合も、代替の認証手段や、ペーストを含めた入力のしやすさをどう確保するかを検討するとよいです。
• パスキーなどのパスワードレス： WebAuthn 等を使ったパスキーは、長いパスワードの暗記や転記に頼らずに済む例の一つです。導入可否は利用環境やバックエンドの整備次第ですが、記憶や理解の負担を下げる認証の選択肢として検討する価値があります。

参考リンク

解説書 達成基準 3.3.8: アクセシブルな認証 (最低限)

3.3.9 アクセシブルな認証 (高度) (レベル AAA)

ログイン時に「パスワードの暗記」や「画像パズル」など、頭や記憶を使うテストを求めない

作成日: 2024.4.10 / 最終修正日: 2026.5.27

この達成基準は、物事を記憶しておくのが難しい利用者や、画面上の文字を読んで書き写すのが苦手な利用者、パズルなどの複雑な指示を理解するのが難しい利用者が、ログインを完了できなくなるのを防ぐことを目的としています。レベルAA（3.3.8）では「画像の中から横断歩道を選ぶ（画像認識）」などは例外として許されていましたが、このレベルAAAではそれらも含めた記憶や判断に頼る認証テストを求めず、誰もがスムーズに認証を通過できる仕組みを求めています。

実践すべきこと

記憶や判断に頼る認証テストに依存しない認証の提供

• ログインなどの認証プロセスにおいて、利用者に「パスワードを自力で思い出して入力する」「パズルを解く」「歪んだ文字を読む」「特定の物体が写った画像を選ぶ」といったテストを求めない。
• 認証には、パスキー（顔認証や指紋認証などの生体認証）、リンクを選択するだけでログインできるメール（マジックリンク）、または外部のソーシャルログイン（GoogleやAppleでログイン）といった代替手段を用意する。

運用者への注意

「秘密の質問」や「CAPTCHA」の見直し

• 「母親の旧姓は？」「はじめて飼ったペットの名前は？」といった秘密の質問は、利用者に過去の記憶を引き出させる認証テストに該当するため、認証の手段として使用しない。
• スパム対策として広く使われている「信号機の画像を選ぶCAPTCHA」も、この基準（AAA）を満たしにくくなるため、利用者に見えない裏側でボットを判定するツール（reCAPTCHA v3など）への移行を検討する。

開発者への注意

パスキーやマジックリンクの実装

• 利用者の端末に備わっている生体認証を使ってログインできる「パスキー」の仕組みを導入する。
• または、メールアドレス宛に「このリンクからログイン」というリンク付きのメールを送り、パスワードの入力やワンタイムパスワードの「書き写し」を求めずに認証を完了させるフローを構築する。

今のWeb環境で気をつけたい点

• レベルAAAの難易度と優先度： 従来型のパスワードやCAPTCHAを廃止するには、認証システムの根本的な改修が必要となり、導入コストが高いため、この基準は「レベルAAA」に設定されています。まずはパスワードマネージャーの自動入力を邪魔しない 3.3.8（レベルAA）から取り組むとよいですが、記憶しながら入力するのが難しい利用者が多いサービスや、高いセキュリティと利便性を両立させたい金融機関のアプリなどにおいては、この「記憶や書き写しに頼らないログイン」が使いやすさを大きく高めます。
• 「パスキー」のこれから： この達成基準は高度に見えますが、現在Apple、Google、Microsoftなどが世界中で推進している「パスワードレス認証」の普及と同じ方向を向いています。つまり、AAA基準を満たすための技術的なハードルは年々下がっており、遠からずこれがWebの一般的な選択肢になっていくと考えられます。

参考リンク

解説書 達成基準 3.3.9: アクセシブルな認証 (高度)

目次へ戻る