「完成です」と見せた申込フォームを、キーボードだけでは送信できなかった

「もう使えます」と言った10分後、Tabキーで止まった

火曜の15時40分。地域の料理教室で、子ども向け講座の申込フォームを担当者へ見せていた。

開催日を選び、保護者名とメールアドレスを入れ、参加人数を選ぶ。送信すると受付メールが届く。AIに画面のたたき台を作らせ、こちらでAPIをつなぎ、テストも通した。マウスで二度申し込み、スマートフォンでも一度確認した。

「これで完成です。予定より早く出せました」

そう伝えると、料理教室の講師は「助かった」と笑った。ここまではよかった。問題は、そのあとだ。

講師は受付用パソコンのマウスを端へ寄せた。「私はいつもTabキーで項目を移るんです」と言い、名前、メールアドレス、希望日へ進んだ。ところが、参加人数のカードには移れない。何度Tabを押しても、そのまま送信ボタンへ飛ぶ。選択されていないので、Enterを押しても申し込みは終わらなかった。

画面の前で、こちらの手が止まった。

AIを使って早く作れたと、自分から話した直後だった。「確認が足りませんでした」と言えば、速さだけを優先したと思われそうだ。講師の操作が特殊だったことにすれば、少しは格好がつく気もした。いったん持ち帰り、誰にも言わず直して、明日の朝に差し替えれば済む。そんな考えが一瞬で頭を回った。

でも、講師はただ、自分が普段している操作を見せただけだ。困らせたのはTabキーではない。マウスで通った一つの道だけを見て、「完成」と決めたこちらの確認だった。

マウスで動く画面と、使い切れる画面は同じではない

見た目の整ったフォームは、完成に見えやすい。入力欄が並び、色も余白もそろい、ボタンを押せばAPIが動く。AIはこの「完成に見えるところ」までを、とても速く作ってくれる。

一方で、利用者が画面をどう進むかは、見た目だけでは分からない。マウスを使わない人も、キーボードと使い分ける人もいる。けがや機器の故障で、一時的に片方しか使えないこともある。

ここでアクセシビリティを「特別な人向けの追加対応」と考えると、納期の最後に回りやすい。そうではなく、申し込みという仕事を、別の操作方法でも最後まで終えられるかを見る品質確認として置いたほうが分かりやすい。

W3Cの「WCAG 2.2」は、ウェブコンテンツのアクセシビリティを確認する国際的な指針だ。すべての機能をキーボードで操作できることを達成基準2.1.1、キーボードで今どこを選んでいるか見えることを2.4.7に置いている。入力エラーは、間違った項目を特定し、文字で説明することが3.3.1にある。

これは、すべての案件に同じ法律上の義務が生じる、という説明ではない。契約やサービスの条件は別に確かめる必要がある。ただ、「何となく使いやすい」で終わらせず、具体的に確認する材料にはなる。

デジタル庁の「ウェブアクセシビリティ導入ガイドブック」も、行政機関だけでなく、情報システムやデジタルサービスの発注・受託に関わる人が確認できる資料として公開されている。アクセシビリティは、実装担当だけが最後に抱える細かい話ではなく、発注する側と作る側が、何を使える状態とするか話すための材料でもある。

壊れていた場所を、「一つの不具合」でまとめなかった

料理教室から戻る途中、私は「人数選択を直せば終わり」と考えていた。早く直して、確認不足を小さく見せたかった。気まずいと、問題まで小さく呼びたくなる。

その夜、マウスを机の端へ置き、最初からもう一度たどった。すると、止まっていたのは一か所ではなかった。

人数カードに、キーボードから入れなかった

人数選択は、見た目を整えるために普通のdivへクリック処理を付けた部品だった。マウスでは押せる。しかし、キーボードから選べる部品としてブラウザに伝わっていないため、Tabでは選択対象にならなかった。

W3Cのフォーム向け解説では、入力欄、チェックボックス、ラジオボタンなど、目的に合うフォーム部品とラベルを対応づける方法が示されている。今回の人数選択なら、まずラジオボタンなどの標準部品で作れないかを見る。独自部品が本当に必要なら、名前、役割、現在の選択状態、キーボード操作を自分たちで補う必要がある。

見た目がカードでも、HTMLまで独自部品にする必要はない。ここを取り違えると、マウスで押せる四角は作れても、どう操作できる部品なのかが伝わらない。

Tabで進めても、今いる場所が見えなかった

人数カードを直したあとも、操作は不安定に感じた。理由は、CSSでフォーカスの枠線を消していたからだ。Tabを押すたびに選択先は移っているのに、画面上ではどこにいるか分からない。

講師が何度もTabを押したのは、操作を知らなかったからではない。画面が返事をしていなかったからだ。現在位置が見えなければ、押しすぎたのか、止まっているのかも判断できない。

デザインのために標準の枠線を消すなら、代わりのフォーカス表示が必要になる。色だけでなく、線や背景の変化を使い、周囲と見分けられるかを実画面で確かめる。きれいに消すことより、操作中の人へ返事をすることが先だ。

エラーは出たが、どこを直すか分からなかった

未選択のまま送信すると、人数カードの枠だけが赤くなった。マウスで画面全体を見ていた開発者には分かる。しかし、文字の説明はなく、エラーが出た場所にも移動しない。どこを直せばよいか、操作中の人には届いていなかった。

そこで「参加人数を選んでください」と文字で示し、人数の選択肢と説明を対応づけた。送信に失敗したら、最初のエラーへ移れるようにし、入力済みの名前やメールアドレスは残した。

W3Cの簡易チェックも、フォームではキーボード操作、ラベル、必須項目の説明、エラーの見つけやすさを確認するよう案内している。赤くしたことは、伝えたことと同じではない。利用者が間違いに気づき、どこを直すか分かり、もう一度送れるところまでがエラー対応だ。

