Form conversion-path remediation — high-level pointers (local fallback)

kecleon tells you what blocks a form from being submitted. The detailed, current form & conversion-path standards — overlay z-index conventions, agreement-checkbox gating patterns, spam protection setup, and the label/ARIA baseline — live in the team wiki (set OUTLINE + OUTLINE_API_URL and the report links them directly). This file is the minimal high-level fallback for when the wiki isn’t configured: direction only, deliberately not step-by-step, so there’s no detailed content to drift out of sync with the wiki.

• Submit covered by an overlay — a fixed/positioned element (cookie banner, chat widget, promo bar) is intercepting clicks; lower its z-index below the form or scope it so it never overlaps a submit button, especially once the page is scrolled toward the bottom.
• Agreement checkbox covered (issue #59 pattern) — the exact cookie-banner-over-checkbox failure; audit every fixed bottom banner against every required consent checkbox before shipping either.
• Submit disabled on load — confirm the enabling condition (a required checkbox, a JS validator) actually fires, and that it isn’t silently gated behind something the visitor never sees.
• Unlabelled fields — every visible input needs a <label>, aria-label, or (as a last resort) a placeholder — accessibility and clarity both depend on it.
• No spam protection — a public form with no honeypot, CAPTCHA, or Turnstile signal is spam-bait; add one deliberately hidden from assistive tech (off-screen or aria-hidden), not just visually.
• Primary form selection — kecleon grades the page’s largest visible form; a secondary form (newsletter signup, search) isn’t individually graded — check it manually if it also converts.
• Read-only by design — kecleon never submits a real form; verify true end-to-end delivery (the lead actually arrives) separately, on a staging or test endpoint.

Full playbook → the team wiki’s form & conversion-path standards.