最初は、利用者がよく訪れるサービスページから問い合わせフォームへ進む経路を選びます。入口のURLと、途中で開くメニュー、入力画面、確認画面、完了画面をメモしておくと、確認漏れを減らせます。確認画面がないフォームに、点検のためだけに画面を追加する必要はありません。

OSとブラウザの名称・バージョン、画面幅や拡大率も記録します。環境によってキーボード操作の設定や挙動が違うためです。リンクを選べない場合には、サイトの不具合と決める前に、ブラウザ側のキーボードナビゲーション設定も確認してください。

入力や送信は、管理者が許可したテスト用フォームとテストデータで行います。本番の受付先へ、確認のために無断で問い合わせを送ってはいけません。送信が認められていない場合は、送信前までを確認し、エラー表示や完了後の動作は未確認として残します。

準備段階では、点検の終点を具体的に決めます。「問い合わせフォームを確認する」という依頼だけでは、入力欄を見るだけなのか、通知メールの受信まで含むのかが分かりません。フォームの管理者と、送信可否、使用できるデータ、確認する画面、終わった後のデータ処理をそろえておきましょう。テスト環境でも、実際の受付通知や外部システムへの登録が動く場合を想定して、接続先を確認してから進めます。

たとえば、架空のサービス紹介サイトなら、「サービス詳細からメニューを開く、相談フォームへ進む、注意事項を読む、許可されたサンプルを入力する、確認画面へ進む、修正画面へ戻る」という経路を一枚にまとめられます。最終送信が許可されていなければ、その直前を終点とし、「送信後の完了画面と受付通知は対象外」と記載します。実際に送信していないのに、完了まで確認済みとは扱いません。

また、最初から全ページを均等に調べる必要はありません。まず代表的な経路を選び、問い合わせへの入口が異なるページや別種類のフォームは、追加の確認候補として残します。一つのフォームで問題を見つけたら、同じ入力部品を使う別のフォームにも広げる、という順番なら、対象範囲を見失わずに進められます。これは点検の進め方の提案であり、サイト全体の評価に必要な対象数を示すものではありません。

操作が予想どおりにならないときは、まず「どこにフォーカスがあるか」を確認します。ブラウザのアドレス欄にいる状態と、ページ内のリンクにいる状態を混同すると、同じキーでも違う結果になります。記録には単に「最初から」と書くのではなく、「対象ページを開き、ページ内の最初のリンクへ移動した状態」など、再現する人が開始位置を合わせられる説明を添えます。

設定の影響を調べる場合も、一度に複数の条件を変えないようにします。まず現在の設定と結果を残し、変更してよい範囲を担当者と確認してから、比較する条件を一つ選びます。別のブラウザで動いたとしても、最初の環境で操作が止まった事実は消しません。「環境Ａでは再現、環境Ｂでは未再現」と分けて記録すれば、制作会社が調べる手掛かりになります。

原因を特定できない段階では、「サイトの実装ミス」「利用者の設定ミス」と結論づけず、観察した結果を共有します。利用環境の設定確認は、利用者に特別な回避操作を押し付けるためではなく、同じ条件で問題を再現するための準備です。

通常のリンクや入力欄では、Tabキーで次へ、Shift＋Tabキーで前へ移動します。今キー操作の対象になっている場所を「フォーカス」と呼びます。枠線などの表示を追い、どのリンクや入力欄にいるかが分かるかを確かめます。見た目がまったく変わらず、現在位置を判断できない箇所は記録しましょう。可視フォーカスは、W3CのWCAG解説でも重要な確認対象です。[1]

次に、問い合わせへ進むための操作ができるかを見ます。リンクを開く操作は一般にEnterキー、ボタンはEnterキーやSpaceキーで行います。ただし、選択肢のまとまりなどは矢印キーを使う場合もあります。すべての部品をTabキーだけで操作するものだと思い込まず、その部品に合った操作方法を確認します。[2][3]

移動順は、説明や入力の流れを理解できる順番かを見てください。たとえば氏名の次に離れた場所の同意欄へ移り、その後でメールアドレスへ戻るなら、入力の流れを把握しにくくなります。画面の左上から右下へ必ず進むことが条件ではなく、意味と操作の流れが保たれることが大切です。[4]

フォーカスの確認では、「対象に移動できるか」「対象だと見て分かるか」「必要な操作を実行できるか」を分けて考えると、依頼内容が明確になります。たとえば、ボタンに枠線が出ても押して反応しなければ操作の問題です。一方、Enterキーを押すと次へ進むのに枠線などの手掛かりがなければ、現在位置の見え方に問題がある可能性があります。[1][2]

ここで、フォーカスが見えないままEnterキーを押して探すのは避けましょう。送信や削除など、意図しない処理が動くおそれがあります。テスト中も安全に確認できる範囲にとどめ、どの操作の直後に現在位置を見失ったかを記録します。制作会社には、直前に見えていた対象と次に確認できた対象を伝えると、調べる範囲を絞りやすくなります。

