JavaScript

The JavaScript submit() method submits a form directly, bypassing submit events and constraint validation, so it is useful when you intentionally want low-level submission behavior.

submit()

submit() はフォームを直接送信するAPIで、submit イベントを発火せず、ブラウザの制約検証も通さずに送信処理へ進めます。

このページでできるようになること

まずは直感：submit() って何？

ざっくり言うと、submit() は「送信ボタンを押したことにする」のではなく、「フォーム送信処理を直接始める」ためのメソッドです。

最小デモ：まず動かす

下のデモでは、空の必須入力欄に対して submit() / requestSubmit() / 実際の送信ボタン を試せます。

空欄のまま form.submit() を押すと、submit イベントなし・検証なしで送信先の iframe に進みます。requestSubmit() や通常ボタンは、空欄ならブラウザ検証で止まります。

JavaScript

const form = document.querySelector('#demoForm');

form.submit();

最短の型はこれだけですが、実務では「本当にイベントと検証を飛ばしてよいか」を先に確認します。

正確な定義（仕様に沿った説明）

何のために存在するか

submit() は HTMLFormElement のメソッドで、フォームを直接送信するために使います。送信ボタンのクリックを再現するAPIではなく、送信処理そのものを始めるAPIです。

何に適用されるか（対象）

submit() は <form> 要素に対応する HTMLFormElement で使います。つまり document.querySelector('form') などで取得したフォーム要素に対して呼び出します。

できること / できないこと（制約）

できること
  • フォーム送信処理をただちに開始する
  • カスタム送信前処理を通さず、低レベルに送信だけ進める
  • JavaScript側で条件が揃ったときだけ明示的に送信する
できないこと（重要）
  • submit イベントを発火して preventDefault() で止めてもらうこと
  • ブラウザの制約検証（required / pattern など）を自動で走らせること
  • どの送信ボタンが押されたかをそのまま反映すること（送信ボタンの name/value を送信データに含める流れにならない）

影響範囲（レイアウト/描画/ユーザー操作/アクセシビリティ）

レイアウト
submit() 自体はレイアウトを変えません。送信後の画面遷移やDOM更新の結果として見た目が変わります。
描画
メソッドを呼んだ瞬間に何か表示が変わるわけではなく、送信処理・レスポンス・JavaScript側の後続処理で変わります。
ユーザー操作
ユーザーが送信ボタンを押した流れとは異なるため、送信前確認や計測処理を submit イベントに寄せていると、そこを素通りします。
アクセシビリティ
ブラウザ標準のエラーメッセージやフォーカス移動を使う設計では、submit() にするとそれらを飛ばしやすくなります。入力不備を伝える導線を壊していないか確認が必要です。

基本の書き方（最短の型）

最小サンプル（コピペ用）

HTML

<form id="loginForm" action="/login" method="post">
    <input type="email" name="email">
    <input type="password" name="password">
</form>

JavaScript

const loginForm = document.querySelector('#loginForm');

loginForm.submit();

よく使う判断

標準の検証と submit イベントを使いたい
form.requestSubmit() を優先します。
送信ボタンが押された扱いにしたい
実際の送信ボタンをクリックするか、requestSubmit(submitter) を使います。
あえて検証やイベントを飛ばしたい
form.submit() を使います。理由が明確なときだけに絞ると安全です。

どこに書くか（実務の位置づけ）

実務では、クリックハンドラや送信前分岐の最後で呼ぶことがあります。ただし「なんとなく submit」だと事故りやすいので、検証・計測・二重送信防止との関係を整理した上で置きます。

仕様として押さえるポイント（初心者が事故りやすい所）

戻り値は？
submit() の戻り値は undefined です。dispatchEvent() のように true/false を返してくれるAPIではありません。
submit イベントは起きる？
起きません。form.addEventListener('submit', ...) による処理、onsubmit、その中の preventDefault() も通りません。
制約検証は走る？
走りません。required / minlength / pattern などがあっても、その場で止めてくれません。
送信ボタンの値は送られる？
通常の送信ボタン経由ではないため、どのボタンが押されたかを表す送信ボタンの name/value は送信データに含まれません。
name="submit" で何が起きる？
フォーム内コントロールの name または id が submit だと、フォームの submit メソッド名と衝突して form.submit is not a function になることがあります。
非同期に見える？
メソッド呼び出し自体は同期的に始まりますが、結果としての遷移や通信完了は別です。試験では「イベントを待っているわけではない」点がひっかけになります。

