# Easy and Accessible Forms — narration script

Runtime 8:44. Timecodes are when each chapter starts; the film's animation is keyed to these cue times, so a recorded voice-over should keep each line near its timecode.

## 0:00 · Where forms lose people

- `0:01` Beyond reading content, most of the actions people take on the web require a form: signing up for a service, buying a product, booking a trip, applying for a job, reporting a problem. The form is where they accomplish the task, or fail at it.
- `0:21` In a survey by the Baymard Institute, seventeen percent of American online shoppers had abandoned an order because the checkout was too long or complicated. The average checkout shows twenty-three form fields. Most could manage with far fewer. And even when a form is easy, asking people to do something they don't want to do can be worse. The same survey found that eighteen percent abandoned the process because the site made them create an account. Clearly we have to be careful about both what we ask and how we ask it.
- `1:02` So let's take a small form, four questions: your name, your email, a mobile number for text alerts, and a password. And let's fill it in twice, on a phone, the way most people will.

## 1:18 · The first attempt

- `1:18` First attempt. The page loads, and every box is already red, scolding us before we've typed a thing.
- `1:27` The labels are inside the boxes, as placeholders. Tap the first one and start typing, and the word that said what it was for disappears. What was it again? Was this field the first name, or the full name? The only way to check is to delete what we typed. Fun fact: this is a limit of short-term memory, and it's why interface designers favor recognition over making people recall something.
- `1:58` Every field brings up the same full keyboard, even for the email address and the phone number. So we hunt for the at sign, and switch keyboards for the digits. Every bit of friction adds to the frustration.
- `2:14` The browser could have filled all of this in from what it already knows. But the form turned autofill off, so we type it, all of it, including our email address twice.
- `2:26` We submit, but apparently we messed up. "Invalid input," in red, at the top of the page. Which input? Invalid how? And the password we just typed has been cleared, so we type that again too. Six fields, seventy-nine characters typed, and one error message that doesn't say what's wrong. The experience is so poor, don't be surprised if people just give up. Next, let's see how to remove most of that friction.

## 3:00 · An appropriate name for every field

- `3:01` An interesting thing about making forms frictionless: when you make them accessible, you often get a better result for everyone. Let's look at the markup, and the meaning of each field, starting with how each one is named.
- `3:17` Now the same form, heard instead of seen. A screen reader user moving through it hears "edit text, blank." Four times. Which one is the email?
- `3:31` A placeholder is not a label. It disappears when you type, it's usually faint gray, and assistive technology often can't use it as a name. A label element can.
- `3:44` Give each field a label, tied to it with for and id, and the field has a name that everyone gets: "Email, required, edit text." Tapping the label puts you in the field, so the target is bigger, too.
- `4:00` Wrap each label, field, and message in a form-field element, and the structure says what it is, with no pile of generic div boxes.

## 4:12 · The right keyboard

- `4:12` A form control's type attribute does more than check the value. On a phone it chooses the keyboard. Type email brings a keyboard with the at sign and the dot right there.
- `4:26` Type tel brings the phone keypad: big digits, no hunting. It doesn't check the number, so the server still has to. And for digits that aren't really a number, like a verification code, input mode numeric brings the same keypad without the quirks of a number field.
- `4:47` One more small thing: the enter key hint attribute labels the Enter key. "Next" between fields, "Done" or "Send" on the last one. A tiny promise about what pressing it will do.

## 5:04 · Let the browser type

- `5:04` The fastest typing is no typing. The browser and the person's password manager already know their name, their email address, and their phone number.
- `5:15` The autocomplete attribute says what each field is for: name, email, tel, new password. Now one tap fills the whole form. The accessibility guidelines ask for exactly this on fields about the user, because typing is slow, error-prone, and for some people, painful.
- `5:38` Turning autocomplete off doesn't make a form more secure. It makes people type, or reuse a short password they can remember. Let the password manager suggest a strong one. Never block paste. And don't ask for the same thing twice.

## 5:56 · Errors that help

- `5:56` Errors still happen, so make them help. First, not too early. Nobody has made a mistake on a field they haven't touched yet.
- `6:07` The user invalid CSS pseudo-class waits until the person has had a go at the field before it matches. So the red appears only after they've left it with something wrong, and never on page load.
- `6:22` Second, say what to do, right next to the field. Not "invalid input," but "Enter an email address like name at example dot com." In words, not only in red, because not everyone can see the red.
- `6:40` That message goes in the field's output element. It's tied to the field, so it's read as the field's description, and it's a polite live region, so a screen reader announces it when it appears.
- `6:54` And third, never take away what was typed. On submit, move to the first problem, keep every value, and let the person fix just the one thing that's wrong.

## 7:07 · The second attempt

- `7:08` Second attempt. Same four questions, same phone.
- `7:13` Tap the name field. The browser offers the details it already has for Ana. One tap, and three fields are filled. The password manager offers a strong new password. Accept it. Send.
- `7:28` Four fields, five taps, and not one character typed. That's this example, counted, not a study of people. But the difference isn't subtle, and none of it needed a single line of JavaScript. Like golf, UX is a game where the lowest score wins: forms that need less typing, less scrolling, and less frustration tend to be the winners.

## 7:55 · Check it yourself

- `7:55` You can check any form in a few minutes. Put the mouse away and fill it in with the keyboard alone: every field reachable, in order, with a visible focus.
- `8:09` Turn on a screen reader and listen to each field's name, its state, and its message. Zoom the page to twice its size and make sure nothing is cut off. And make the targets big enough to hit with a thumb.
- `8:25` Then open the keyboards demo on your own phone, and feel the difference the right type makes. An easy form is an accessible form. It's the same work, and everyone gets the benefit.