Frontend Architecture
Accessible forms: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the keyboard-path discipline stick.
Reconstruct the unit’s spine — label association, announced errors, focus on the first invalid field, native vs ARIA, and what you inherit when you preventDefault — without looking back at the lesson.
- 01What does it mean for a label to be programmatically associated, and why is a placeholder not a substitute?
- 02Why does visually painting invalid fields red announce nothing to a screen reader, and what two-part fix makes errors perceivable?
- 03On a failed submit with custom validation, why is moving focus the highest-leverage step, and where should focus go?
- 04Native constraint validation does focus, scroll, and the error bubble for free. What exactly do you inherit the moment you call e.preventDefault()?
- 05Why is a div-based control a worse bug than a missing label, and what does 'use the native element' actually buy you?
- 06Is controlled-vs-uncontrolled a React accessibility decision? Explain the relationship.
If you could reconstruct each answer from memory, you hold the unit’s spine: every control needs a programmatically associated name (a placeholder is not one, and a third of the web fails this); errors must be announced through a pre-existing live region and tied to their field with aria-invalid + aria-describedby and stated as suggestions; a failed submit must move focus to the first invalid field, not just scroll; native elements ship the role, focusability, and keyboard handling you cannot fully replicate; the moment you preventDefault you inherit all of that; and controlled-vs-uncontrolled is a state decision, orthogonal to accessibility.