Phase 8 — Accessible Forms Allowed

This gauge covers Chapter 12 after Responsive CSS and Pseudo-elements.

Learning goal

Build forms whose controls have clear names, instructions, groups, purposes, and actions before adding visual presentation.

Inherited tools

Everything allowed through ../responsive/allowed.md remains available.

New HTML

• form
• label
• select, option
• optgroup
• datalist
• textarea
• fieldset, legend
• output
• progress
• meter

The inherited input, button, p, span, and structural elements may now be used as parts of complete forms.

Form attributes

• On form: action, method, novalidate
• On labelable controls: id, name, required, disabled
• On input: appropriate type, value, placeholder, autocomplete, min, max, step, minlength, maxlength, checked, list, accept, multiple
• On label: for
• On select: multiple
• On option: value, selected
• On optgroup: label, disabled
• On datalist: id
• On textarea: rows, cols, placeholder
• On output: for, name
• On progress: value, max
• On meter: value, min, max, low, high, optimum
• For help text: aria-describedby
• For required or invalid state only when native HTML cannot express it: aria-required, aria-invalid

Input types

In addition to the inherited types used in earlier lessons:

• search
• url
• date
• number
• file
• range
• color
• hidden

Learning rules

1. Give every control a visible label. Prefer an explicit label for matching the control's unique id.
2. A placeholder is an example or hint, not a replacement for a label.
3. Use the input type that matches the requested data so browsers can provide suitable keyboards, validation, and autofill behavior.
4. Give submitted controls meaningful name values. Controls without a name are not included in ordinary form submission.
5. Use autocomplete tokens when the purpose maps to known user information.
6. Group related radio buttons or checkboxes with fieldset and describe the group with legend.
7. Associate persistent instructions with a control using aria-describedby when the relationship is not already clear.
8. Use native required, length, and range constraints before recreating them with ARIA. Do not add aria-required when required already expresses it.
9. Identify required fields in text, not by colour alone.
10. Give every button an explicit type. Use submit for submission, reset only when clearing is genuinely useful, and button for non-submit actions.
11. Keep focus indicators visible and keep source order aligned with the intended reading and keyboard order.
12. Do not rely on colour, placeholder disappearance, or browser validation alone to explain what data is expected.
13. Use optgroup with a visible label when a long select benefits from meaningful categories.
14. Connect an input's list attribute to a datalist's id. Datalist options are suggestions; unlike select options, they do not restrict other values.
15. Give specialized inputs visible labels and persistent format instructions. Browser interfaces for date, file, range, and colour controls vary.
16. Use accept to suggest suitable file types, but validate files on the server because browser filtering is not a security boundary.
17. A hidden input is not interactive and does not need a visible label. Never treat its value as secret or trustworthy merely because it is hidden.
18. Give output an accessible name and use for to identify the controls that contribute to its result.
19. Use progress for task completion and meter for a scalar measurement within a known range. Include adjacent text that communicates the value.
20. Use native range attributes: progress begins at zero, while meter may also define min, low, high, and optimum.
21. An input-group addon is supplementary. Keep a visible label (or group name) and connect helpful addon text with aria-describedby when needed.
22. Style switches as real checkboxes. Do not rebuild toggle behaviour with empty elements in this chapter.

Not allowed

• JavaScript or scripted validation
• Custom controls that replace native inputs, selects, textareas, or buttons
• Essential instructions shown only in placeholders
• Positive tabindex values or CSS visual reordering of form controls
• ARIA that duplicates or conflicts with native HTML
• Datalist suggestions presented as enforced choices
• Client-side file filtering presented as file validation
• Secrets or trusted authorization data stored in hidden inputs
• progress used for an ordinary measurement or meter used for task progress
• Inline styles
• Any HTML tag, attribute, or CSS property not inherited or listed above

Pages

• 01-labels-inputs.html — form structure, explicit labels, names, types, and autocomplete
• 02-select-textarea.html — select menus, options, textareas, and persistent instructions
• 03-groups-actions.html — fieldsets, legends, grouped choices, required state, and button types
• 04-complete-form.html — a responsive accessible form combining the chapter rules
• 05-suggestions-groups.html — datalist suggestions and labelled option groups
• 06-specialized-inputs-status.html — specialized input types, output, progress, and meter
• 07-input-groups.html — prefix and suffix addons beside labelled fields
• 08-choice-styles.html — inline choices, disabled states, and checkbox switches

Rules to lean on

Rules 2, 32, 44, 54–59, 63, 72–80, 99–110, 111–122, 135–144, and later admin form presentation rules when studying Chapter 18.