All jobs / Frontend / web developer

HTML interview questions

HTML questions a Frontend / web developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.

1. A nav of links and a cart of line items — which HTML lists, and why not only divs?

   The strongest answer: Use nav plus a list for the links, and ul/ol for the cart, so AT can announce counts and jump by list

   Why it works: Lists are not decoration: they give count, list shortcuts, and a stable structure.

   • Lists are for listed things.
   • Nav links: nav wrapping a list.
   • Cart rows: ul/ol (or a real data table if it is tabular).
   • Don't fake layout with tables or bare spans.

2. Product photo versus a decorative divider — how do you write alt?

   The strongest answer: Describe the image's purpose (the product, not 'image'); use empty alt for decorative images

   Why it works: alt is a replacement, not a caption dump. Empty alt is correct for decoration.

   • alt describes purpose, or is empty.
   • Meaningful image: say what it is for.
   • Decorative image: alt=''.
   • Don't stuff keywords or skip the attribute.

3. The interviewer asks how you would mark up a clickable Save control that submits a form. Strongest answer?

   The strongest answer: Use a native <button type='submit'> so the form, keyboard, and assistive tech all work without extra script

   Why it works: A submit button is the control the platform already wires to Enter, forms, and the accessibility tree.

   • Prefer native controls over clickable divs.
   • Put the action in a button (type=submit) inside a form.
   • Handle the form submit event, not only a click.
   • Add ARIA only when a native element cannot do the job.

4. A sign-up form uses type=text for the email, phone and password fields.

   What do you change, and what does the user get from it?

   The strongest answer: Use type=email, tel and password with matching autocomplete values and required — the right mobile keyboard, autofill and password managers, and built-in validation; the server still validates

   Why it works: Right — the input type and autocomplete tokens are free features: keyboards, autofill, password managers. None of it replaces server-side validation.

   • Tell the browser what each field is.
   • Correct type for each input.
   • Add autocomplete tokens.
   • Validate again on the server.

5. They ask how you would structure headings on a product page with a title, a Reviews block, and a Related block. Strongest answer?

   The strongest answer: One h1 for the product, then h2s for Reviews and Related — never skip levels just to get a size

   Why it works: The heading outline is how people and tools jump the page. One h1, then honest h2s.

   • Headings describe structure, not font size.
   • One h1 for the page topic.
   • Nest h2/h3 in order; style with CSS.
   • Never hide extra headings for SEO.

6. A page has a logo, primary nav, article, and footer. How do you landmark it?

   The strongest answer: header, nav, one main, footer — plus a skip link to main; don't nest extra mains

   Why it works: Landmarks are how AT users jump regions. Native elements first, one main.

   • Use native landmarks.
   • header / nav / main / footer.
   • Exactly one main; skip link to it.
   • Don't mark every card as a landmark.

7. Product pages of a client-rendered shop show the same title in search results, and links pasted into chat apps unfurl with no image or description.

   What markup do you check and fix?

   The strongest answer: Per-page title, meta description and canonical, Open Graph tags, and structured data matching the visible content — all present in the HTML the server sends, because many previewers never run JavaScript

   Why it works: Exactly — unique head tags per URL, delivered in the first response. Link previewers and some crawlers read only that.

   • Head tags per URL, in the first response.
   • Unique title, description, canonical.
   • Open Graph plus structured data.
   • Render them on the server.