Frontend Developer Interview Question

How would you build a signup form whose validation errors are actually usable, including for screen reader users?

What the interviewer is probing, how to structure your answer, and a spoken example you can adapt.

Quick answer

Use real labels tied to inputs, validate on blur and on submit rather than on every keystroke, and put each error message next to its field with aria describedby pointing at it plus aria invalid on the input. On submit, move focus to the first invalid field or to a summary of errors. Keep native constraints and types so mobile keyboards and autofill work, and never signal errors with color alone.

Why interviewers ask this

Forms are where accessibility failures cost real money, so this is a practical test rather than a values question. The interviewer wants to hear about programmatic association between error and field, focus management on submit, and live region behavior, all things automated tools cannot check. It also reveals whether you validate in a way that annoys users, such as showing an email error before they have finished typing it.

How to structure your answer

  • Start with native semantics: labels, input types, required.
  • Give the timing rule for when validation fires.
  • Explain the programmatic link between input and error message.
  • Describe focus handling on a failed submit.

Example answer

Spoken example, first person

I start native, because most of it comes free: a real label with a for attribute, the right input type so mobile shows the right keyboard, autocomplete attributes so password managers work, and required where it applies. For timing, I validate a field on blur and everything on submit, never on every keystroke, since telling someone their email is invalid while they are typing it is just noise. Once a field has been marked invalid I do re validate as they type, so the error clears as soon as it is fixed. Each message sits right under its input, and the input gets aria invalid true and aria describedby pointing at the message id, which is what makes a screen reader announce the error when focus lands there. On a failed submit I move focus to the first invalid field, or to a short error summary at the top with links to each field if there are several. And errors are never color only; there is text and an icon, because a red border alone means nothing to a lot of people.

Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.

See how it works

Follow-up questions to expect

  • When would you use a live region here, and when would it be annoying?
  • How would you handle a server side error that arrives after submit?
  • How do you test this without a screen reader available?

Related frontend developer questions

Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.

Predict my questions

Rehearse the hard questions before they are asked

Practise with a live copilot, then walk in ready. A $29 Session Pass gets you through the interview with no subscription and no lock-in.

Get GhostPilot