SiteLint documentation and guidelines

Forms must have a submit button

Description

A clear, accessible control that completes and sends the form – most commonly a submit button — helps users understand how to finalize their input. While a traditional submit button is the simplest, predictable pattern, forms can also be submitted with other accessible triggers (e.g., an icon button, an implicit submit on Enter, or a programmatic call) as long as the mechanism is keyboard-operable, clearly labeled, and communicated to all users, including those using assistive technologies.

Disabilities impacted

  • Motor impairments: people who use keyboards, switches, or voice-control software need a single, predictable control that can be activated without a mouse. If the form auto-submits or relies on an obscure gesture, they may never trigger it.
  • Visual impairments: screen-reader users explore the page sequentially. A clearly labeled Submit (or equivalent) control gives them an unambiguous landmark. Hidden or implied submission methods are often skipped or mis-announced.
  • Cognitive disabilities: explicit, consistently placed controls reduce memory load and anxiety. Ambiguous completion cues (just press Enter or icon-only buttons) can cause users to abandon the form or re-enter data multiple times.

Why it matters

Every form needs an obvious, keyboard-reachable way to finish the task. Whether it’s a labeled button, an accessible icon with role="button", or an explicit keyboard instruction, the mechanism must be discoverable, operable, and understandable. When that control is missing or unclear, users with disabilities are the first to be excluded-resulting in lost data, frustrated visitors, and possible legal exposure. A predictable commit action is therefore a baseline accessibility and usability requirement, not an optional extra.

Coding problems and solutions

Common coding problems

  • No obvious commit action – the form has no visible, keyboard-reachable control that tells users “you are finished, press here”.
  • Hidden or zero-size submit button – a button exists in the markup but is removed from the accessibility tree or viewport with display:none, opacity:0, width:0, etc.
  • Non-button submit – a <div>, <i>, or image is wired to form.submit() via JavaScript; it is not focusable, has no accessible name, and does not respond to keyboard or assistive-tech events.
  • “Enter to submit” only – no visual or programmatic cue that Enter will send the form; screen-reader and switch users may never discover it.

How to fix it

1. Provide a reachable, perceivable commit control

Give users at least one control that:

  • is a real <button type="submit"> (or <input type="submit">);
  • remains in tab order (tabindex="0" is implicit);
  • has an accessible name (text content or aria-label);
  • is not visually hidden or clipped to zero size.
Problem: no commit control
<form action="/save" method="post">
  <label>Email <input name="email" required></label>
  <!-- user has no idea how to finish -->
</form>
Fixed: explicit submit button
<form action="/save" method="post">
  <label>Email <input name="email" required></label>
  <button type="submit">Save preferences</button>
</form>

2. If you auto-submit or use an icon, make it accessible

Auto-submission on blur/timeout is allowed only when you also announce the change (e.g., Saving… live region) and give users a way to undo. Icon-only buttons need an accessible name and keyboard support:

Accessible icon button
<button type="submit" aria-label="Send message">
  <svg aria-hidden="true"><use href="#icon-paper-plane"></use></svg>
</button>

3. Never hide the primary commit control

CSS that removes the button from the accessibility tree or viewport forces users to guess or abandon the task.

Problem: button is present but invisible
<button type="submit" style="display:none">Submit</button>
Fixed: button remains visible and focusable
<button type="submit" class="btn btn-primary">Submit</button>

4. Reinforce the expected interaction

  • Keep the submit button inside the <form> so screen readers associate it.
  • Disable the button on click and show Submitting… to prevent double submissions.
  • After submission, move focus to the confirmation message or error summary.

Known limitations

  • Complex, multi-step forms: each step still needs its own explicit Continue / Save & continue / Submit control. If you replace the button with an auto-advance or timer, provide a non-timed path and a visible Go back link so users with motor or cognitive impairments can stay in control.
  • Dynamic forms (AJAX, live regions, progressive disclosure): whenever new fields are injected, re-evaluate that the primary commit control is still in the DOM, inside the same <form>, and remains keyboard-focusable. Screen readers do not automatically re-scan for newly added buttons.
  • Browser & Assistive Technologies quirks: some combinations (e.g., Safari + VoiceOver on iOS) will not announce an enterkeyhint or implicit submission. Always supply at least one real <button type="submit"> and test with keyboard-only, Switch Control, TalkBack, NVDA, and JAWS to verify the control is reachable and named consistently.
  • Single-page-app routing: client-side navigation can steal focus or remove the button from the DOM before the user activates it. Preserve focus order and keep the button disabled (not hidden) while the request is in flight, then return focus to a confirmation or error landmark.

Resources

Standard

  • Standard: SiteLint, Best Practices
  • Rule ID: missing-submit-button