はじめに
ラジオボタンは、複数の候補からひとつだけ選ばせたい入力欄に向いたフォーム部品です。作り方の要点は、同じ選択グループに同一のnameを付け、送信値をvalueで分け、説明文をlabelで結び付けることにあります。そのため、見た目を整える前に、選択肢の意味と送信データの対応を決めておくと扱いやすくなります。
その基礎が固まると、入力ミスの減少、キーボード操作への対応、フォーム送信後の処理まで一貫して設計できるのが現実的です。ラジオボタンの使い方は単純に見えますが、checkedの初期値、requiredの検証、disabledの扱い、CSSでの装飾方法を混同しやすい領域でもあります。初心者がつまずきやすいのは、見た目だけを先に変えて、フォームとしての意味が崩れてしまう点です。
- HTML Living Standard
- Google Chrome 126 / Firefox 127 / Safari 17.5
- CSS Selectors Level 4 / JavaScript ECMAScript 2024
- ラジオボタンの基本構造と選択グループの作り方
name、value、checked、requiredの使い分け- ラベル、アクセシビリティ、フォーム送信値の考え方
- CSSで見た目を整えるときの注意点
- JavaScriptで選択値を読む使い方
結論: ラジオボタンは同じnameでまとめる
結論は明確で、同じグループに属するラジオボタンには同じnameを付けます。ブラウザは同一のnameを持つinputの集合をひとまとまりとして扱い、その中からひとつだけ選択できる状態にします。一方で、各候補の送信値はvalueで分けるため、画面上の文言とサーバーへ送る値を別々に管理できるのが基本です。
結果: 期待される表示は、メールと電話のうち一方だけを選択でき、初期状態ではメールが選ばれているフォームです。
この作り方では、contactという名前の入力欄に対して、emailまたはphoneという値が送られます。画面に表示する日本語と送信値を切り離せるため、後続の処理では英数字の安定した値を使えます。ただし、同じグループ内でnameがずれると同時に複数選べる状態になり、ラジオボタンらしい使い方から外れてしまいるのが目安です。
公式仕様に近い確認先として、フォーム部品の属性はMDNのradio入力タイプが参考になると整理できます。フォーム全体の送信や属性の意味を広く確認する場合は、WHATWGのradio button stateも一次情報として参照できます。そのため、仕様の細部に迷ったら、解説記事だけでなく公式ドキュメントによればどう定義されているかを確認すると整理しやすくなるのがポイントです。
ラジオボタンの早見表
ラジオボタンの作り方は、属性、ラベル、検証、装飾、スクリプトの役割を分けて考えると理解しやすくなります。その中でも特に押さえたいのは、選択グループを決めるnameと、送信値を決めるvalueの関係です。これらを混同しなければ、フォームの見た目を変えてもデータ構造は崩れにくくなると理解できます。
| 項目 | 使う要素・属性 | 役割 | 注意点 |
|---|---|---|---|
| 基本入力 | input | 入力欄を作る | 単体では用途が決まらない |
| 種類指定 | type="radio" | ひとつだけ選ぶ入力にする | checkboxとは動きが異なる |
| グループ化 | name | 同じ候補群をまとめる | 同一グループでは値をそろえる |
| 送信値 | value | 選択後に送る値を決める | 未指定だと扱いにくい値になる |
| 初期選択 | checked | 読み込み時の選択状態を作る | 同じグループで複数付けない |
| 必須入力 | required | 未選択での送信を防ぐ | グループ内のどれかに付ければ判定される |
| 無効化 | disabled | 選択と送信対象から外す | 値は送信されない |
| 読み取り補助 | label | 説明文をクリック対象にする | 入力欄と文言を結び付ける |
| 明示的関連 | forとid | 離れた位置のラベルを関連付ける | idはページ内で重複させない |
| 囲み関連 | label内にinput | 短い構造で関連付ける | 複雑な配置では読みづらい場合がある |
| 送信先 | action | フォーム送信先を決める | サーバー側の受け口と合わせる |
| 送信方法 | method | getかpostを選ぶ | 検索条件ならgetが合いやすい |
| 送信ボタン | button | フォーム送信を起動する | type="submit"を明示する |
| 候補のまとまり | fieldset | 関連する入力を囲む | 選択肢の意味をまとめやすい |
| 見出し | legend | グループの説明を示す | 視覚だけでなく読み上げにも関係する |
| 説明文 | aria-describedby | 補足説明を関連付ける | 過剰に付けると情報量が増える |
| 状態取得 | querySelector | 選択済み要素を探す | :checkedと組み合わせる |
| 複数取得 | querySelectorAll | 候補全体を取得する | 戻り値はNodeListになる |
| 変更検知 | addEventListener | 選択変更時に処理する | changeイベントが使いやすい |
| 選択判定 | checked | 現在選ばれているか調べる | 属性とプロパティの違いを意識する |
| 値の取得 | .value | 送信値を読む | 画面表示の文字とは限らない |
| CSS選択 | :checked | 選択中だけ装飾を変える | 構造に合わせてセレクタを作る |
| 隣接装飾 | + | 直後の要素を装飾する | マークアップ順に依存する |
| 子孫装飾 | ~ | 後続要素を広く対象にする | 対象範囲が広がりすぎないようにする |
| 色変更 | accent-color | 標準UIの色を調整する | ブラウザ差を確認する |
| 余白 | margin | 要素外側の間隔を作る | クリック範囲とは別に考える |
| 内側余白 | padding | ラベル内の余白を作る | タップしやすさに関係する |
| 枠線 | border | 候補を視覚的に区切る | 選択状態との差を出す |
| 角丸 | border-radius | 候補の形を調整する | 過度に丸めると可読性が落ちる場合がある |
| 配置 | display | 縦並びや横並びを制御する | 狭い画面では折り返しを考える |
この表の中で、ラジオボタンの使い方に直接関わる属性はtype、name、value、checkedです。ただし、実際のフォームではfieldsetやlegendも組み合わせるため、入力部品だけを孤立させない設計が求められます。関連するフォーム全体の組み立ては、HTMLで問い合わせフォームを作成する方法5選!も合わせて読むと理解しやすくなります。
作り方1: 最小構成で選択肢を作る
ラジオボタンの最小構成は、inputにtype="radio"を付け、同じ候補群に共通のnameを与える形です。そのうえで、候補ごとに異なるvalueを持たせると、送信された値から利用者の選択を判別できると覚えるとよいでしょう。作り方としては短いものの、この段階でデータ設計がほぼ決まります。
結果: 期待される表示は、利用頻度の候補から毎日、週に数回、月に数回のいずれか一方だけを選べるフォームです。
この例では、候補の表示文字は日本語ですが、送信値はdaily、weekly、monthlyの英数字になっています。そのため、サーバー側では表示文言の変更に影響されず、値を条件分岐に使えます。一方で、valueを省くと送信値が意図しない形になりやすいため、候補ごとに明示しておくのが自然です。
その構造を広げる場合、アンケートや問い合わせフォームでは選択肢の数が増えますし、ここを基本と考えるとよいでしょう。候補が多い画面では、リンク先やページ内移動と組み合わせて案内を分けることもあります。ページ内の移動設計は『HTMLでアンカーリンクを活用する方法10選が参考になるのが一般的です。
💡 Tips:nameは利用者に見える文字ではなく、フォーム送信時の項目名として扱われます。候補の説明文を変更しても、処理側で使うnameとvalueを安定させると保守しやすくなると考えられます。
作り方2: 初期選択と必須入力を設定する
初期状態で選ばせたい候補がある場合は、対象のラジオボタンにcheckedを付けます。未選択で送信させたくない場合はrequiredを使い、ブラウザの標準検証に任せられます。ただし、初期選択を置くと利用者が選んだように見えるため、アンケートでは設問の性質に合わせて使い分けますし、ここがポイントです。
結果: 期待される表示は、希望時間帯の候補がまとまり、初期状態で夕方が選ばれた予約フォームです。
このとき、requiredは同じnameのグループに対して働きます。候補のどれかひとつが選ばれていれば検証を通るため、すべてのラジオボタンに付ける必要はありません。一方、checkedを同じグループ内の複数に付けると、後に書かれた候補が選択される挙動になりやすく、意図が読み取りにくくなります。
そのため、初期選択を使う作り方では、最初に選ばれている値が本当に中立かどうかを確認すると言えるでしょう。選択を促す設問なら初期選択を置かず、送信時にrequiredで未回答を止めるほうが自然な場合もあります。フォームの使い方として、利用者の意思を勝手に決めたように見せないことが大切です。
作り方3: labelでクリックしやすくする
ラジオボタンは小さな丸い入力欄だけをクリック対象にすると、スマートフォンやタブレットで選びにくくなります。その問題を避けるには、labelで入力欄と説明文を結び付けますし、ここがポイントです。ラベル全体がクリック対象になるため、ラジオボタンの使い方としても自然で、キーボードや支援技術との相性も良くなるのが現実的です。
結果: 期待される表示は、各プラン名の文字をクリックしても対応する候補を選べるフォームです。
この作り方では、idとforを同じ値にすることで、離れた位置にある入力欄とラベルを関連付けています。構造を短くしたい場合は、labelの中にinputを入れる書き方も使えます。ただし、カード型の見た目や複雑な説明を加える場合は、idとforで明示したほうが配置を調整しやすくなると整理できるのが基本です。
一般に、複数の入力欄が集まるフォームでは、fieldsetとlegendで設問のまとまりを示します。ラジオボタンの候補だけを並べるより、何を選ぶ欄なのかが読み取りやすくなります。一方、装飾目的だけで意味のない囲みを増やすと、読み上げ時の情報量が増えすぎる場合があると理解できるのが目安です。
label、fieldset、legendで機械的にも関係を表すことが求められます。作り方4: CSSで見た目を整える
標準のラジオボタンはブラウザごとの見た目に差があります。軽く色を合わせたい場合はaccent-colorを使い、選択肢全体をカード風にしたい場合は:checkedや隣接セレクタを組み合わせますが、これは押さえたい点です。ただし、入力欄を完全に隠す作り方では、フォーカス表示やキーボード操作を失わないように調整が必要です。
結果: 期待される表示は、選択中の配送方法だけ背景色と枠線の色が変わるカード型の候補一覧です。
この例では、:has()を使って、内部のinput[type="radio"]が選択されたlabel全体にスタイルを当てています。accent-colorは標準UIの色を変えるだけなので、クリックやフォーカスの基本動作を保ちやすい書き方です。一方、古いブラウザまで広く考える場合は、:has()を使わず、inputとspanを隣接させて+ で装飾する方法もあります。
その装飾を広げると、フォーム内に画像、スライダー、カレンダーなどを組み合わせる場面も出てきますし、これが一つの目安です。表示部品を増やす場合は、フォームの選択状態と他のUIが矛盾しないように構造をそろえます。関連するUIの作成例は、HTMLとCSSで手軽に作るスライドショーコピペ12選やHTMLとJSを使ってカレンダーを作成・更新する方法10選も参考になります。
display: noneでラジオボタン本体を消すと、キーボード操作やフォーカス確認が難しくなる場合があるのがポイントです。見た目を変える場合でも、操作できる入力欄としての性質を残す設計が必要です。作り方5: JavaScriptで選択値を取得する
フォーム送信前に選択値を画面へ反映したい場合は、JavaScriptで選択中のラジオボタンを取得します。典型的な使い方は、document.querySelector()でinput[name="plan"]:checkedを探し、見つかった要素のvalueを読む形です。ただし、未選択の可能性があるフォームでは、要素がnullになる場合も考慮します。
結果: 期待される表示は、プランを選ぶたびに段落の文字が「選択値: basic」のように切り替わる画面です。
この使い方では、changeイベントが発生したタイミングで現在の選択値を読み直します。textContentを使えば、取得した文字列を安全にテキストとして差し込めます。一方、innerHTMLに外部入力をそのまま入れる作り方は、不要なリスクを増やしやすいため避けるのが一般的です。
その処理を複数の候補群に広げる場合は、nameごとに取得対象を変えますが、覚えておくと役立つでしょう。たとえば、input[name="delivery"]:checkedなら配送方法、input[name="payment"]:checkedなら支払い方法を取得できます。関連する入力グループが増えるほど、ツリー構造を意識して要素を探す力が役立ちますが、これは押さえたい点です。
こうしたDOMの親子関係を整理したい場合は、HTMLとツリー構造をマスターする!初心者からプロまでわかる7つの完全ガイドも補助になります。ラジオボタンの値を読む処理は短く見えますが、フォーム全体の構造が乱れているとセレクタが長くなりがちです。そのため、スクリプトを書く前に、入力欄のまとまりをマークアップ側で整えると後の変更に対応しやすくなるのが一般的です。
ラジオボタンとチェックボックスの違い
ラジオボタンとチェックボックスは、どちらも候補を選ぶ入力部品ですが、選べる数が異なります。ラジオボタンは同じnameの中からひとつだけ選ぶ用途に向き、チェックボックスは複数選択を許す用途に向きます。この違いを取り違えると、利用者の意図と送信データがずれやすくなると覚えるとよいでしょう。
| 比較項目 | ラジオボタン | チェックボックス | 判断の目安 |
|---|---|---|---|
| 選択数 | 原則ひとつ | 複数選択も可能 | 単一回答ならラジオボタン |
| 属性 | type="radio" | type="checkbox" | 入力の意味で選ぶ |
| 解除 | 同一グループ内では別候補へ移る | 同じ項目を再クリックして外せる | 未選択へ戻したいかで変わる |
| 用途 | 支払い方法、配送方法、性別回答など | 興味分野、同意項目、オプション選択など | 排他的な選択かで判断する |
この比較で迷いやすいのは、候補が複数ある場面をすべてラジオボタンにしてしまうことです。複数の関心分野を選ばせるフォームなら、ひとつに制限されるラジオボタンでは回答を表しきれません。一方、支払い方法のように同時に複数選べない項目では、チェックボックスよりラジオボタンのほうが意味に合います。
フォーム設計で失敗しやすい点
初心者がつまずきやすいのは、候補を見た目だけで並べて、フォーム送信時の値を確認しない点です。特にnameの不一致、valueの未設定、labelの不足は、画面上では分かりにくいまま不具合につながります。そのため、ラジオボタンの作り方では、見た目、操作、送信値を同時に確認する必要があるのが現実的です。
ただし、確認といっても個別環境での結果を断定する必要はありません。ブラウザの開発者ツールでフォーム要素を確認し、選択時にcheckedプロパティが変わるか、送信されるname=valueの組み合わせが意図どおりかを見ます。公式ドキュメントによれば、ラジオボタンは同じグループ内でひとつの値を表す入力状態として扱われます。
disabledを付けた候補は、選択できないだけでなくフォーム送信の対象からも外れますし、ここを基本と考えるとよいでしょう。選択済みの値を変更不可に見せたいだけなら、説明文やサーバー側の制御も含めて設計する必要があります。一方、候補を動的に増減する画面では、JavaScriptで生成した入力欄にも同じルールが当てはまります。生成時にnameがばらつくと単一選択にならず、idが重複するとlabelの関連付けが壊れますし、ここがポイントです。動的な作り方ほど、テンプレート側で属性値の規則を決めておくと混乱を避けやすくなると考えられます。
用途別の使い方
ラジオボタンの使い方は、単一回答のアンケート、配送方法、支払い方法、表示形式の切り替えなどに向いています。どの用途でも共通するのは、同時に選べる答えがひとつだけかどうかを先に判断することです。逆に、複数の選択を自然に許したい場面では、チェックボックスや複数選択リストを検討すると整理できます。
具体的には、料金プランの選択ではplan、配送方法ではdelivery、支払い方法ではpaymentのように、項目の意味が分かるnameを付けます。値にはbasic、express、credit_cardのような処理しやすい文字列を使うと、サーバー側でも条件分岐しやすくなります。ただし、画面に表示する文言をそのまま値にすると、表記変更のたびに処理も影響を受けやすくなると言えるでしょう。
これらの設計は、フォーム単体ではなくページ全体の導線とも関係すると理解できます。問い合わせフォームなら設問数を絞り、アンケートなら回答の選びやすさを優先し、設定画面なら現在値がすぐ分かる配置にします。ラジオボタンの作り方を覚えた後は、利用者が迷わず選択できる文言と並び順を調整する段階に進みますし、これが一つの目安です。
保守しやすい命名と配置
保守しやすいフォームでは、name、id、classの役割が分かれています。nameは送信データ、idはページ内の一意な識別、classは装飾やスクリプトの対象として使うと整理できると覚えるとよいでしょう。そのため、同じ文字列を何でも使い回すより、目的に応じて命名を分けるほうが変更に耐えますが、覚えておくと役立つでしょう。
たとえば、料金プランの候補ならname="plan"を共通にし、id="plan-basic"やid="plan-premium"で個別に識別します。CSSでは.plan-optionのようなclassを付けると、選択値と見た目の責務を分離できます。一方、idを装飾目的で大量に使うと、再利用が難しくなる場合があるのが基本です。
こうした命名規則は、JavaScriptで値を取得する場面にも効いてきますが、これは押さえたい点です。querySelectorのセレクタが読みやすければ、後から候補を追加しても修正箇所を探しやすくなります。ただし、DOM構造に依存しすぎたnth-child中心の指定は、並び替えに弱い書き方になりやすいです。
実務的なチェック観点
公開前の確認では、選択状態、送信値、ラベル操作、キーボード操作、エラー表示を順に見ます。ラジオボタンは見た目が小さいため、マウス操作だけでなく、Tabで移動し、矢印キーで選択が変わるかも確認対象になると考えられます。その確認により、フォームの使い方が視覚操作だけに偏っていないかを把握できるのが目安です。
このとき、未選択時の扱いも明確にします。requiredを使うなら、送信時にブラウザの検証メッセージが出る前提で設計し、独自メッセージを出すならsetCustomValidityなどの利用も検討できます。一方、サーバー側でも必ず値を検証し、クライアント側の制御だけに依存しない構成にするのがポイントです。
具体的には、選択候補の表示順が変わった場合でも、valueの意味が変わらないように保ちますし、これが一つの目安です。管理画面で候補を追加できる場合は、保存される値と表示名の対応を別々に管理すると、文言変更によるデータ破損を避けやすくなります。フォームの規模が大きくなるほど、作り方の小さな違いが保守性に影響するのが一般的です。
要点の整理
ラジオボタンは、同じnameで候補をまとめ、候補ごとのvalueで送信値を分ける入力部品です。作り方の中心は短いコードに見えますが、label、fieldset、legend、required、checkedをどう組み合わせるかで使いやすさが変わります。そのため、見た目の調整より先に、単一選択としての意味と送信データを固めますが、覚えておくと役立つでしょう。
そのうえで、CSSではaccent-colorや:checkedを使い、JavaScriptではquerySelectorとchangeイベントで選択値を扱います。ラジオボタンの使い方をフォーム全体の設計と結び付けると、問い合わせ、予約、アンケート、設定画面などに応用できます。公式情報と実装パターンを照らし合わせながら、選択肢の意味が崩れない構成にすることが大切です。
関連記事
- 『HTMLでアンカーリンクを活用する方法10選
- HTMLとJSを使ってカレンダーを作成・更新する方法10選
- HTMLとCSSで手軽に作るスライドショーコピペ12選
- HTMLとツリー構造をマスターする!初心者からプロまでわかる7つの完全ガイド
- HTMLで問い合わせフォームを作成する方法5選!
※本記事は実在のエンジニア複数名で構成される Japanシーモア編集部が、AI支援を活用して作成・校正・公開しています。


