Frontend Architecture
Accessible forms: multiple-choice review
Crux Multiple-choice synthesis across the forms-a11y unit: label association, announced errors, focus on first invalid, native vs ARIA, and constraint validation.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a decision you make on a real form review — not a definition to recite, but the call between a form that works for everyone and one that only works with a mouse.
Goal
Confirm you can connect label association, announced errors, focus management, native semantics, and constraint validation into one decision tree — the synthesis the lesson built toward.
Quiz
Completed
A field shows its label as placeholder text only. A teammate argues it is fine because the text is visible. Why is this still a WCAG failure?
Heads-up Visually adjacent or placeholder text is not a programmatic association. The accessibility tree needs an explicit for/id or implicit wrapping; pixels on screen do not create the name AT reads.
Heads-up aria-label works but gives sighted users no visible label, so it is a last resort for icon-only fields. A real <label> is the default; the failure here is having no associated name at all.
Heads-up Even at perfect contrast the placeholder disappears on focus and is not a reliable accessible name. Contrast does not turn a placeholder into a programmatic label.
Quiz
Completed
Custom JS validation runs on submit and finds three invalid fields. The team paints them red and scrolls to the first. A keyboard/screen-reader user still hears nothing. What is the highest-leverage missing step?
Heads-up Scrolling helps a sighted mouse user only. Color is invisible to a screen reader and useless to a colorblind user, and focus never moved, so nothing is announced. You must move focus, not just the viewport.
Heads-up alert() interrupts everyone, loses the per-field aria-describedby association, and does not place focus where the fix happens. It is a worse experience for keyboard and AT users.
Heads-up Once you preventDefault and validate yourself, aria-required changes no behavior. The gap is focus management plus announcement, not a re-trigger of native validation.
Quiz
Completed
You add a div with role=button and a click handler that styles exactly like the design. A keyboard user reports the button does nothing. Beyond role, what was forgotten?
Heads-up role=button only changes how AT announces the element. It does not add it to the tab order or wire up Enter/Space activation; those are exactly what <button> gives you for free and a div does not.
Heads-up A div with text content does get an accessible name; the missing piece is keyboard operability (tabindex + key handlers), not the name. This is why the native <button> is the senior default.
Heads-up Mouse handlers do not help keyboard users at all. The fix is keyboard activation (Enter and Space) and tab-order membership, which is why reinventing a button is rarely worth it.
Quiz
Completed
You inject an error message into a div with role=alert in the same render that first mounts that div. Sighted users see it; many screen-reader users hear nothing. Why?
Heads-up role=status is polite and waits for a pause, which is right for non-urgent updates. Errors warrant assertive role=alert; the bug here is timing of when the region exists, not the choice of role.
Heads-up Any element can be a live region. The constraint is that it must be present before the content changes, so the change is observed rather than the region simply appearing already-populated.
Heads-up They do announce changes inside a pre-existing live region. The failure is mounting the region and its text in one pass, so there is no change to observe.
Quiz
Completed
A form relies entirely on native constraint validation (required, type=email, pattern). The team then adds e.preventDefault() to show custom messages and async checks. What responsibility did they just inherit?
Heads-up preventDefault suppresses the native validation UI entirely, including the automatic focus, scroll, and bubble. From that point the focus-on-first-invalid behavior is yours to reimplement.
Heads-up Native focus, scroll, and the error bubble all stop firing once you intercept submit. The behavior, not just the styling, becomes your responsibility.
Heads-up pattern no longer drives any UI after preventDefault. Screen-reader users now depend on your role=alert region, aria-invalid, and aria-describedby plus moving focus — all of which you must add.
Quiz
Completed
Design needs a styled dropdown the native select cannot match visually. Which implementation is the senior default, and why?
Heads-up A half-built role=listbox is worse than the native select it replaces: arrow keys, type-ahead, Escape/Home/End, and aria-activedescendant are all missing, so it is unreachable or broken for keyboard and AT users.
Heads-up Focus, value, and the visible widget drift apart; keyboard focus lands on an invisible control while the mouse sees a fake one. You get the maintenance cost of both with the correctness of neither.
Heads-up A div has no role, is not in the tab order, and has no keyboard behavior, so it is invisible to screen readers and unreachable by keyboard. It is the classic silent WCAG 1.3.1 / 4.1.2 failure.
Recap
The through-line is one decision tree: every control needs a programmatically associated name (real label, not placeholder); errors must live in a pre-existing live region and be tied to their field with aria-invalid + aria-describedby; on a failed submit you must move focus to the first invalid field, not just scroll; native elements ship role, focusability, and keyboard handling you cannot fully replicate; and the moment you preventDefault you inherit the focus and announcement responsibilities the browser handled for free. Reach for ARIA-rebuilt widgets last, and only when the native element genuinely cannot do the job.