HTML Interview Questions
Commonly asked HTML interview questions with clear, practical answers.
A curated set of HTML interview questions — the kind that come up in real front-end screens, from fundamentals through accessibility.
Fundamentals
Q: What are the benefits of semantic HTML?
It gives meaning to markup instead of relying purely on generic <div>s: screen readers can build a landmark-based navigation structure (<nav>, <main>, <footer>) so assistive technology users can jump directly to the part of the page they need, search engines can better understand page structure and content importance for ranking, and other developers (or your future self) can read the markup and immediately understand the page's structure without inspecting CSS classes.
Q: What's the difference between a block-level element and an inline element?
A block-level element (<div>, <p>, <h1>, <section>) always starts on a new line and takes up the full available width by default, and accepts width/height/margin/padding on all sides. An inline element (<span>, <a>, <strong>) flows within the surrounding text, only takes up as much width as its content, and ignores top/bottom margin and explicit width/height. inline-block is a hybrid: it flows inline like text but accepts box-model sizing like a block element.
Q: What's the difference between <div> and a semantic element like <section> or <article>?
Visually, nothing — both are generic containers with no default styling beyond display: block. The difference is entirely in meaning: <section>/<article> communicate to browsers, assistive technology, and search engines that the content has a specific structural role, while <div> communicates nothing beyond "this is a box." Use <div> only when a wrapper is purely for styling/scripting and carries no inherent semantic meaning.
Accessibility
Q: Why is the alt attribute on <img> important?
It provides a text alternative for the image — read aloud by screen readers, shown if the image fails to load, and indexed by search engines (image search relies heavily on alt text). A purely decorative image should use alt="" (empty, not omitted) so screen readers skip it entirely rather than announcing an unhelpful filename.
Q: How do you make a custom clickable <div> accessible, and why is that usually the wrong approach?
You'd need role="button", tabindex="0" to make it focusable, and JavaScript key handlers for Enter/Space since a <div> has none of that built in — and you'd still likely miss edge cases a native element handles for free. The better approach in almost every case is to just use a real <button>, which is keyboard-accessible, focusable, and correctly announced by screen readers with zero extra code.
Forms & structure
Q: Why should every form input have an associated <label>?
Because it gives assistive technology a name to announce when the input receives focus — without it, a screen reader user hears only "edit text" with no indication of what the field is for. It also expands the clickable/tappable target for sighted users, since clicking a label focuses its associated input.
Q: What happens if you don't include <!DOCTYPE html> at the top of a page?
Some browsers can fall back into "quirks mode," an older, less standards-compliant rendering mode with inconsistent box-model and layout behavior left over from the pre-CSS-standardization era of the web. Always including <!DOCTYPE html> as the very first line guarantees the browser uses modern standards mode.
Accessibility, SEO & modern HTML
Q: When should you reach for an ARIA attribute instead of just using more semantic HTML, and how would you trap keyboard focus inside an open modal dialog?
Reach for ARIA only when a native element genuinely can't express what you need — a custom tab panel, combobox, or modal has no direct HTML equivalent, so its role and state have to be described explicitly (role="dialog", aria-expanded, and so on). For focus trapping specifically: move focus into the dialog when it opens, listen for Tab/Shift+Tab and call event.preventDefault() to wrap focus back around when it would otherwise leave the last (or first) focusable element, and restore focus to whatever triggered the dialog when it closes — without that, a keyboard user is left with focus on a hidden or removed element.
Q: What's the purpose of a canonical URL, and how does it differ from what Open Graph tags do?
A canonical <link> tells search engines which URL is the authoritative version of a page's content when the same content is reachable through several URLs (with/without a trailing slash, with tracking parameters, via a redirect), consolidating ranking signals onto one URL instead of splitting them across near-duplicates. Open Graph tags solve an unrelated problem — controlling how a URL renders as a social preview card (title, description, thumbnail) — and have no direct effect on search ranking at all.
Q: What problem do Web Components solve that plain CSS classes and JavaScript modules don't? Genuine encapsulation — a Shadow DOM subtree's internal markup and styles can't leak out to the rest of the page, and the page's own global CSS can't reach in and restyle it either, short of a few deliberate escape hatches. A disciplined naming convention like BEM reduces class collisions but doesn't prevent them; Shadow DOM makes collisions structurally impossible, which matters most for a component meant to be dropped into many different, unrelated codebases.