In 04-01 we saw that native form controls (<input>, <select>, <textarea>, <button>) come with role, focus and keyboard operation built in. But an accessible form needs more than good controls: it needs every control to have a name, related fields to be grouped, hints and errors to reach everyone, and the focus order to be logical. Those are exactly the 3.3.x criteria ("Input Assistance") that in Module 3 we studied as a requirement and now implement.

Our practice ground is Cursalia's enrollment/registration form: name, email, phone, password, level of education, interests and terms acceptance. We'll build it piece by piece, always with correct versus incorrect examples, thinking about Marta (NVDA must read her each field's label), Hugo (needs clear, unambiguous instructions) and Lucía (traverses it entirely with the keyboard).

1. The label: associating label and control
2. Why the placeholder is not a label
3. Grouping with fieldset and legend
4. Required fields: required and aria-required
5. Instructions and hints with aria-describedby
6. Accessible errors (and a first look at role="alert")
7. autocomplete and input types
8. Focus and logical order
9. Common mistakes and tips
10. Exercises
11. Conclusion

Every form control must have an accessible label. The label is the control's name (remember 4.1.2): without it, Marta hears "edit box" without knowing what to type. There are two correct ways to associate a <label> with its control.

Option A — for / id (the most common and flexible): the label's for attribute points to the control's id.

Option B — wrapping label: the control goes inside the <label>. No for/id needed.

Both make clicking the text focus the field (a larger click area, something Lucía appreciates) and make the reader announce it with its name. The usual mistake is not associating them: loose text next to an input.

Here there is no <label> (or its for doesn't match any id): Marta hears "blank edit box". If by design you can't show visible text (for example, the catalog search box with just a magnifying glass), use aria-label, which we'll cover in 04-03:

It's tempting to add just a placeholder="Email" and skip the <label>. That's a serious mistake for several reasons:

Rule: the placeholder is, at most, a format hint; it never replaces the label.

When several controls form a single conceptual group —a set of radios (pick one) or checkboxes (pick several)—, you must wrap them in a <fieldset> and give them a common title with <legend>. That way the reader announces the group ("Level of education, group") before each option, giving the context a lone radio wouldn't have.

Marta hears: "Level of education, group. Secondary, radio button, 1 of 3". Without the fieldset, she'd hear three lone radios without knowing which question they answer.

The same applies to interests (checkboxes) or accepting several terms. Don't overuse fieldset for independent fields (name, email): it's only for groups.

Marking a field as required has two sides you must cover at once: the functional and the communicative.

• required: native attribute. Activates the browser's validation and exposes the "required" state to the reader (Marta hears "required"). It's the first choice.
• aria-required="true": only if you need to communicate the requirement without triggering the browser's native validation. Don't duplicate both without reason; required is usually enough.
• Visual and textual indication: a red asterisk isn't enough (fails 1.4.1, "not by color/shape alone"). Explain what the asterisk means and, better still, reinforce it with text.

Many fields need a hint: password format, what the phone number is used for, etc. For that hint to be read alongside the field (and not left as orphan text beside it), you associate it with aria-describedby, which points to the id of the hint text. The reader reads the label first and the description afterward.

Marta hears: "Password, edit box, required. At least 8 characters, with one letter and one number". Hugo reads that same clear instruction before typing, not after failing. aria-describedby can point to several ids separated by spaces (for example, the hint and the field's error message).

When the user makes a mistake, criterion 3.3.1 requires identifying the error in text (not by color alone) and describing it usefully. Best practices:

• Explicit text, not just a red border: "The email is invalid: the @ is missing".
• Associated with the field using aria-describedby, so the reader reads it when focusing that field.
• Don't rely on color: add an icon or the word "Error" (this is 1.4.1, which we'll cover in depth in 04-04).
• Moving focus to the first field with an error or summarizing the errors at the top helps Lucía and Marta.

Here aria-invalid="true" marks the field as invalid in the accessibility tree, and aria-describedby makes the message read when you focus it.

When the error appears dynamically (after clicking "Submit", without reloading the page), you also need to announce it even if focus is elsewhere. That's what live regions are for. A brief introduction: a container with role="alert" (or aria-live="assertive") makes the reader read automatically any text that appears inside it, without the user having to go looking for it.

We stop at this introduction: the detail of aria-live, role="status" vs role="alert" and dynamic regions is covered at the markup level in 04-03, and full validation with JavaScript (when to validate, how to move focus, updating messages live) belongs to Module 5.

Choosing the right type and adding autocomplete reduces everyone's effort, and very noticeably for Lucía (less typing), Hugo (less to remember) and anyone using voice control or a phone.

autocomplete also meets criterion 1.3.5 ("Identify Input Purpose"), which helps tools that adapt or fill in fields for the user.

The order in which Lucía reaches the fields when pressing Tab must follow the form's visual and logical order. The key is that the DOM order matches the visual order: if you lay out top to bottom in the HTML, focus will flow correctly with no tricks.

• Don't use a positive tabindex (tabindex="1", "2"...): it breaks the natural order and is a constant source of bugs. Let the DOM dictate the order.
• A real <button type="submit"> lets you submit the form with Enter from any field.
• After submitting with errors, moving focus to the error summary or the first failing field saves Lucía from tabbing blindly (JS implementation: Module 5).

• Fields with no associated <label>. This is the number-one failure. Every control needs a name via for/id, a wrapping label or, as a last resort, aria-label.
• Using the placeholder as a label. It disappears, contrasts poorly and is unreliable as a name. Always add a visible label.
• Requirement by color only. The red asterisk isn't enough: add required and explain what the * means.
• Hints and errors left unassociated. A hint next to a field that isn't linked with aria-describedby is invisible to the reader.
• Errors by red border only. Marta doesn't see color: the error must be in text and be associated.
• Radios/checkboxes without fieldset/legend. They lose the context of the question.
• Positive tabindex. Almost never the solution; order the DOM instead.
• Tip: fill in your entire form using only the keyboard and a reader, with your eyes closed. If you can't tell what a field asks for or where the error is, it isn't accessible yet.

This fragment of the Cursalia registration doesn't associate labels. Fix it using for/id and replace the placeholder-label with a real label.

Users can check several interests. Mark up this checkbox group correctly so the reader announces the group title.

Write the "Password" field: visible label, required, with an associated format hint and an error message (associated and not dependent on color alone) for when the password is too short.

Solution 1. Each control gets an associated label; the placeholder gives way to a real <label>:

Solution 2. The whole group goes in a <fieldset> with a <legend>:

Now the reader announces "Interests, group" before each box.

Solution 3. Visible label + required + hint with aria-describedby + associated error in text, with an icon in addition to color:

Note that aria-describedby points to two ids (hint and error), so the reader reads both. When the password is valid, your code will remove aria-invalid and the error message (that's already JS logic, Module 5).

An accessible form isn't magic: it's labeling every control, grouping what belongs together, communicating the requirement and hints through associated text, describing errors clearly and not by color alone, and respecting the DOM's focus order. With this, Cursalia's enrollment form stops being a wall for Marta, Hugo and Lucía. We've leaned almost entirely on native HTML and only peeked at aria-describedby, aria-invalid and role="alert".

Those aria-* attributes are the door to the next lesson. In 04-03 · Using ARIA Roles and Properties we'll step back to understand what ARIA is, its five golden rules (starting with "don't use it if there's native HTML"), how the accessible name we've been using is computed (aria-label, aria-labelledby, aria-describedby) and how to describe states like aria-expanded on Cursalia's filters dropdown, always at the markup level.