順番についても、Tabキーを押した回数だけでは説明が足りません。「メールアドレス欄の次に、画面上部の別サービスへのリンクへ移った」のように、移動元と移動先を名称で残します。途中に新しい案内が表示されるなど、開始時の状態が違えば移動経路も変わり得るため、表示されていた部品の状態を合わせて記録してください。

問い合わせリンクがメニューの中にある場合は、開く操作だけで終えず、中のリンクへ進めるか、閉じた後に次の操作へ移れるかを確認します。カーソルを重ねたときだけ開く仕組みでは、キーボードで同じ情報にたどり着ける方法が必要です。[2]

ボタンで内容を開閉する部品について、W3CのAPGではEnterキーとSpaceキーで表示を切り替えるパターンを示しています。一方、画面の手前に開いて背後の操作を一時的に止める「モーダルダイアログ」は、別のパターンとして扱います。見た目が似ていても、期待するキー操作は同一とは限りません。[5][6]

モーダルダイアログでは、開いたときにフォーカスが内側へ移り、Tabキーの移動も内側を巡る設計が基本です。これは、それだけで不具合という意味ではありません。APGのパターンではEscapeキーで閉じ、閉じた後は通常、開くきっかけになったボタンへフォーカスを戻します。処理の流れによっては別の適切な場所へ移す場合もあります。[6]

問題として記録したいのは、閉じるボタンへ到達できず、キーボードで抜け出す方法も分からない状態です。Tabキーが同じ場所を巡るかだけでなく、閉じる操作と、その後の移動まで試してください。特殊な退出操作が必要な場合は、その方法が利用者に案内されているかも確認します。[7]

架空の確認用モーダルを例にすると、内側に「内容を確認した」と「閉じる」の二つの操作があり、その間をTabキーで巡ること自体は、モーダルの想定された動作と考えられます。確認したいのは、その範囲の中で必要な操作を選べるか、閉じる方法が使えるか、閉じた後に作業を続けられるかです。背後のフォームへTabキーで直接移れないという理由だけで、キーボードトラップと報告しないようにします。[6][7]

反対に、閉じたように見えるのにフォーカスが見えず、どこから入力を再開すればよいか分からない場合は、閉じる操作と復帰後の問題を分けて記録します。「ウィンドウは閉じるが、次のTabキーで移る先を確認できない」と書けば、開閉処理全体を一つの不具合として扱うより、現象を伝えやすくなります。判断が難しければ、期待する利用の流れを添えて設計の確認を依頼しましょう。

入力欄に文字を入れられることを確かめたら、許可されたテスト環境でエラー時の動作を確認します。必須項目の未入力や入力形式の誤りなど、担当者と決めた条件を一つずつ試すと、どの操作で問題が起きたのかを追いやすくなります。

見るのは、エラーが表示されたかだけではありません。どの項目をどう直すかが分かり、キーボードで該当欄へ戻って修正し、次の段階へ進めるかまで確認します。エラーでない項目の内容が残るかも、再入力の負担を見つける手掛かりになります。[8]

確認画面がある場合は、画面内の「修正する」「戻る」といった操作も試します。入力欄へ戻った後に現在位置が分からなくならないか、修正した内容が確認画面に反映されるかを見てください。完了まで試せる環境なら、送信後の表示を確認し、追加送信が不要な状態になっているかも記録します。

エラーの試験項目は、フォームの仕様と許可された操作範囲から選びます。まず必須の一項目だけを空欄にし、それ以外は指定された有効なテストデータを入力するなど、条件を限定しましょう。複数の入力不備を一度に入れると、どの条件が表示や移動に影響したのか分かりにくくなります。最初の確認を終えてから、複数項目にエラーがある場合へ広げると記録を整理しやすくなります。

たとえば、架空のフォームでメールアドレス欄だけを空欄にした場合、エラーが出る操作、その後の現在位置、該当欄まで戻る操作、値を直して先へ進む操作を順に残します。「赤い表示が出た」で終わらず、「メールアドレスの入力を求める文が表示され、対象欄へ戻って入力できた」のように、表示の内容と実行できたことを分けて書きます。

修正のために画面を戻った際は、入力済みの項目も見直します。氏名などが残っているか、選択した問い合わせ種別が変わっていないか、変更した箇所だけが確認画面へ反映されているかが確認候補です。消えた値があれば、すべての値が必ず保持されるべきだと即断するのではなく、仕様と利用者の負担の両面から担当者に相談します。

完了表示と通知メールの到着は別に確認します。本稿のキーボード点検では完了画面までの操作を記録し、メール不達の原因調査は別の確認項目として扱います。

「フォームが使いにくい」だけでは、制作会社が同じ状態を見つけるまでに時間がかかります。一つの問題につき、対象URL、確認環境、開始時の状態、押したキーの順番、期待する結果、実際の結果をまとめましょう。

