1. 入力エラーと、送信後の不達を分ける

最初に、利用者がどこで止まったかを確認します。「問い合わせできない」という連絡だけでは、入力の問題か、送信処理の問題かを決められません。

起きたこと 最初に確認すること
欄が赤くなるが、直し方が分からない 欄の名前、表示された文、入力条件の説明
ボタンが押せず、理由も分からない 未入力の必須欄や同意欄の案内、操作できない理由の表示
送信操作の後に通信エラーが出る 入力ミスと決めず、制作担当へ受付の記録と処理結果の調査を依頼
完了画面は出たが、通知が届かない 受付・通知送信・受信の記録を分けて確認

最後の二つでは、受付済みの可能性があります。送り直しを繰り返す前に、通知メールが届かないときの確認手順に沿って記録を調べます。

不具合の連絡には、対象URL、発生日時、端末・ブラウザー、操作した欄、表示文を残します。画面を共有する場合は、名前・メールアドレス・問い合わせ本文を隠し、制作会社と合意した経路で渡してください。認証情報や顧客情報を公開の掲示板や外部AIへ貼り付けません。

2. 「条件・場所・直し方」の三つで確かめる

WCAG 2.2の入力支援の基準では、自動検出した入力エラーの箇所と内容を文字で示すこと（3.3.1）、入力にラベルや指示を用意すること（3.3.2）、修正案が分かる場合に示すこと（3.3.3）を扱っています。修正案には、安全性や目的を損なう場合の例外があります。

次の表は、この観点を担当者の確認に使うためのhirostaの提案です。これだけでサイト全体のWCAGへの適合を判定するものではありません。

観点 つまずきの例 制作担当と確かめること
入力前の条件 入力してから初めて「必須」と分かる 欄の名前の近くに要否を示し、条件と例を入力前から読めるか
誤りのある場所 ページ上部に「入力エラー」とだけ出る どの欄の何が問題かを、文字で特定できるか
直し方 「正しく入力してください」とだけ出る 空欄なのか、形式が違うのかを分け、次の操作を示せるか
説明の残り方 入力を始めると欄内の説明が消える 条件を欄外にも置き、入力中・エラー時にも見返せるか

デジタル庁の入力欄の使い方も、入力条件の事前説明と、具体的な訂正方法を示しています。アクセシビリティの説明では、入力すると消えるプレースホルダーを、条件や入力例の説明に使わないよう案内しています。

文字種の制限も見直す対象です。既存システムの制約があるなら理由と対応範囲を確かめ、画面だけ条件を緩めて受付側と食い違わせないようにします。AIに文案を作らせる場合も、実際には受け付けられない入力方法を案内していないか、人が仕様と比べて確認します。

3. 想定シナリオ：電話番号のエラーから戻れない

以下は架空の設備会社の例で、実際のフォームの診断・改修・効果測定は行っていません。

フォームの電話番号欄には「電話番号」とだけあり、ハイフン付きで入力するとページ上部に「入力内容を確認してください」と出る設定を想定します。受付側は数字だけを受け付けますが、画面にその説明がありません。

  1. Web担当者が条件を確かめる：電話番号を必須にする業務上の理由と、受付先システムの制約を制作担当に聞きます。エラーを消すためだけに必須を外しません。
  2. 制作担当が修正範囲を提示する：数字だけに限定する必要があるなら、入力前に条件を説明する案を出します。ハイフンを除く処理を設ける案なら、受付側との整合と、変換結果を利用者が確認できるかまで検討します。
  3. 画面の案を確認する：数字だけを受け付ける案では、欄の近くに「電話番号（必須）」「数字のみで入力してください」を置きます。ハイフン付きでエラーになる場合の文は「電話番号のハイフンを除いて入力してください」など、原因と操作が分かる形にします。これはこの設定に限った文案例です。
  4. 公開候補で修正できるかを確かめる：実在する連絡先を使わず、合意した確認用の環境で担当者が操作します。エラーの欄へ戻れ、説明どおりに直すと次へ進めるかを確認します。

