PHASE 4Intermediate ~21 min· topic 8 of 8

Topic 4.8

Form UX and Autofill

In one line

Good forms ask for little, label everything, let the browser autofill with autocomplete tokens, show the right phone keyboard with inputmode and enterkeyhint, and explain errors next to the field in words a person can act on.

Think of it like this

A good receptionist versus a bad one. The good one already has your name from last time, hands you a pen that works, asks one thing at a time, and if you make a mistake says "the date should be day/month/year" and points at the box. The bad one hands you three pages, then says "error" and makes you start again. Form UX (user experience) is everything that makes your form the good receptionist.

Words you'll meet

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

UX: User experience: how easy and pleasant something is to use.
Autofill: The browser filling in fields for you with details it has saved.
autocomplete token: A keyword like email or postal-code that tells the browser what a field is for.
inputmode: An attribute that picks which on-screen keyboard a phone shows.
enterkeyhint: An attribute that changes the label on the phone keyboard's Enter key, like "Next" or "Send".
aria-describedby: Links a field to extra text (a hint or an error) by id, so screen readers read it with the field.
aria-invalid: Tells assistive technology that the field's value has a problem.
Password manager: Software (often built into the browser) that saves and fills your passwords.

Step by step

01Tell autofill what each field is

The name is for your server; the autocomplete token is for the browser. They don't need to match.

index.htmlwhole filehtml

<label for="n">Full name</label>
<input id="n" name="fullName" autocomplete="name">
<label for="e">Email</label>
<input id="e" name="email" type="email" autocomplete="email">
<label for="a">Address</label>
<textarea id="a" name="address" autocomplete="shipping street-address"></textarea>
<label for="z">PIN code</label>
<input id="z" name="zip" autocomplete="shipping postal-code" inputmode="numeric">

02Logins that password managers understand

username + current-password on login, new-password on sign-up and password change. With new-password, browsers offer to generate a strong password.

index.htmlwhole filehtml

<input name="user" autocomplete="username">
<input name="pw" type="password" autocomplete="current-password">

<!-- sign-up -->
<input name="newpw" type="password" autocomplete="new-password" minlength="8">

03The right keyboard and Enter key

For a one-time code: digits keyboard, SMS autofill, and a "Done" key.

index.htmlwhole filehtml

<label for="otp">6-digit code</label>
<input id="otp" name="otp" inputmode="numeric" autocomplete="one-time-code"
       pattern="[0-9]{6}" maxlength="6" enterkeyhint="done">

04Errors people can act on

The hint is always visible; the error appears only when needed. Both are linked with aria-describedby, so a screen reader says: "Email, edit text, invalid entry. We'll send the receipt here. Enter an email like name@example.com."

index.htmlwhole filehtml

<label for="email">Email</label>
<p id="email-hint">We'll send the receipt here.</p>
<input id="email" name="email" type="email" required
       aria-describedby="email-hint email-err" aria-invalid="true">
<p id="email-err" class="error">Enter an email like name@example.com.</p>

05When to show errors

Validate when the person leaves a field or submits. Once a field has shown an error, re-check it as they type so the error disappears as soon as it's fixed.

When to show errorsdiagram

Rendering diagram…

Try it yourself

1
Change the Enter key
In the first example, change the search field's enterkeyhint to go. Predict the last console line, then run it. On a phone, the Enter key now reads "Go".
2
Make the errors friendlier
In the second example, change the valueMissing message to name the field: use input.labels[0].textContent + " is required." instead of the fixed text. Run it: phone error: Mobile number is required.
3
Test autofill for real
Copy the first example into a local index.html, open it in Chrome or Safari and click into Full name. If you have saved addresses, the browser offers to fill the whole form. Remove the autocomplete attributes and compare.

Code & diagrams

Autofill tokens, keyboards and Enter keys New tab

Open this page on a phone to see each keyboard. The `16px` font size stops iPhones from zooming in when a field is focused.

Preview

Press Run to see the page.

Console

Nothing logged yet.

Expected console output

name | autocomplete: name | keyboard: (from type) | enter: (default)
email | autocomplete: email | keyboard: (from type) | enter: (default)
pw | autocomplete: new-password | keyboard: (from type) | enter: (default)
otp | autocomplete: one-time-code | keyboard: numeric | enter: done
zip | autocomplete: postal-code | keyboard: numeric | enter: next
q | autocomplete: (none) | keyboard: (from type) | enter: search

Accessible error messages on submit New tab

`novalidate` turns off the browser bubbles, but `validity` still works, so our code reuses the built-in rules and writes its own messages next to each field.

Preview

Press Run to see the page.

Console

Nothing logged yet.

Expected console output

Focus moved to: email
email error: Enter an email like name@example.com.
phone error: This field is required.
All good: sending email=asha%40example.com&phone=9876543210

Break it on purpose

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

Break #1

autocomplete="off" on a login

Add autocomplete="off" to the password field of a login form to "stop browsers saving it".

terminal

$ the page shows

── what you'll see ──

most browsers still offer to save and fill the password; users who rely on a password manager get confused

Break #2

Errors that only use colour

Show errors only by turning the field's border red, with no text.

terminal

$ screen reader and colour-blind users

