Semantic HTML

Semantic HTML uses native elements for their intended meaning so assistive technology, keyboards, and search engines get structure without extra ARIA. Landmarks (`<main>`, `<nav>`, `<header>`), heading hierarchy, `<label>` associations, and real `<button>`/`<a>` elements are the default interview answer before custom widgets.

					<main>
  <h1>Checkout</h1>
  <form>
    <label for="email">Email</label>
    <input id="email" type="email" autocomplete="email" />
    <button type="submit">Pay</button>
  </form>
</main>
				

| Element | Why it matters | |---------|----------------| | `<button>` | Built-in keyboard activation and role | | `<label for>` | Names form controls for screen readers | | Headings in order | Skipping levels confuses outline navigation | | `<nav>` | Users jump directly to navigation regions |

On interviews: when to use `<button>` vs `<a>`; why a `<div role="button">` is a last resort; how landmarks help screen-reader rotor menus.

Common pitfalls: div soup with click handlers; placeholder-only labels; multiple `<h1>` without purpose; icon-only buttons without accessible names.

The trade-off is design flexibility versus free semantics and behavior from the platform.

Checklist:

• Prefer native controls for actions and navigation.
• Associate every input with a visible label.
• Keep a logical heading outline.
• Test keyboard and screen-reader names on new UI patterns.