What is semantic HTML and why does it matter for accessibility?

HTMLAccessibilityJioCinema

The short answer

Semantic HTML means using HTML elements that describe the meaning of the content, not just how it looks. Instead of using <div> and <span> for everything, you use elements like <header>, <nav>, <main>, and <button> that tell the browser and assistive technologies what the content actually is. This makes your page accessible, better for SEO, and easier to maintain.

What makes HTML "semantic"

Every HTML element carries a meaning. Some elements describe their content clearly — these are semantic. Others are generic containers with no meaning — these are non-semantic.

<!-- Non-semantic — a div means nothing -->
<div class="header">
  <div class="nav">
    <div class="nav-item" onclick="goHome()">Home</div>
  </div>
</div>
<!-- Semantic — each element describes its role -->
<header>
  <nav>
    <a href="/">Home</a>
  </nav>
</header>

Both examples can look exactly the same on screen with the right CSS. But to a screen reader, they are completely different. The first one is just a bunch of boxes. The second one tells the screen reader "this is a header with navigation containing a link." A blind user can jump directly to the navigation or skip it entirely.

Common semantic elements

Here are the elements you should be reaching for instead of <div>:

  • <header> — introductory content or navigation at the top
  • <nav> — a group of navigation links
  • <main> — the primary content of the page (only one per page)
  • <article> — a self-contained piece of content (blog post, comment, card)
  • <section> — a thematic group of content with a heading
  • <aside> — content related to the main content but separate (sidebar, callout)
  • <footer> — concluding content at the bottom
  • <figure> and <figcaption> — an image or diagram with a caption
  • <time> — a date or time value

And for interactive elements, always use the right element:

  • <button> instead of <div onclick="...">
  • <a> instead of <span onclick="...">
  • <input> with <label> instead of a <div> with a placeholder

Why semantic HTML matters for accessibility

This is the part most candidates miss. Semantic HTML is not just about clean code — it directly affects whether people can use your website.

Screen reader navigation: Screen readers use semantic elements as landmarks. A user can press a shortcut key to jump to <nav>, skip to <main>, or move between <article> elements. With only <div> elements, they have to listen to the entire page from top to bottom.

Keyboard accessibility: Elements like <button> and <a> are focusable and operable by keyboard by default. They respond to Enter and Space keys. A <div> with an onclick does none of this — you would need to manually add tabindex, role, and keyboard event handlers.

<!-- This works with keyboard out of the box -->
<button onclick="save()">Save</button>
<!-- This does NOT work with keyboard -->
<div onclick="save()">Save</div>
<!-- To make the div work, you need all of this -->
<div
  onclick="save()"
  role="button"
  tabindex="0"
  onkeydown="if(event.key === 'Enter') save()"
>
  Save
</div>

The <button> gives you all of that behavior for free. The <div> approach is more code, more fragile, and easy to get wrong.

Reduces ARIA dependence: ARIA attributes (role, aria-label, aria-describedby) exist to add meaning to non-semantic elements. But if you use semantic HTML, you rarely need ARIA at all. The first rule of ARIA is literally "don't use ARIA if you can use a native HTML element instead."

<!-- Using ARIA because we used a div -->
<div role="button" aria-label="Close dialog">X</div>
<!-- No ARIA needed — the element speaks for itself -->
<button aria-label="Close dialog">X</button>

Form accessibility: Using <label> with <input> creates a connection that screen readers announce automatically. It also makes the label clickable, which increases the click target area — helpful for everyone, especially on mobile.

<!-- Good — label is connected to input -->
<label for="email">Email</label>
<input id="email" type="email" />
<!-- Bad — no connection, screen reader cannot associate them -->
<div>Email</div>
<input type="email" />

Common Pitfalls

A very common mistake candidates make is building interactive elements with <div> and <span> instead of using <button> and <a>. It might look the same visually, but it breaks keyboard navigation and screen reader support. If something is clickable, it should be a <button> (for actions) or <a> (for navigation). Interviewers notice this immediately, especially at companies that care about accessibility.

SEO benefits

Search engines use semantic HTML to understand your page structure. A <h1> inside an <article> inside <main> tells Google "this is the main heading of the primary content." A <div class="title"> inside a <div class="content"> tells Google nothing.

Using semantic elements correctly helps search engines:

  • Identify the main content vs navigation vs sidebar
  • Understand content hierarchy through proper heading levels (<h1> through <h6>)
  • Find navigation structure for sitelinks
  • Extract dates from <time> elements

Interview Tip

When answering this question, do not just list the semantic elements. Explain the impact. Talk about how using a <div> as a button breaks keyboard access, how screen readers use landmarks to navigate, and how semantic HTML reduces the need for ARIA. Showing that you understand the real-world consequences — not just the theory — tells the interviewer you build inclusive products.

Why interviewers ask this

Semantic HTML questions test whether you think beyond visual output. Many developers write code that looks right on screen but is completely broken for keyboard and screen reader users. Interviewers ask this to gauge whether you understand web accessibility fundamentals, whether you would build a clickable element with a <div> or a <button>, and whether you can write HTML that works for everyone. At companies building products used by millions, accessibility is not optional — it is a requirement.

Table of Contents