── what you'll see ──

"Email, edit text" with no mention of a problem; the red border is invisible to some people

Myth vs fact

Myth

autocomplete="off" reliably turns autofill off.

Fact

Browsers ignore it for logins and often for addresses. It's a hint, not a switch.

Myth

inputmode="numeric" only allows digits.

Fact

It only shows a digit keyboard. People can still paste or type letters with a hardware keyboard; add pattern and server checks.

Myth

Validating on every keystroke is the most helpful.

Fact

It shows errors while the person is still typing ("invalid email" after one letter). Validate on leaving the field or on submit, then live once an error is shown.

Myth

Placeholders can hold the format hint.

Fact

They vanish as soon as you type, exactly when you need the hint. Put hints in visible text linked with aria-describedby.

Pro corner

Extra depth for experienced readers. New to this? Skip it for now and come back later.

▸
The autocomplete tokens come from the HTML spec's autofill field list. Section tokens like section-ship group fields when one form has two address blocks; webauthn added to username lets the browser offer passkeys in the autofill menu (conditional mediation).
▸
iOS Safari zooms the page when focusing an input whose font size is under 16px. Set form controls to at least 16px rather than disabling zoom with the viewport meta, which harms people with low vision.
▸
aria-describedby can list several ids ("hint error"); they're read in that order after the name. Text referenced this way is read even if it's visually hidden, but not if it uses hidden or display: none.
▸
For long forms, an error summary at the top (a list of links to each bad field, focused after submit) works well with screen readers and is the pattern used by the UK government design system. Pair it with the inline messages (Topic 7.5).

Remember this

1
Autofill is the browser filling in fields with saved details (name, address, card, passwords). It works best when you tell it what each field is with the **autocomplete attribute and a token** (a fixed keyword) such as name, email, tel, street-address, postal-code, country, cc-number, username, current-password, new-password or one-time-code. Tokens can be prefixed with shipping or billing (shipping postal-code). Correct tokens let password managers save and fill logins and let a phone fill an SMS code with one tap.
2
**inputmode picks the on-screen keyboard** on phones and tablets without changing any rules: numeric (digits only), decimal (digits and a decimal point), tel, email, url, search, text or none. It's the right tool for numbers that aren't quantities, such as card numbers, PINs and OTPs: type="text" inputmode="numeric" keeps leading zeros and avoids number-input quirks (Topic 4.2).
3
**enterkeyhint** changes the label of the Enter key on a phone keyboard: enter, done, go, next, previous, search or send. It only changes the label: you still decide in code what happens, though in a form Enter submits by default (Topic 4.6).
4
Error messages should appear next to the field, say what's wrong and how to fix it ("Enter an email like name@example.com", not "Invalid input"), and not rely on colour alone. Connect the message to the input with aria-describedby="id-of-message" so screen readers read it with the field, set aria-invalid="true" on the field, and on submit move focus to the first field with a problem. Check when the person submits or leaves a field, not on every keystroke, which shouts at people while they're still typing.
5
Layout and grouping. One column is fastest to fill: the eye moves straight down. Put labels above fields, group related fields with fieldsets (Topic 4.3), and keep the order people expect (name, then address, then payment). Ask only what you need; every extra field loses some people. Mark the fewer kind of field: if most are required, label the optional ones "(optional)".
6
Respect the person. Don't block pasting (it breaks password managers), don't clear the form after an error, don't hide rules until after a failure (show "at least 8 characters" up front), and keep buttons labelled with the action ("Create account", not "Submit"). Make tap targets at least 24 by 24 CSS pixels (WCAG 2.2), and bigger, around 44, is more comfortable.

Explain it without notes

What does the autocomplete attribute do, and why does using the right token matter?

What's the difference between type, inputmode and enterkeyhint?

Describe how to show an accessible error message for one field.

Give five ways to make a form easier to fill in.

Practice

Write a delivery address form (name, street address, city, PIN code, phone) with the right autocomplete tokens and keyboards.

Write a password field for a sign-up form with a visible rule hint linked by aria-describedby and the token that lets browsers suggest a strong password.

Trade-offs

↔
Showing all errors at once on submit is simple and predictable; inline errors on leaving each field give faster feedback but can interrupt; most good forms combine both.
↔
Splitting a long form into steps feels lighter but hides how much is left and adds navigation; one page is easier to review and autofill.

Done when you can

I can add the right autocomplete tokens for names, addresses, emails, phones and passwords.
I can pick an inputmode and enterkeyhint for mobile keyboards.
I can write error messages that say how to fix the problem.
I can link hints and errors with aria-describedby and set aria-invalid.
I can move focus to the first error on submit.
I can explain why blocking paste and autocomplete="off" on logins hurt users.

Command Palette

Words you'll meet

Step by step

01Tell autofill what each field is

02Logins that password managers understand

03The right keyboard and Enter key

04Errors people can act on

05When to show errors

Try it yourself

Change the Enter key

Make the errors friendlier

Test autofill for real

Code & diagrams

Break it on purpose

autocomplete="off" on a login

Errors that only use colour

Myth vs fact

Pro corner

Remember this

Explain it without notes

Practice

Trade-offs

Done when you can