たとえば、次のように書けます。これは説明用の架空例であり、実在サイトの診断結果ではありません。 対象は問い合わせ画面。ページを開き、Tabキーで「注意事項を見る」へ移動してEnterキーを押す。開いたウィンドウでTabキーとShift＋Tabキーを試すが、「閉じる」に移動できない。Escapeキーでも閉じられない。期待する結果は、キーボードでウィンドウを閉じ、入力を続けられること。

再現に必要なら、入力したテストデータと、同じ操作を繰り返した結果も添えます。画面写真や動画は補助になりますが、押したキーが映らないこともあるため、文章の手順を省かないでください。共有前には、個人情報や不要な認証情報が写っていないかを確認します。

テキスト報告は、制作会社が手元で再現できる程度に具体的であれば十分です。冒頭に「注意事項を閉じられず入力を続けられない」のような短い要約を置き、その下に環境、手順、期待結果、実際の結果を続けます。実際に試したキーだけを書き、試していない操作まで「どのキーでも動かない」と広げないことが大切です。 たとえば説明用の記録なら、「ページを開いた直後はメニューが閉じている」「Tabキーで注意事項のボタンへ移動する」「Enterキーで開く」「Tabキーで内側を一巡する」「閉じる操作を試す」と段階を分けられます。そのうえで、どの段階で期待と違ったのかを記します。前提の入力値や画面幅が必要なら併記し、個人名や実在の問い合わせ内容はテスト記録に混ぜません。

再現回数にも意味があります。同じ条件で三回試して三回起きた場合と、一度だけ起きて再現できない場合は分けて伝えます。「毎回」「ときどき」という印象だけでなく、実際に確認した範囲を示してください。再現できなかった場合も、発生時の操作や時刻が残っていれば調査材料になります。ただし、原因が通信や特定の実装にあるなどの推測は、観察結果とは別に扱います。

制作会社と対応順を相談するときは、問い合わせがそこで止まるのか、操作はできても現在位置を見失うのか、影響が一つの画面か共通メニュー全体かを伝えます。ここでの優先順位は運用上の判断であり、WCAGの適合レベルを置き換えるものではありません。

修正後は、最初に記録した環境と手順で再現しなくなったかを確認します。その箇所だけでなく、メニューを閉じた後や、エラーを直した後にも問い合わせを続けられるかを見ましょう。共通部品の修正なら、同じ部品を使う別の画面への影響も担当者と確認します。

W3CのEasy Checksは、簡易点検を通過しても重要な障壁が残り得ると説明しています。キーボードで一つの経路を確認できたことをもって、サイト全体のJIS・WCAGへの適合や準拠を宣言しないでください。[8]

点検対象と未確認の範囲を残し、対外的な表記を検討する場合は、別途必要な評価を相談します。

再確認では、修正対象の操作を成功させるだけでなく、その直前と直後をつなげて試します。モーダルを閉じられるようにしたなら、開く操作、内側の移動、閉じる操作、元の作業への復帰までを確認します。入力エラーを修正したなら、エラーを出す条件と、正しい値で進める条件を分けて確かめます。正常な流れに別の支障が出ていないかを見るためです。

画面幅によってメニューの表示方法が変わるサイトでは、最初の確認に使った幅だけでなく、別の表示状態も追加候補になります。どの範囲まで確認するかは、修正した部品の利用箇所と合わせて決めましょう。共通メニューの修正なのか、特定のフォームだけの修正なのかが分かれば、同じ操作をどこまで繰り返すべきか相談しやすくなります。

結果の管理では、「確認済み」「問題が残る」「条件がそろわず未確認」を区別します。担当者から修正済みとの連絡が来たことと、こちらで動作を確認できたことは別です。再確認した日と環境を追記し、まだ試せていない項目を閉じないようにしましょう。この記録を次の更新時にも使えば、同じ部品の変更後に何を見直すかが分かります。

キーボード操作の点検は、入口から入力、修正、完了までを一つの流れとして確認すると進めやすくなります。操作できない箇所だけでなく、現在位置が見えなくなる場面や、途中で戻れなくなる場面も記録しましょう。対象URLと再現手順がそろえば、制作会社と修正箇所を共有しやすくなり、修正後の確認にも同じ記録を使えます。

ホームページのウェブアクセシビリティ対応｜中小企業が押さえる位置づけと進め方
ホームページ公開後に確認すべきチェックリスト｜中小企業が見落としやすい運用ポイント

[1] WCAG 2.2 Understanding 2.4.7 Focus Visible
[2] WCAG 2.2 Understanding 2.1.1 Keyboard 
[3] APG Button Pattern 
[4] WCAG 2.2 Understanding 2.4.3 Focus Order 
[5] APG Disclosure Pattern 
[6] APG Dialog Modal Pattern 
[7] WCAG 2.2 Understanding 2.1.2 No Keyboard Trap 
[8] WAI Easy Checks 

原文確認日 2026年10月20日。本稿の報告様式、テスト環境の準備、対応順の整理は編集上の運用提案です。WCAG解説とAPGは理解・実装を助ける資料であり、本稿は規格全体の適合判定や実サイトの診断結果を示すものではありません。