A form with width: 400px inputs renders fine on desktop but overflows phones below 420px wide, forcing horizontal scroll on every keystroke. Two-column form layouts that don't collapse to one column on mobile cram fields into half the screen width and make typing error-prone. Forms are the primary conversion surface — sign-ups, checkout, contact — and a form that is hard to complete on mobile directly reduces business outcomes.
High because form friction maps directly to conversion loss on the highest-value pages.
Apply width: 100% with box-sizing: border-box to all form inputs globally, and wrap multi-column form layouts in a responsive grid that stacks on mobile. Audit forms under src/components/forms/ and checkout flows.
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4">
<input class="w-full px-3 py-2 border rounded-md" type="text" />
<input class="w-full px-3 py-2 border rounded-md" type="text" />
</div>
ID: mobile-responsiveness.layout.responsive-forms
Severity: high
What to look for: Check form components for input sizing. Look for fixed-width inputs (e.g., width: 300px) that would be too wide or too narrow on mobile. Check whether inputs use full-width styling (width: 100%) or responsive sizing classes. Look for multi-column form layouts that may collapse poorly on mobile.
Pass criteria: Count all form input elements (<input>, <select>, <textarea>) across the project. For each, verify it uses width: 100%, responsive sizing classes (Tailwind w-full), or is contained within a responsive form layout. Report: "X of Y form inputs use responsive sizing." No more than 0 form inputs may use fixed pixel widths exceeding 320px without a responsive constraint. Multi-column form layouts must have at least 1 mobile breakpoint that stacks columns.
Fail criteria: At least 1 form input has a fixed pixel width that would render poorly on mobile (exceeding 320px without responsive override), or at least 1 multi-column form layout has no mobile breakpoint and forces horizontal scroll.
When evaluating form input sizing, assess it relative to the viewport, not just the immediate container. If the container itself has a fixed width that causes horizontal overflow (caught by no-horizontal-scroll and no-fixed-width), form inputs that are full-width within that broken container are still effectively inaccessible on mobile. Note in detail if forms appear correct within their container but the container itself overflows the viewport.
Skip (N/A) when: Never — virtually all web projects have at least one form.
Detail on fail: "2 of 8 form inputs have fixed widths — contact form inputs have fixed width of 400px, exceeding 320px limit, and will overflow on screens narrower than 420px".
Remediation:
input, select, textarea { width: 100%; box-sizing: border-box; }
In Tailwind:
<input class="w-full px-3 py-2 border rounded-md" type="text" />
For multi-column forms, use responsive grid:
<div class="grid grid-cols-1 sm:grid-cols-2 gap-4">
<input class="w-full" ... />
<input class="w-full" ... />
</div>