Question 1

Why should every input have a <label>?

Accepted Answer

Labels give accessible names and enlarge click/tap targets. Associate with for/id or wrap the control. Placeholder is not a label. Visible labels survive autofill and translation better.

Question 2

What does the required attribute do vs JavaScript validation?

Accepted Answer

required participates in native constraint validation; JS can add custom rules and UX. Native validation is progressive and works without JS, but messaging/styling is limited. Combine both carefully; don't disable native without replacement.

Question 3

Explain name vs id on form controls.

Accepted Answer

id is unique for labels/anchors; name is the key submitted in form data. Multiple radios share a name. id must be unique in the document. Missing name means the field won't submit.

Question 4

How do fieldset and legend improve forms?

Accepted Answer

They group related controls and name the group for AT. Ideal for radio sets and address blocks. Don't nest fieldsets excessively. Legend should be concise.

Question 5

What is autocomplete and why does it matter?

Accepted Answer

Hints browsers/password managers how to fill fields (email, current-password, etc.). Correct tokens improve conversion and security (password managers). Wrong tokens frustrate users and cause autofill bugs.

Question 6

How does constraint validation API work?

Accepted Answer

checkValidity/reportValidity and setCustomValidity integrate with :valid/:invalid. Listen to invalid events. Custom messages must be cleared when fixed. Useful for cross-field rules.

Question 7

When do you choose GET vs POST for forms?

Accepted Answer

GET for idempotent safe queries; POST for mutations or sensitive/large payloads. GET puts data in the URL (history, logs, length limits). POST for login, checkout, uploads.

Question 8

How do you build an accessible multi-step form?

Accepted Answer

One logical form or wizard with clear step status, preserved data, and focus management per step. Announce step changes. Don't lose entered data. Validate per step and summarize errors before submit.

Question 9

What are the risks of disabling native form submit?

Accepted Answer

You may break Enter-to-submit, progressive enhancement, and password manager flows. If using preventDefault, reimplement keyboard submit and validation thoroughly.

Question 10

Explain input types email, tel, url, number — benefits and pitfalls.

Accepted Answer

They change mobile keyboards and enable native validation, but number has quirks for IDs/Zips. Use text + inputmode when spin buttons or scientific notation hurt UX. Pattern can refine validation.

Question 11

How should file inputs be labeled and constrained?

Accepted Answer

Visible label, accept for hints, server-side validation always; multiple when needed. accept is not security. Show selected filenames. Consider drag-drop as enhancement only.

Question 12

What is enctype multipart/form-data and when is it required?

Accepted Answer

Required for file uploads so binary parts are encoded correctly. Default urlencoded is fine for text fields. JSON APIs often bypass classic enctypes via fetch.

Question 13

Design a form system API for a design system team.

Accepted Answer

Composable Field, Label, Hint, Error with consistent ids, describedby wiring, and tokens. Centralize a11y contracts so product teams can't ship unlabeled inputs. Document validation patterns.

Forms HTML Interview Questions

Other HTML interview topics