Interviewfrage für Frontend-Entwickler

Wie würdest du ein Signup-Formular bauen, dessen Validierungsfehler wirklich brauchbar sind, auch für Screenreader-Nutzer?

Worauf der Interviewer abzielt, wie du deine Antwort aufbaust und ein gesprochenes Beispiel zum Anpassen.

Kurzantwort

Nutz echte Labels, die an die Inputs gebunden sind, validier bei blur und beim Absenden statt bei jedem Tastendruck, und setz jede Fehlermeldung neben ihr Feld, mit aria-describedby darauf zeigend plus aria-invalid auf dem Input. Beim Absenden verschieb den Fokus auf das erste ungültige Feld oder auf eine Fehlerzusammenfassung. Behalt native Constraints und Typen, damit Mobiltastaturen und Autofill funktionieren, und signalisier Fehler nie allein über Farbe.

Warum Interviewer das fragen

Formulare sind der Ort, an dem Barrierefreiheitsfehler echtes Geld kosten, das ist also ein praktischer Test und keine Wertefrage. Der Interviewer will von der programmatischen Verbindung zwischen Fehler und Feld hören, vom Fokusmanagement beim Absenden und vom Verhalten von Live Regions, alles Dinge, die automatische Tools nicht prüfen können. Es zeigt außerdem, ob du so validierst, dass es Nutzer nervt, etwa indem du einen E-Mail-Fehler zeigst, bevor sie fertig getippt haben.

So baust du deine Antwort auf

  • Fang bei nativer Semantik an: Labels, Input-Typen, required.
  • Nenn die Timing-Regel, wann die Validierung feuert.
  • Erklär die programmatische Verbindung zwischen Input und Fehlermeldung.
  • Beschreib die Fokusbehandlung bei einem fehlgeschlagenen Absenden.

Beispielantwort

Gesprochenes Beispiel, erste Person

Ich fange nativ an, weil das meiste dann gratis kommt: ein echtes label mit for-Attribut, der richtige Input-Typ, damit Mobil die passende Tastatur zeigt, autocomplete-Attribute, damit Passwortmanager funktionieren, und required, wo es zutrifft. Beim Timing validiere ich ein Feld bei blur und alles beim Absenden, nie bei jedem Tastendruck, denn jemandem zu sagen, seine E-Mail sei ungültig, während er sie tippt, ist einfach nur Lärm. Sobald ein Feld als ungültig markiert ist, validiere ich beim Tippen allerdings schon nach, damit der Fehler verschwindet, sobald er behoben ist. Jede Meldung sitzt direkt unter ihrem Input, und das Input bekommt aria-invalid true und aria-describedby auf die Id der Meldung, und genau das sorgt dafür, dass ein Screenreader den Fehler ansagt, wenn der Fokus dort landet. Bei einem fehlgeschlagenen Absenden setze ich den Fokus auf das erste ungültige Feld, oder auf eine kurze Fehlerzusammenfassung oben mit Links zu den Feldern, falls es mehrere sind. Und Fehler sind nie nur farbig; es gibt Text und ein Icon, denn ein roter Rahmen allein bedeutet für viele Menschen gar nichts.

Steht dieses Vorstellungsgespräch bald an? GhostPilot hört bei deinem Live-Call mit, erkennt die Frage in dem Moment, in dem sie gestellt wird, und bringt dir eine strukturierte Antwort in Echtzeit auf den Bildschirm. Probier es im nächsten Mock aus, oder hol dir einen $29 Session Pass, kein Abo, für den Ernstfall.

So funktioniert es

Nachfragen, mit denen du rechnen solltest

  • Wann würdest du hier eine Live Region nutzen, und wann wäre sie nervig?
  • Wie würdest du einen serverseitigen Fehler behandeln, der nach dem Absenden eintrifft?
  • Wie testest du das, wenn kein Screenreader verfügbar ist?

Weitere Fragen für Frontend-Entwickler

Dein Interviewer stellt seine eigene Version davon. Kopier deine echte Stellenbeschreibung in den kostenlosen Question Predictor und bekomm die 20 Fragen, die diese Rolle am wahrscheinlichsten stellt, samt dem, worauf jede wirklich abzielt.

Meine Fragen vorhersagen

Üb die harten Fragen, bevor sie gestellt werden

Trainier mit einem Live-Copiloten und geh dann vorbereitet rein. Ein $29 Session Pass bringt dich durch das Vorstellungsgespräch, ohne Abo und ohne Bindung.

GhostPilot holen