accessible-formslisted

# Accessible Forms The form is where accessibility most often breaks. Visual designers prioritise clean layouts; engineers reach for `placeholder` as a label; validation surfaces errors at submit; keyboard users get trapped in modal flows; screen-reader users discover required fields after submission. This skill encodes the patterns that pass real audits. ## Purpose Forms are conversion-critical (signup, checkout, contact, KYC) AND accessibility-critical (auth, payment, account management are AAA paths per `wcag-accessibility`). The patterns below cover every input type, every state transition, every validation pattern, and the two new WCAG 2.2 SCs that specifically target authentication forms. ## Standards Cited - **WCAG 2.2 §1.3.1** — Info and Relationships (label association) - **WCAG 2.2 §1.3.5** — Identify Input Purpose (autocomplete tokens) - **WCAG 2.2 §2.4.6** — Headings and Labels (descriptive) - **WCAG 2.2 §3.3.1** — Error Identification - **WCAG 2.2 §3.3.2** — Labels or Instructions - **WCAG 2.2 §3.3.3** — Error Suggestion - **WCAG 2.2 §3.3.4** — Error Prevention (Legal, Financial, Data) - **WCAG 2.2 §3.3.7** — Redundant Entry (NEW in 2.2) - **WCAG 2.2 §3.3.8** — Accessible Authentication Minimum (NEW in 2.2) - **WCAG 2.2 §3.3.9** — Accessible Authentication Enhanced (NEW in 2.2) - **HTML Living Standard** — `<label>`, `<input>`, `autocomplete` attribute, constraint validation API - **WAI-ARIA 1.2** — `aria-required`, `aria-invalid`, `aria-describedby`, `aria-