Semantics and Structure That Actually Help

The problem

A lot of interfaces look great on screen and terrible underneath.

You inspect them and find:

• a div pretending to be a button
• headings out of order just to get the desired font size
• an important region without main, nav, or any real structural meaning

Visually, the page can still work.

But for someone navigating through the page structure, the experience already starts broken.

And the worst part is that teams often treat this like a detail, when in practice it is foundation.

Mental model

Think about it like this:

Semantics is how HTML explains the intent of the interface before any visual makeup.

If you remove the CSS and you can still understand:

• what is navigation
• what is the main content
• what is a heading
• what is a clickable action

then the structure is healthy.

If everything turns into a pile of neutral blocks without CSS, the interface is probably leaning too hard on appearance and not enough on meaning.

Breaking it down

A native element carries meaning for free

This is one of the biggest sources of noise in frontend work.

If the action is clicking to perform something, the natural starting point is:

• <button>

If the action is navigating somewhere else, the natural starting point is:

• <a>

Replacing those with div plus manual click behavior creates extra work and usually breaks expected keyboard, focus, and assistive-technology behavior.

A heading is not just typography

Heading hierarchy is not only about visual size.

It organizes reading and navigation.

When you jump from h1 to h4 just because you liked the style, the page can still look good, but the structure becomes harder to understand for people who rely on it.

Landmarks help the page explain itself

Elements like:

• <main>
• <nav>
• <header>
• <footer>
• <section>

help the page communicate where each part starts and ends.

That does not replace clear content.

But it keeps the page from becoming one large undifferentiated block.

CSS should not carry meaning on its own

This is a common mistake.

The team uses classes, spacing, and color to make something “look like a button” or “look like a heading,” but the DOM does not support that intention.

When that happens, the meaning of the interface depends too much on the visual layer.

And that usually gets expensive in accessibility and maintenance.

Simple example

Imagine a card with the action “View details.”

A weak version looks like this:

<div onclick="openDetails()">
  View details
</div>

Visually, it can look acceptable.

Structurally, it does not clearly communicate that this is an action.

A better version starts like this:

<button type="button" onClick={openDetails}>
  View details
</button>

The gain is not “following HTML rules.”

The gain is that the browser understands this as a real button, with coherent behavior and semantics from the base.

Common mistakes

• using div for almost everything out of convenience
• choosing heading level by visual size instead of hierarchy
• letting CSS decide the meaning of the interface by itself
• trying to fix poor semantics later with patches
• treating semantic HTML like a nice-to-have instead of UI architecture

How a senior thinks

More experienced engineers usually look at the interface in layers.

Before state, animation, or polished design, they ask:

Does the DOM already prove what this interface is?

It sounds simple, but it changes the quality of the foundation a lot.

Seniority here shows up in building UI that explains itself better, needs fewer patches, and cooperates with the browser from the start.

What the interviewer wants to see

In frontend interviews, this topic reveals real maturity.

The interviewer wants to see whether you:

• treat the DOM as structure, not just as a surface for CSS
• choose the element based on functional role
• understand that accessibility starts early
• avoid patching when the problem is really structural

A strong answer often sounds like this:

Before I think about ARIA or fine-tuning, I want to guarantee that the HTML already represents the real intent of the interface. If it is an action, I use an action element. If it is navigation, I use a navigation element. If the structure cannot explain itself without CSS, the accessibility foundation already started weak.

Accessibility starts in the structure, not in the patch.

HTML without clear intent becomes hidden cost for the rest of the frontend.