HTML Basics That Still Matter in 2026 (and the Ones That Don’t)

Most HTML advice online is either a 2014 tutorial or a listicle written by someone who has never shipped a site. I’ve been writing markup for a living for a long time, and the fundamentals haven’t changed nearly as much as people claim. What has changed is which parts actually matter for search engines, screen readers, and the poor developer who inherits your code next year.

Here’s what I’d tell anyone building pages in 2026, whether it’s a small business site or a web app.

Use semantic tags because browsers and assistive tech rely on them

The <div> soup era is over, or at least it should be. Modern browsers expose an accessibility tree built from your markup. If everything is a div, that tree is empty, and screen readers have to guess. Google’s crawlers also parse structure, not just text.

This is bad:

<div class="header">
 <div class="nav">...</div>
</div>
<div class="main">
 <div class="article">
 <div class="title">My Post</div>
 </div>
</div>

This is what you want:

<header>
 <nav aria-label="Main">...</nav>
</header>
<main>
 <article>
 <h1>My Post</h1>
 </article>
</main>

The second version gives you landmarks, a logical heading outline, and free keyboard navigation in most browsers. You don’t need a framework for any of it.

One h1 per page, and a heading order that makes sense

I still see pages with four <h1> tags and headings chosen by font size instead of hierarchy. The rule is simple: one <h1> that describes the page, then <h2> for major sections, <h3> for subsections. Don’t skip levels to get smaller text. Use CSS for that.

This matters more than people think. Screen reader users jump between headings constantly. So do search crawlers, and so do humans skimming a long page.

Native elements beat ARIA almost every time

The first rule of ARIA is don’t use ARIA. A <button> gets keyboard focus, Enter and Space activation, and the correct role for free. A div with role="button" gets none of that unless you write the JavaScript yourself, and most people forget the Space key.

<!-- Don't do this -->
<div role="button" tabindex="0" onclick="submit()">Submit</div>

<!-- Do this -->
<button type="submit">Submit</button>

Same story with <details> and <summary> for accordions, and <dialog> for modals. The dialog element is well supported now and handles focus trapping and the backdrop for you. If you’re still shipping a custom modal library, take a look at what the platform gives you.

Images: width, height, and lazy loading

Layout shift is a ranking and a UX problem, and it’s mostly self-inflicted. Always set intrinsic dimensions on images so the browser can reserve space before the file loads.

<img src="hero.avif"
 alt="Storefront on Main Street"
 width="1200" height="630"
 loading="lazy" decoding="async">

Skip loading="lazy" on your hero image or anything above the fold. Lazy loading the largest contentful paint image is a common self-own. And write alt text that describes the image, or use alt="" for purely decorative images. Don’t stuff keywords in there.

Forms in 2026 are much better than they used to be

You can get free client-side validation, the right mobile keyboard, and autofill hints without a line of JavaScript.

<form action="/subscribe" method="post">
 <label for="email">Email address</label>
 <input id="email"
 name="email"
 type="email"
 autocomplete="email"
 required>
 <button>Subscribe</button>
</form>

That type="email" gives you a keyboard with an @ sign on phones and basic format checking. autocomplete="email" lets password managers and browsers fill it in. The label being tied to the input with for means clicking the text focuses the field and screen readers announce it correctly. None of this is new, but a shocking number of forms still get it wrong.

What you can stop worrying about

• XHTML self-closing syntax. <br /> and <br> both work. Pick one and move on.
• Table-based layouts. Unless you’re building an actual email, tables are for tabular data only.
• Meta keywords. Ignored by every major search engine for well over a decade.
• Pixel-perfect font stacks. Use system fonts or a variable font and stop shipping five weights you don’t use.

Where this fits into real projects

Clean HTML is the cheapest performance and accessibility win you can get, and it’s the part of the stack that outlives every framework you’ll adopt. I’ve rebuilt enough sites on Long Island and elsewhere to know that the markup is usually the last thing anyone audits and the first thing that causes problems. If you’re planning a rebuild or want a second set of eyes on what you already have, my custom web development work covers the whole stack, but it always starts here.

If you take one thing from this: write markup that means something. Everything downstream, from search to screen readers to the next developer, depends on it.

FAQ

Do I still need to worry about HTML if I use React or Next.js?

Yes, more than ever. JSX compiles down to HTML, and if you write divs everywhere, your rendered output is divs everywhere. Frameworks don’t fix bad markup, they just make it harder to see.

Is semantic HTML actually a ranking factor?

Not directly as a named signal. It matters indirectly: it improves accessibility, page structure, and how well crawlers understand your content, and heading structure and alt text both feed into how pages get indexed.

How do I check if my HTML is any good?

Run the W3C validator, then open the page with a screen reader or just tab through it with the keyboard. If you can reach and use everything without a mouse, you’re ahead of most sites.