How do you ensure a complex form is fully accessible?

WHAT THIS TESTS: The interviewer wants to know if you treat accessibility as an architectural concern rather than a polish layer. They are looking for fluency in the accessibility object model, specifically how HTML semantics, keyboard focus, and ARIA attributes work together to create a coherent experience for screen reader and keyboard-only users. This question separates developers who add labels from those who design robust, inclusive validation flows.

A GOOD ANSWER COVERS: First, semantic foundation. Every input needs an associated label, preferably through explicit htmlFor and id pairing or implicit nesting, so the accessible name is computed correctly. Second, focus choreography. On submit with errors, the form should programmatically move focus to either an error summary at the top of the form or the first invalid field, using a ref and focus method, so keyboard users are immediately aware of the problem without tabbing backward. Third, ARIA state and description. Set aria-invalid to true on fields that fail validation, and use aria-describedby to point to the error message element id. This causes screen readers to announce the invalid state along with the descriptive error text when the field receives focus. Fourth, live region discipline. If you use an aria-live region for inline errors, pair it with controlled focus management to avoid interrupting the user mid-typing.

COMMON WRONG ANSWERS: Relying solely on visual color changes like red borders to indicate errors. Using placeholders instead of labels. Adding aria-live regions indiscriminately without managing focus, which creates a verbose and confusing screen reader experience. Treating ARIA attributes as replacements for semantic HTML, such as using divs with role textbox instead of native input elements. Claiming that React manages accessibility automatically.

LIKELY FOLLOW-UPS: How would you handle a multi-step form wizard where focus needs to shift between pages? What is your strategy for announcing inline validation versus submit-time validation? How do you test these patterns without a screen reader? What happens to focus when a modal containing a form opens or closes?

ONE CONCRETE EXAMPLE: Imagine a registration form with email, password, and confirm password fields. On submit, validation runs and finds the email is malformed and the passwords do not match. The component scrolls to and focuses an error summary banner at the top, which has tabindex negative one and an aria-live polite region containing the error list. Each invalid input below has aria-invalid set to true and an aria-describedby attribute pointing to its respective error paragraph. When the user tabs to the email field, the screen reader announces the accessible name from the label, the invalid state, and the error message describing the format requirement.