Canon Forms

CANON · Forms

Forms are the highest-stakes interface in any product. A confusing form costs conversions in marketing, costs data in apps, and costs trust everywhere. Most form failures are predictable.

Quantified Rules

Field Structure

<div class="field">
  <label for="email">Email address</label>
  <input
    id="email"
    name="email"
    type="email"
    autocomplete="email"
    required
    aria-describedby="email-hint"
  />
  <span id="email-hint" class="hint">We'll never share your email.</span>
</div>

Label Placement

Default to labels above inputs. Closer scan path, more mobile space, easier to align.

Label-to-Input Gap

4–8px between label and its input.

Less = cramped. More breaks proximity grouping (Gestalt).

Field-to-Field Gap

16–24px between fields.

Tighter feels rushed. Wider breaks form rhythm.

Input Sizing

The 16px rule is non-negotiable for mobile inputs. Smaller font triggers iOS zoom on focus, which feels broken.

Input Types (HTML5)

Use the right type for the right data:

<!-- For OTP / numeric codes that aren't math -->
<input type="text" inputmode="numeric" pattern="[0-9]*" autocomplete="one-time-code">

Autocomplete Tokens

<input autocomplete="email">
<input autocomplete="given-name">
<input autocomplete="family-name">
<input autocomplete="street-address">
<input autocomplete="postal-code">
<input autocomplete="cc-number">
<input autocomplete="current-password">
<input autocomplete="new-password">
<input autocomplete="one-time-code">

Always set autocomplete. It powers password managers, browser fill, and saves users seconds. Full token list: https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill

Validation Timing

Rule: do not show errors until the user has had a chance to make them. A pristine field is not in error.

Error Messages

<div class="field">
  <label for="email">Email</label>
  <input
    id="email"
    type="email"
    aria-invalid="true"
    aria-describedby="email-error"
  />
  <span id="email-error" role="alert" class="error">
    <svg aria-hidden="true">...</svg>
    Enter a valid email address. Example: name@example.com.
  </span>
</div>

Error Message Examples

Submit Button

Submit button label is the verb of the form. "Submit" is generic. "Create account", "Send message", "Place order" tell the user what will happen.

<button type="submit">
  <span>Create account</span>
  <!-- After click: -->
  <!-- <span class="spinner" aria-hidden="true"></span><span class="sr-only">Creating account…</span> -->
</button>

Required vs Optional Markers

Use one or the other consistently. Don't mark everything as required.

Field Width Should Match Expected Input

Field width is a hint about expected input length. A 40-char-wide field for postal code is misleading.

Multi-Step Forms

Stepper UX requirements:

• Show progress (3 of 5)
• Show step names (not just numbers)
• Allow back navigation
• Save progress between steps
• Don't validate future steps based on current

Question Density Per Step

3–7 fields per step.

Below 3 feels wasted. Above 7 feels heavy. 5 is the sweet spot.

Inline Help vs Tooltips

Tooltips must trigger on focus too, not hover only. Touch and keyboard users need access.

Anti-Patterns

Login / Signup Specifics

<!-- Login -->
<input type="email" autocomplete="username" required>
<input type="password" autocomplete="current-password" required>

<!-- Signup -->
<input type="email" autocomplete="username" required>
<input type="password" autocomplete="new-password" required>

<!-- Always include show-password toggle -->
<button type="button" aria-label="Show password" aria-pressed="false">
  <svg>...</svg>
</button>

Decision Tree

Building a form?
├─ Use <form> with proper submit handling
├─ Each field has <label for>, type, autocomplete, name
├─ Inputs: 16px font, 44px height, 12/16 padding
├─ Required fields: validated on blur or submit (not on load)
├─ Errors: specific message + icon + aria-live
├─ Submit button: verb describing action, full-width on mobile
├─ > 8 fields? Use multi-step with progress
└─ Login/signup? Use correct autocomplete tokens

Audit Checklist

1. Every input has a <label> with for matching id. No placeholder-as-label.
2. Every input on mobile has font-size >= 16px.
3. Every input has the correct type (email, tel, url, etc).
4. Every input has autocomplete set where applicable.
5. Validation doesn't fire before user has had a chance to enter.
6. Errors are specific, persist until corrected, and have aria-live="polite".
7. Submit button uses an action verb, not "Submit".
8. Submit button shows loading state after click; doesn't allow double-submit.
9. Required marker strategy is consistent (mark required OR mark optional, not both).
10. Multi-step forms show progress and allow back navigation.

Citations

• WCAG 2.2 SC 3.3.1 Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html
• WCAG 2.2 SC 3.3.2 Labels or Instructions: https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html
• WCAG 2.2 SC 1.3.5 Identify Input Purpose: https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html
• HTML autocomplete tokens: https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill
• Nielsen Norman Group, Form Design: https://www.nngroup.com/articles/form-design-placeholders/
• Material 3 Text Fields: https://m3.material.io/components/text-fields/overview
• Apple HIG Text Fields: https://developer.apple.com/design/human-interface-guidelines/text-fields