DEV Community

FrozonFreak
FrozonFreak

Posted on Edited on Originally published at thewebhig.hashnode.dev

Tell the browser what each field is for (Web HIG tip #14)

#forms #webdev #a11y #html

Open your checkout or sign-up form on a phone and tap the email field. If the keyboard has no @ key, or the browser offers nothing to fill in, the form isn't telling the browser what it's asking for. Now try the phone number, the postcode, and the password. Every field that makes someone type by hand is one more chance for a typo or for them to give up.

Web HIG tip #14 (Quick #52): Use native input types and autocomplete attributes appropriate to the field purpose.

Why it matters

The browser already knows a lot about the person using it. It just needs to know which field is which:

  • type="email", type="tel", and type="url" bring up a keyboard suited to the field on most phones, so nobody has to hunt for @, digits, or a slash
  • autocomplete tokens let the browser offer the saved name, email, address, or card, so one tap can replace a whole block of typing
  • Password managers use autocomplete="current-password" and "new-password" as the clearest signal of whether to fill a saved password or offer a new one
  • People with motor or cognitive disabilities, and anyone on a small screen, gain the most from typing less

The full HIG covers this in §2.11, Forms Contract. Three rows of its table apply here. Autocomplete: use appropriate autocomplete tokens for common fields (name, email, address, cc-*). Password managers: do not block autofill, and use standard input types with autocomplete="current-password" / "new-password". Input types: use semantic types (email, tel, url, number) for mobile keyboard optimization. Quick #52 is Quick-only guidance, with no separate rule ID, and it pairs with Quick #50: every field still needs a visible label.

Author's note, not part of the HIG: WCAG 2.2 SC 1.3.5 Identify Input Purpose (Level AA) asks that fields collecting information about the user expose their purpose in code, for the purposes listed in WCAG section 7. The matching autocomplete tokens are the usual way to do that. one-time-code isn't on that list.

The rule of thumb

Ask: if the browser only had this markup, would it know what each field is for?

This form looks fine, but the browser sees three anonymous text boxes:

<label for="f1">Email</label>
<input id="f1" name="f1" type="text" autocomplete="off">

<label for="f2">Phone</label>
<input id="f2" name="f2" type="text">

<label for="f3">Password</label>
<input id="f3" name="f3" type="password" autocomplete="off">
Enter fullscreen mode Exit fullscreen mode

Name the purpose and the browser does the rest:

<label for="email">Email</label>
<input id="email" name="email" type="email" autocomplete="email"
       placeholder="name@example.com">

<label for="phone">Phone</label>
<input id="phone" name="phone" type="tel" autocomplete="tel">

<label for="password">Password</label>
<input id="password" name="password" type="password"
       autocomplete="new-password">
Enter fullscreen mode Exit fullscreen mode

The labels and layout don't change. The keyboard does, and so does what the browser offers to fill.

Do this instead

  • Pick the type from what the field holds: email, tel, url, search, password. Use type="number" only for real quantities you might step up or down. For digit strings that aren't numbers, such as card numbers, security codes and one-time codes, use type="text" with inputmode="numeric" and the matching autocomplete token (cc-number, cc-csc, one-time-code). Add pattern only when you also show a clear error message. Use inputmode="numeric" for a postcode only if every postcode you accept is digits-only
  • Add an autocomplete token to every field about the user: name, email, tel, address-line1, postal-code, country, cc-number, cc-exp, cc-csc, username. Sign-in codes get one-time-code
  • Use current-password on sign-in and new-password on sign-up and password change, so password managers fill or generate correctly
  • Don't set autocomplete="off" to stop autofill on these fields. Browsers often ignore it on sign-in fields anyway. Keep off for values that are never reused or where a saved suggestion would be wrong, such as a CAPTCHA answer, an in-app search or combobox that shows its own suggestions, or a one-off confirmation code. For a one-time sign-in code, use one-time-code so the phone can fill it from the SMS. On a form where an admin sets someone else's password, use new-password, not off
  • If a form asks for two addresses, prefix the tokens: shipping address-line1 and billing address-line1, shipping postal-code and billing postal-code. (street-address is for a single multi-line <textarea>.) For more than one shipping address, put a section- token first, e.g. section-gift shipping postal-code

Quick check for your app

Open your sign-up, sign-in, and checkout forms (say, example.com/checkout) on a real phone. Tap each field: the keyboard should match it, with @ for email and a keypad for phone and codes. Then let the browser fill the form from a saved profile and check that every value lands in the right box. Sign up with a password manager, sign out, and sign back in: it should offer to save, then fill. A tool can list the autocomplete attributes, but only filling the form shows whether the right values land in the right fields.

The Web HIG is an open set of guidelines for how the web should behave, not a component library. Design systems define how it looks. The Web HIG defines how it behaves.

Top comments (0)