A Field With No Name Is a Field That Is Not There

In one line

The accessible name of a form control is not whether the markup has the word label; it is the result of a computation that follows a defined order. If you don't know that computation, you can write every label and still build fields that have no name.

Why this was needed

The place where people get stuck in a signup form is always the same. You press Submit and nothing happens. Somewhere on the screen something may have turned red, but for a screen reader user there was no sound at all, and for a keyboard user focus is still on the button.

If you open the markup at that point, there is a label and there is required. But it says for="mail" while the input is id="email". To the eye they sit side by side, so no one notices. To a machine the two are strangers, and that field's name is nothing.

A screen reader reads a field with no name as just "edit." There is no way to tell what to enter. And this defect survives for a long time because automated check tools often let it pass with "label element present."

How it works

HTML-AAM defines the order for computing the name for each kind of control. For text input fields and textarea, it is this.

1. aria-labelledby  — 가리킨 요소들의 글자를 이어 붙인다
2. aria-label       — 속성값 그대로
3. 연결된 label      — for/id 또는 감싼 label 의 글자
4. title            — 마우스를 올려야 보이는 그것
5. placeholder      — 글자를 치면 사라지는 그것

The sources are HTML Accessibility API Mappings section 4.1 and Accessible Name and Description Computation.

Two things matter here.

First, if any earlier step yields a value, the later ones are not looked at. So if you attach aria-label="이메일" (the Korean word for "email"), a screen reader reads only aria-label no matter what the visible label text is. This is how you get a screen where the screen says "Company email" but the voice says "Email." Voice-control users say the visible text, so for them this mismatch becomes a problem where they can't operate it at all.

Second, a placeholder can also become a name. That is why check tools don't flag it as "no name." But it is a name that disappears the moment you type, so when you come back in a long form, there is no way to confirm what the field was for. For low-vision users, the contrast is also insufficient.

A group needs a name of its own

A radio button is not an answer by itself; several together form one question. Even if you attach a label to each option, it only reads up to "Email radio button, selected." Nowhere does it say what you are choosing.

If you group them with a fieldset and give a legend, the group gets a name. Then the question and answer are read together, like "How to be notified, email radio button."

An error is not a color

A red border means nothing to someone who can't distinguish colors, and doesn't even exist for someone who isn't looking at the screen. You need a separate signal that a program can read.

aria-invalid="true" — this field's value is wrong right now
aria-describedby — points to the element that says what is wrong
role="alert" or aria-live — reads out text that appears later

aria-describedby can list several ids separated by spaces. So if you point to both the help text and the error message, rule guidance such as "at least twelve characters" doesn't disappear when an error appears. Implementations that erase the rule when an error occurs are surprisingly common.

What it looks like in the field

WCAG's Labels or Instructions says only that labels or instructions should be provided when input is needed. In practice, this one line usually breaks in three ways.

The design looks nicer, so the label is removed and only the placeholder is left
A component is reused with a hardcoded id, so using it twice on one screen makes the id collide. The moment they collide, the later label points to the earlier field
The error message replaces the aria-describedby, so the rule guidance disappears

All three look fine if you check with a mouse. That is why this course starts by running the checker and confirming with your own eyes where the name came from. If the source is label, it is safe; if it is placeholder or title, it is a name that disappears; and if it is empty, that field is a field that doesn't exist.

And giving autocomplete properly is also accessibility. For people who find it hard to use their hands, the number of keystrokes is a direct cost, and a value not in the HTML Standard's autofill field names is simply ignored by the browser. autocomplete="e-mail" does nothing.

What you will do in the next lab

You write one signup form and use the calculator to check where the name came from for each field. You move names that came from a placeholder over to a label, group the radios with a fieldset, and make errors readable by a program. At the end, you save the calculator's result to a file.