Semantic HTMLAccessibilityWeb Standardsjunior level

Semantic HTML Gives the Page Meaning

the question

What is semantic HTML, and why is it important for accessibility and maintainability?

what they're testing: The interviewer is probing whether you choose elements by meaning and understand the browser behavior and accessibility information that choice provides.

a strong answer

Semantic HTML means choosing elements for what they mean, not how they look. Use a <button> for an action, an <a> for navigation, and real headings for sections. Those choices tell the browser what each part of the interface is. The browser can then expose roles, relationships, and landmarks to assistive technology.

That meaning changes how people can use the page. Screen-reader users can jump by heading or landmark, and native controls arrive with expected behavior. A <button> participates in keyboard focus and responds to the standard activation keys. A clickable <div> may look identical after CSS, but it is still a generic container unless you recreate its semantics and interaction behavior.

Semantics also make markup easier for another developer to read and give tools such as search engines and reader modes useful structure. This does not mean replacing every <div> with <section>. Use the element whose meaning matches the content; a generic container is correct when no semantic element fits. Semantic HTML is the accessible baseline, not a complete accessibility strategy. Labels, text alternatives, focus handling, contrast, and testing still matter.

Where people slip

the tempting wrong answer, and what's actually true

Semantic HTML just means replacing every `<div>` with `<header>`, `<section>`, or `<article>`.
Semantic HTML includes controls, headings, lists, tables, and text-level elements, while `<div>` remains appropriate when no meaningful element fits.
A styled, clickable `<div>` is equivalent to a native `<button>`.
CSS can copy the appearance, but a `<div>` does not gain the button's native role, focusability, or keyboard behavior.
Adding `role="button"` gives a `<div>` all the behavior of a native button.
The role supplies accessibility semantics, but the author must still implement the expected focus and keyboard interactions.

If they push further

When should you use a `<div>` instead of a semantic element?

Use a `<div>` for grouping or styling when no element describes the content's meaning; it is a valid generic container, not an element to ban.

Can ARIA replace semantic HTML?

Prefer a native element when one matches the job. ARIA can add missing semantics for custom widgets, but a role does not add the native keyboard behavior.

Does semantic HTML make a page accessible by itself?

No. It provides a strong structural baseline, but accessible names, text alternatives, focus behavior, contrast, and testing still need attention.

Sources

Now answer it yourself.

Reading a strong answer is easy. Producing one under pressure is the skill the interview tests. Gapmap grades your answer against the same bar an interviewer would.

was this useful?

beta

The interviewer part is in the works.

The diagnostic, personal maps, and AI mock interviews are being finished right now. The notes stay free either way. Leave an email and you'll get the first-cohort invite, plus a month of Pro when it opens.