disabledとreadonlyの違いを徹底解説！使い分けのコツを中学生にも分かる表で解説

---

disabledとreadonlyの基本をつかもう

まず最初に理解しておきたいのは disabled と readonly という属性の意味の違いです。どちらもフォームの入力部品を操作できなくする点は共通していますが、実際の挙動は大きく異なります。
この記事では中学生にも分かるように、具体的な場面の例とともに違いを整理していきます。

disabled を指定すると、その入力部は完全に使えなくなります。カーソルを合わせても反応せず、押したり入力したりすることはできません。さらに重要なのは、送信ボタンを押したときにその値がサーバーに送られない点です。つまりフォームとしてのデータには現れません。これを使う状況は、ユーザーがその入力を意図的に使えない状態にしたいときです。例えば、権限のないユーザーには特定の選択肢を表示していないことを示すときなどです。

readonly は違いが微妙に似ていますが、扱いは異なります。readonly が設定された入力欄は
見た目は通常のままですが、値の変更はできません。
しかし送信時にはその値がサーバーへ含まれる点がポイントです。つまり「現在の値を表示したまま、読み取り専用として扱う」用途に適しています。例えば、契約書の一部の自動計算結果を表示して、利用者が変更できないことを示したいときに使えます。

disabledとreadonlyの実務的な使い分けとよくある勘違い

まず、フォーカスの扱いが異なります。disabled の要素には通常、フォーカスが移動しません。キーボード操作で順番に移動していくときも選択肢として現れません。対して readonly の場合は、入力はできなくてもフォーカスはあたることがあります。これはスクリーンリーダーの読み上げ順にも影響することがあり、アクセシビリティ上の配慮が重要です。

次に 送信時の挙動 です。disabled の値はフォームの送信時に含まれません。これはデータの漏れを防ぐ意味で便利ですが、逆に必須情報が欠落する危険性もあります。readonly は値を送信します。したがって、計算結果や参照情報の表示と実データの送信を分けたい場合に適しています。

最後に 見た目の違いとCSSの影響 です。多くのブラウザでは disabled の要素は見た目が薄くなり、色がグレー化されます。readonly は通常の入力と同じ見た目のままですが、カーソルが点滅しなくなるなど、操作感が異なります。これらの違いを理解して適切に使い分けると、ユーザー体験が大きく向上します。

要素	disabled	readonly
フォーカス	不可	可（場合による）
送信時の値	送信なし	送信あり
編集可否	不可	不可
見た目	通常は灰色	通常の見た目

実務での使い分けのコツとよくある勘違い

実務では、背景にあるデータの扱いとユーザーへの意思表示を分けて考えることが重要です。
disabled は「この情報を使えません」という状態を強く伝える役割を持ちます。
readonly は「この値は表示されており、変更できませんが送信はされます」という意味合いで使います。

もう一つのポイントはアクセシビリティです。スクリーンリーダーを使う人にとって、 disabled の要素は読み上げ順や操作可能性の情報が混乱することがあります。したがって、不可ですと表示するだけでなく、aria-disabled などの補足情報を検討するのも良い実務です。

現場では、たとえば条件付きで入力を無効化したり、特定の値だけを編集不可にしたりします。そうすると、データの整合性を保ちつつ、利用者へ正しい情報を提示できます。
結局のところ、「何を伝えたいのか」「どのデータが送信に影響するのか」を明確にすることが大切です。

ピックアップ解説

今日は放課後に友達と雑談するような口調で、disabled について深掘りします。私たちは学校の掲示板のような例を使い、誰が何をできるか、どこまでデータが渡るのかを語り合いました。disabled は単なる見かけの変更ではなく、データの送信や処理の仕方に影響を与える“仕切り”だと気づいた瞬間、ウェブの作り方が少し楽になりました。つまり、使い分けの本質は「ユーザーに伝えたい状態」と「システム側で扱うデータ」を分けることです。

---