AIの役割は説明文の下書きなどに限れます。受付条件の決定や、実画面で直せることの確認を、文案の作成で代えることはできません。

4. 制作会社へは、文言と受付条件を一緒に確認してもらう

「フォームを分かりやすくしてください」だけでは、文字の修正で済むのか、受付処理まで直すのかが曖昧です。次のように依頼範囲を分けます。

対象URLと、入力エラーが出た欄・操作・表示文を共有します。必須項目と入力形式について、画面の説明と受付側の条件が一致しているか確認してください。修正する文言、入力欄とエラーの関連付け、受付処理への影響を分けて提示してください。PC・スマホ・キーボードで、エラー箇所を見つけて直せることまで確認したいです。送信を伴う確認は、環境・通知先・実施日時を事前に調整してください。

自社の担当者は、何を必須にするか、問い合わせ対応で本当に必要な情報は何かを決めます。制作担当は実装と受付処理の整合を確認します。読み上げソフトでの案内が必要な場合は、入力欄と説明・エラーの関連付けを含め、確認できる担当と方法を相談します。

役割や成果物が契約で曖昧なら、HP制作の発注範囲を整理する手順も参考にしてください。

5. 修正後は、エラーを出すだけでなく直せるかを見る

自社サイトを点検した検証ラボでは、2026年10月21〜22日にフォームの枠線や入力中の表示、Tab移動時の位置を示す表示などを点検・修正しました。入力欄の枠線の薄さと入力中の表示の弱さは、色がCSS変数で指定されていたため機械では検出できず、画面を見て気付いたと記録しています。

この点検では、機械がHTML・CSSから候補を集め、ブラウザーで実際の見え方やTab移動を確かめ、人が変更を採用する分担にしました。静的な点検ではCSSの継承・変数・透過・計算後の表示を解決できないため、候補が出なくても、画面や操作に問題がないとは判断できません。

この観察を踏まえ、フォーム修正後は機械の結果に加えて、次の二つを確認することを提案します。制作担当と確認環境・対象を決めて進めます。

  • PCとスマホの実表示：枠線や入力中の表示が見えるか、条件・欄・エラー文の対応が分かるかを画面で確かめます。スマホではキーボードを出した状態で修正箇所が隠れないかも見ます。
  • Tab移動：マウスを使わずTabキーで欄へ移動し、現在の位置を示す表示が見えるか、修正する欄へ戻れるかを確かめます。

一方、次の三つは元ラボで検証した結果ではなく、入力エラーを直せるか判断するために別途必要な確認の提案です。

  • エラーからの復帰：必要な説明が残り、直した欄のエラーが解消するかを確認します。ほかの欄が消えて最初から入力し直すことにならないかも見ます。
  • 受付処理との一致：画面を通過した入力が受付側で拒否されないか、制作担当に確認してもらいます。送信を伴う場合は通知先と実施を調整し、受付記録と受信までを別に確認します。
  • 支援技術での案内：読み上げで欄の名前・説明・エラーが伝わるかは、画面の目視と分けて確認します。

公開中のフォームへ無断で確認用の送信をせず、送信が必要な項目は環境・通知先・実施日時を事前に調整してください。

6. 費用と期間は、文章・画面・受付処理を分けて考える

文言の修正、フォーム部品の改修、受付側の条件変更、PC・スマホや読み上げでの確認を分けて見積りを依頼します。同じ一文の変更でも、CMSの設定で直せるか、外部フォームや連携先まで変更が必要かで範囲が変わります。

期間も、実装の作業時間と、自社の条件決定・制作担当への確認待ちを分けます。まず困っている一つのフォームと欄を選び、現在の条件、直す範囲、確認担当をそろえましょう。この記事の例から固定の料金や納期は約束できません。

受付後の分類・担当振り分けも含めて整理する場合は、問い合わせ対応のガイドと業務の支援内容をご覧ください。支援範囲と料金はサービス案内、現在の困りごとの相談はお問い合わせで受け付けています。