# 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.