Skip to content
tezvyn:

Semantic HTML: Use the Right Element for the Job

Source: developer.mozilla.orgMediumHow cards are made

Semantic HTML: Use the Right Element for the Job

Think of HTML tags as pre-built components, not just style containers. Using <button> instead of a styled <div> gives you keyboard navigation and screen reader support for free. The biggest mistake is using generic <div>s for interactive elements.

Why it exists

Browsers need to understand the meaning and structure of your content, not just how it looks. Without semantic clues, a screen reader can't tell a heading from a paragraph, a search engine can't weigh the importance of text, and a user can't navigate with a keyboard. Semantic HTML provides this essential structure, making content universally understandable.

The mental model

Think of HTML elements as specialized tools, not just generic boxes. A <button> is a pre-built button with click handling and keyboard focus built-in. A is just an empty box. Using the right tool for the job saves you from having to build the tool's features from scratch using CSS and JavaScript.

How it works

When you use a semantic element like <button>, <nav>, or <h1>, the browser automatically applies accessibility roles and properties. For example, a <button> is focusable by default (you can Tab to it) and can be activated with the Enter or Space key. A styled has none of this behavior. The browser uses this structure to build an "accessibility tree," which screen readers and other assistive technologies use to interpret and navigate the page.

When to use it

Always. From the very start of a project, choose elements based on their meaning. Use <nav> for navigation blocks, <main> for the primary content, <article> for self-contained pieces, and <h1> through <h6> for a logical document outline. Use <button> for actions and for navigation links. This practice not only aids accessibility but also improves SEO and makes the codebase easier for other developers to understand.

When not to use it

There are very few reasons to avoid semantic HTML. The main valid use for non-semantic elements like and is for purely presentational grouping when no other element fits the meaning. For example, use a to group a set of elements together so you can apply a single CSS style, like a background color or a border.

One canonical example

A common mistake is creating a button from a . Bad: Click Me This looks like a button but isn't keyboard accessible, and screen readers won't announce it as a button. It's invisible to many users. Good: <button>Click Me</button> This version is automatically focusable with the Tab key, can be activated with Enter or Space, and is announced as a "button" by assistive technologies, all for free.

Interview question

What is the primary benefit of using a <button> element instead of a styled <div> for an interactive click action?

  • a.It automatically includes pre-defined JavaScript event listeners for common interactions.
  • b.It inherently provides accessibility features such as keyboard navigation and screen reader support.Correct
  • c.It ensures the button's visual appearance is consistent across all web browsers.
  • d.It makes the HTML code shorter and easier to write for developers.
Why?

The card emphasizes that a <button> element automatically provides keyboard focus, activation via Enter/Space, and is announced by screen readers, features a styled <div> lacks. While other options might seem plausible, they are not the primary, inherent benefit of semantic elements for interactive components.

Just read this? Test yourself on what you have been reading.

Read the original → developer.mozilla.org

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on html — each one lists the topics its interview covers.

See open roles