The 10 Elements You’re Probably Misusing in HTML (and Why It Matters)

HTML looks simple. That’s the trap. You write a few tags, refresh the browser, and things appear. But years later, you realize: that messy, semantically empty markup you wrote for a quick prototype? It became the foundation of an app serving 30,000 people a day.

I’ve inherited codebases where everything was a <div>. I’ve seen buttons that weren’t buttons, headings that weren’t headings, and links that didn’t link anywhere. These aren’t rookie mistakes — they’re habits. And the longer we let them slide, the more they cost us.

So here are 10 HTML elements I see misused constantly — and what I tell teams to do instead.

1. <div>

It’s not wrong to use a <div>. It’s wrong when everything is a div. If your page outline looks like div soup, you’re not using HTML — you’re stacking boxes.

Use instead: <section>, <article>, <nav>, <aside>, or <main> when the content carries meaning.

2. <span>

This is an inline container, not a layout tool. If you’re putting spans inside spans to pad things or space things visually, you’re fighting the language.

Use it for: styling a word or two. Nothing structural.

3. <b> and <i>

Bold and italic look useful, but they say nothing to assistive tech.

Use instead: <strong> for importance, and <em> for emphasis. They work with screen readers — and humans who rely on them.

4. <h1> to <h6>

Headings give your content shape. Skipping levels or using them for size-only styling (instead of structure) creates chaos.

Rule of thumb: Nest headings logically. If your page outline doesn’t read like a table of contents, you’re doing it wrong.

5. <a>

No href? It’s not a link. If you’re using <a> to trigger JavaScript actions, rethink it. That’s what buttons are for.

Use <a> for navigation. Use <button> for in-page actions.

6. <button>

A button with no label is a black hole for screen readers. If your button relies on icons or empty content, add aria-label or inner text.

Don’t do: <button></button>
Do: <button aria-label="Close modal"></button>

7. <form> and <label>

Placeholders are not labels. And a form without labels might look good — until you try to use it with a screen reader, or three months from now when you forget what each field does.

Pair every input with a proper, connected <label>. No exceptions.

8. <img>

No alt? That’s an accessibility failure. And alt="image" doesn’t help anyone.

If it’s decorative: alt="".
If it has meaning: Describe it. Clearly. Thoughtfully.

9. <table>

Tables are for data. Not for layout. Still see this? You’ll also see devs tearing their hair out trying to make responsive hacks work later.

Use tables for: structured data with column/row logic. Not pixel-perfect layouts.

10. <script>

Inline scripts that block rendering? Brutal. Add defer or async so the browser can load intelligently.

Fix it with: <script src="file.js" defer></script>

The Bigger Picture

HTML isn’t just code. It’s communication. Between you and your team. Between your site and a browser. Between your content and someone using assistive tech at 11pm with slow internet.

Write like someone will inherit your code tomorrow. Because they will. Maybe it’ll even be you.

Want help reviewing your markup or leveling up your team’s HTML habits? Contact me here and I’ll walk you through the cleanup — and build smarter from the start.

What Makes a Good Heading Hierarchy in HTML?

A client once asked me why their beautifully designed landing page was tanking in SEO and frustrating users. The answer wasn’t the layout, the copy, or even the speed. It was the headings. Three <h1>s. No logical order. Just styled text made to look bold. Screen readers were lost. Search engines were confused. And users? They bounced.

This is why heading hierarchy matters. It’s not just for visual flair — it’s the scaffolding of meaning on your page.

What Is Heading Hierarchy?

HTML gives us six levels of headings: <h1> through <h6>. These aren’t just different font sizes — they describe the structure of your content.

  • <h1> — The main title of the entire page (use only once)
  • <h2> — Major sections under the main title
  • <h3> — Subsections of an <h2>
  • <h4>, <h5>, <h6> — Further nesting if needed

Think of it like writing a book. The <h1> is your book title. <h2> tags are chapter headings. <h3> introduces subheadings within those chapters. When you break this logic, you confuse your readers — and machines, too.

Why It Actually Matters

  • Accessibility: Screen readers rely on headings to provide a table of contents and let users jump between sections efficiently.
  • SEO: Search engines use headings to understand what your content is about and how it’s organized.
  • Skimmability: Human readers scan. Headings guide the eye and help people find what matters fast.

Real-World Example

Here’s a clean, semantic structure for a typical blog post:

<article>
  <h1>How to Work Remotely Like a Pro</h1>

  <section>
    <h2>Setting Up Your Environment</h2>
    <p>...</p>
  </section>

  <section>
    <h2>Mastering Communication</h2>
    <h3>Video Call Etiquette</h3>
    <h3>Asynchronous Updates</h3>
    <p>...</p>
  </section>
</article>

With styling turned off, this still reads like a structured outline. That’s what good markup should do.

Common Mistakes I See

  • Multiple <h1>s: There should only be one true main heading per page.
  • Skipping levels: Going from <h2> to <h5> because it “looks smaller” breaks logic.
  • Using headings for styling: Headings aren’t just big text. Use CSS for appearance. Use headings for structure.
  • No headings at all: Some devs use <div>s with classes like “title” — but that means nothing to assistive tech.

Helpful Tools to Check Your Work

  • HTML5 Outliner — See your document’s structure as a screen reader would.
  • Reader Mode: Try Firefox or Safari’s “Reader View.” What shows up first? That’s your hierarchy in action.
  • WAVE Tool: A browser extension that flags heading misuse and accessibility issues.

My Personal Approach

Before I touch any CSS, I write out the content structure in plain HTML. No classes. No layout. Just semantic blocks. If I can read only the headings and still understand the page, it passes. If not, I rethink the outline.

This isn’t a style preference. It’s a strategy. Good heading hierarchy protects your project from future confusion, improves usability, and helps teams work together with confidence.

Still unsure if your headings are doing their job? Contact me here and I’ll walk through it with you — or help you fix it hands-on.