よくある勘違い・混同ポイント

form.submit()

送信処理を直接始めます。submit イベントなし、制約検証なし。

form.requestSubmit()

送信ボタン相当の流れで送信をリクエストします。submit イベントあり、制約検証あり。

送信ボタンのクリック

ユーザー操作に近い自然な流れです。どの送信ボタンかも反映されます。

submit() ＝ 送信ボタンを押したのと同じ
同じではありません。見た目は似ていても、submit イベントと制約検証の有無が違います。
checkValidity() した後なら完全に同じ
近づきますが同じではありません。送信ボタン由来の name/value、submitter 情報、submit イベント経由の処理は別です。
preventDefault() で止められる
submit() が直接走る場合、そもそも submit イベントが発生しないので、その中で止める設計は効きません。
送信できれば UX は同じ
違います。ブラウザ標準の入力エラー表示、フォーカス移動、支援技術との相性が変わるので、フォーム体験は大きく変わります。

実務でよくある使用例（制作会社の現場を想定）

JavaScript側で独自検証を完了させた後にだけ送る

たとえば複数項目を組み合わせた独自判定を通したあと、最後に送信だけ進めたい場面です。ただしブラウザ標準検証を意図的に捨てることになるので、エラー表示の設計を自前で持っている前提で使います。

submit イベントに依存しない既存フォームを後方互換で送る

古い実装やライブラリ都合で、送信前イベントを通したくないケースがあります。こうした場合の逃げ道としては機能しますが、保守時に意図が伝わるコメントが欲しい場面です。

自動送信風UIでも、本当は requestSubmit() の方が自然なことが多い

検索フォームや絞り込みUIで「条件が変わったらすぐ送る」を実装したいとき、submit() を選ぶと検証や分析イベントが抜けやすいです。まずは requestSubmit() を試し、それで足りない理由があるときだけ submit() に下げます。

事故りやすい例と回避策

悪い例：submit イベントが動く前提で submit() している

JavaScript

form.addEventListener('submit', (event) => {
    event.preventDefault();
    sendAnalytics();
});

form.submit();

この書き方だと sendAnalytics() は実行されません。submit イベント自体が発火しないからです。

良い例：イベントと検証を使いたいなら requestSubmit() にする

JavaScript

form.addEventListener('submit', (event) => {
    event.preventDefault();
    sendAnalytics();
});

form.requestSubmit();

submit イベントを通す設計なら、こちらの方が意図に合います。

A11y / UX で確認したいこと

関連API・属性との相互作用

requestSubmit()
送信ボタン相当の流れで送りたいときの第一候補です。制約検証も submit イベントも含みます。
checkValidity() / reportValidity()
独自分岐を入れる前に、入力値が妥当かを確認したいときに使います。submit() 前に明示的に使うことがあります。
FormData
送信前にデータの中身を確認したいときに便利です。ただしどの送信ボタン経由かの差は submit() と他手段で変わります。
novalidate
フォーム全体で標準検証を外すHTML属性です。submit() はこれとは別に、メソッド側の性質として検証を飛ばします。

試験で得点できる整理

FAQ

submit() の前に dispatchEvent(new Event('submit')) すれば同じですか？
同じではありません。自分で投げたイベントと、ブラウザのフォーム送信アルゴリズムの流れは一致しません。必要なら requestSubmit() を使う方が自然です。
Ajax送信でも submit() を使いますか？
送信を fetch() で自前実装するなら、そもそもフォームの標準送信を使わないことも多いです。標準送信を残すか、自前通信にするかを先に決めます。
form.submit is not a function が出ました。
フォーム内に name="submit" または id="submit" のコントロールがないか確認します。衝突している場合は名前変更が最優先です。

症状早見

症状：submit ハンドラが動かない
原因候補：submit() を直接呼んでいる。確認：呼び出し箇所。解決：requestSubmit() に切り替えるか、処理の置き場所を見直す。
症状：空欄でも送信される
原因候補：制約検証を飛ばしている。確認：required があるフォームに submit() を使っていないか。解決：requestSubmit() または reportValidity() を使う。
症状：form.submit is not a function
原因候補：submit という名前のフォーム部品がある。確認：HTMLの name/id。解決：衝突する名前を避ける。
症状：押したボタン種別がサーバーに届かない
原因候補：送信ボタン経由ではなく submit() で送っている。確認：Network または受信データ。解決：requestSubmit(submitter) を使う。

まとめ：迷ったときの判断軸