「AIが作ったから」を説明にせず、確認した事実を出す

三つの問題が見つかった時、いちばん重かったのは修正量ではない。担当者へ、どこまで使えなかったかを言うことだった。

AIが作った部分に問題があった、と説明すれば、自分の責任が少し薄くなる気がする。しかし、利用者から見れば、誰が最初のコードを書いたかは関係ない。知りたいのは、今どの操作ができず、いつ直り、何を再確認するかだ。

私は翌朝まで黙るのをやめ、その日のうちに三点を送った。

マウスでは申し込みを完了できますが、キーボード操作では参加人数を選べず、送信できない状態を確認しました。

人数選択の部品、現在位置の表示、入力エラーの案内を修正します。

修正後は、マウスを使わず入力開始から受付メール受信まで確認し、結果を明日10時までに共有します。

この文面には、AIという言葉を入れなかった。隠したのではなく、原因と対応に必要な情報へ絞った。今回伝える中心は、生成手段ではなく利用者への影響だ。

確認不足を共有すると、信用を失う気がして一人で直したくなる。でも、黙ったまま公開時刻を迎えると、相手は利用者への案内を決められない。言いづらい指摘を、事実・影響・お願いの三文で伝える方法と同じで、気まずさを消してから話す必要はない。事実を小さく分ければ、次の判断へ進める。

マージ前は、マウスを端へ置いて三つを見る

すべてのアクセシビリティを短い確認だけで保証することはできない。自動チェックで見つかる問題もあれば、支援技術を使った確認や当事者による評価が必要な場面もある。W3Cの簡易チェックも、これだけで包括的な評価にはならないと明記している。

それでも、マージ前に大きな見落としを減らす入口は作れる。申込フォームなら、まず次の三つを行う。

1. 最初から完了まで、TabとEnterだけで進む

マウスを触らず、最初の入力欄から完了画面まで進む。戻る操作が必要ならShift+Tabも使う。選択肢では矢印キーやSpaceを試し、送信後は受付メールや完了表示まで確認する。

「ボタンに到達できた」で終わらず、利用者の目的が終わるところまで見る。料理教室なら、受付番号が表示され、確認メールが届くところまでだ。

2. 今いる場所と、部品の意味を確かめる

Tabを一回押すたび、現在位置が見えるかを見る。さらに、人数選択がボタンなのか、ラジオボタンなのか、選択済みかどうかをブラウザや支援技術へ伝えられる作りになっているか確認する。

AIが独自部品を提案してきたら、まず標準のHTML部品で同じ見た目を作れないか戻る。独自部品を採用するなら、「なぜ標準では足りないのか」と、キーボード操作を含む確認結果をPRに残す。

3. わざと間違え、直して再送する

必須項目を空にする。メールアドレスの形式を崩す。選択肢を未選択にする。その状態で送信し、エラーが文字で分かるか、該当箇所を見つけられるか、入力済みの値が残るかを確認する。

正常に送れた一回だけでは、フォームの半分しか見ていない。失敗した人が戻れることまで見ると、初めて使い切れる画面に近づく。

AIが書いたテストを利用者の結果へつなぐ方法では、自動テストが何を証明した緑なのかを整理している。AIの完了報告を三つの証拠で確かめる方法と合わせ、差分、自動チェック、実際の操作を一組にすると、「完成」の根拠を説明しやすくなる。

翌日の確認で、講師の手は送信まで止まらなかった

翌朝9時50分。修正版を料理教室へ持ち込み、前日と同じパソコンで講師に最初から試してもらった。

名前、メール、希望日、参加人数。Tabを押すたびに青い枠が移り、人数は矢印キーで選べた。必須項目を一つ空にすると、「参加人数を選んでください」と表示され、その場所へ戻れた。修正してEnterを押すと、受付番号が出て、確認メールが届いた。

講師は「昨日は私のやり方が変なのかと思った」と話した。その言葉は少し痛かった。画面が動かない時、利用者は作った側より先に、自分の操作を疑うことがある。何度も押し、黙って諦め、問い合わせをしない人もいる。こちらが不具合に気づかなければ、その離脱は「申し込みがなかった」という数字にしか見えない。

だから、完了条件を一行増やした。

主要な申込経路を、マウスとキーボードの両方で完了でき、エラーから再送できること。

全部の画面を毎回同じ深さで確認できないなら、最初に対象を決める。申し込み、購入、ログイン、解約など、利用者が目的を果たす主要経路を優先する。必要な基準や評価範囲は、発注側とも合意しておく。

AIに初稿を任せても、何を使える状態と呼ぶかは自分たちで決める。利用者の操作で確かめ、抜けを言葉にして次の完了条件へ残す。そこまでできれば、速さだけでなく、任せたあとの不安も減らせる。

完成と言ったあとに不具合が見つかるのは、かなり気まずい。それでも、利用者の操作を特殊扱いせず、同じ道をたどり直せば、直す場所は見えてくる。次のフォームを開いたら、まずマウスを端へ置く。Tabを一回押すところからでいい。🔍

参考にした一次情報・公的資料

• W3C「Web Content Accessibility Guidelines (WCAG) 2.2」（2024年12月12日勧告）
• W3C WAI「Easy Checks - A First Review of Web Accessibility」（2026年9月9日確認）
• W3C WAI「Forms Tutorial: Labeling Controls」（2026年9月9日確認）
• デジタル庁「ウェブアクセシビリティ導入ガイドブック」（2025年10月16日更新）

※この記事は、ウェブアクセシビリティの確認を始めるための一般的な実務例であり、個別サービスの適合性や法的義務を判断するものではない。