Custom HTML5 in 2026: What Still Matters (and What Doesn’t)

Most “HTML5” advice floating around is a decade old. The spec hasn’t stood still, and neither have browsers. Here’s what actually matters if you’re hand-writing markup in 2026, and where the old advice quietly stopped being true.

I’ve been building sites by hand for a long time now, and the biggest change isn’t new tags. It’s that the browser does more of the work, which means your job shifted from “make it work” to “make it correct and fast.”

Start with a real doctype and stop worrying about it

If you’re still writing <!DOCTYPE html> and nothing else, you’re fine. That’s the whole thing. No version number, no DTD, no XML declaration above it. The old XHTML doctypes are dead weight.

<!DOCTYPE html>
<html lang="en">
<head>
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>Page title</title>
</head>
<body>
 ...
</body>
</html>

Two things people still get wrong here. First, lang on the <html> element. Screen readers use it to pick pronunciation, and translation tools use it to decide whether to offer a translation at all. Second, charset first. If <meta charset> appears after 1024 bytes of content, the browser may have already guessed wrong.

Semantic elements: use them for structure, not decoration

The HTML5 sectioning elements (header, nav, main, article, section, aside, footer) are not divs with nicer names. They carry meaning that assistive tech and search engines actually consume. The rule I use:

• <main> once per page, wrapping the unique content. Not the header, not the nav, not the footer.
• <article> for something that would make sense syndicated on its own. A blog post, a product card, a forum reply.
• <section> for a thematic grouping that has a heading. If you can’t write a heading for it, it’s probably a <div>.
• <nav> for major navigation groups. You don’t need it around every list of links.
• <div> for everything else. It’s not a dirty word.

The most common mistake I see in audits is a page with fourteen <section> elements and no headings inside them. That tells a screen reader user nothing. A plain <div> would have been more honest.

Forms got genuinely better, and most people haven’t caught up

Input types like email, tel, url, date, and number give you free mobile keyboards, free validation hooks, and free accessibility. There’s no reason to be using type="text" for an email field in 2026.

<form action="/subscribe" method="post">
 <label for="email">Email address</label>
 <input
 type="email"
 id="email"
 name="email"
 autocomplete="email"
 required
 aria-describedby="email-hint">
 <p id="email-hint">We send one email a month. No spam.</p>

 <button type="submit">Subscribe</button>
</form>

Notice the autocomplete attribute. That’s not cosmetic. Correct autocomplete tokens are one of the highest-use accessibility wins on any checkout or signup form, and they’re trivially easy to add. autocomplete="email", autocomplete="given-name", autocomplete="cc-number". The full list is in the WHATWG spec.

Also worth knowing: required and constraint validation are now reliable everywhere. You still want server-side validation, always, but you can drop a lot of JavaScript for the client side.

The <dialog> element finally replaced your modal library

This one took a while, but it’s here. Native <dialog> with showModal() gives you focus trapping, an inert background, escape-to-close, and a proper top layer. That’s the bulk of what people were pulling in 40KB of JavaScript for.

<dialog id="confirm">
 <form method="dialog">
 <p>Delete this item? This can't be undone.</p>
 <button value="cancel">Cancel</button>
 <button value="confirm">Delete</button>
 </form>
</dialog>

<script>
 const dialog = document.getElementById('confirm');
 document.querySelector('#open-btn').addEventListener('click', () => {
 dialog.showModal();
 });
 dialog.addEventListener('close', () => {
 if (dialog.returnValue === 'confirm') {
 // proceed with delete
 }
 });
</script>

The method="dialog" on the inner form is the part people miss. It closes the dialog and sets returnValue to the clicked button’s value, so you don’t have to wire up your own close handlers.

Images: still the biggest performance lever on most sites

Nothing else you do to the markup will beat getting images right. The current baseline:

<img
 src="photo-800.avif"
 srcset="photo-400.avif 400w,
 photo-800.avif 800w,
 photo-1600.avif 1600w"
 sizes="(max-width: 700px) 100vw, 800px"
 width="800"
 height="533"
 loading="lazy"
 decoding="async"
 alt="Descriptive alt text here">

Explicit width and height prevent layout shift. srcset with sizes lets the browser pick the right file. AVIF is broadly supported now, with WebP as a fallback if you need one. And loading="lazy" on below-the-fold images is free performance.

One caution: don’t lazy-load your largest contentful image (usually the hero). It delays the thing you most want to load. Use fetchpriority="high" on that one instead.

What you can stop doing

• Vendor prefixes on CSS. Autoprefixer handles this at build time; hand-writing -webkit- in 2026 is noise.
• Polyfills for HTML5 elements. The html5shiv era ended when IE died.
• Type attributes on scripts and styles. <script type="text/javascript"> and <style type="text/css"> are both defaults now. Drop them.
• Self-closing slashes on void elements. <br /> is valid but pointless. <br> is cleaner.
• Wrapper divs for layout. Grid and flexbox killed most of them. Not all, but most.

Where hand-written markup still wins

I’m not going to pretend everyone should hand-code every page. For a content site with hundreds of posts, a CMS is the right call. But there are real cases where writing the markup yourself produces a meaningfully better result:

• Marketing and landing pages where the markup is the product and every kilobyte counts.
• Custom web development projects where the design doesn’t map cleanly onto a theme or page builder.
• Performance-critical pages where you need control over exactly what loads and when.
• Accessibility-sensitive work where framework defaults get in the way more than they help.

I do most of this work from Commack, out on Long Island, and the local angle matters less than you’d think. What clients actually care about is whether the page loads fast and whether their customers can use it. The markup is how you get there.

Validate, but don’t worship the validator

Run your pages through the W3C Nu HTML Checker. It catches real mistakes: unclosed tags, duplicate IDs, misused ARIA. But a clean validation report is not the same as a good page. A page can validate perfectly and still be unusable with a keyboard. Validation is a floor, not a ceiling.

The thing I’d actually test: unplug your mouse and try to complete the primary task on your own site. That tells you more than any automated tool.

FAQ

Do I still need to write <!DOCTYPE html> in 2026?

Yes. Without it, browsers fall back to quirks mode, which changes how box sizing, line heights, and a pile of other CSS properties are calculated. It’s one line and it prevents a whole category of weird bugs.

Is HTML5 still the right term?

Not really, but everyone knows what you mean. The spec is now a living standard maintained by WHATWG, so there’s no “HTML6” coming. It just keeps getting updated. Saying “HTML” is more accurate, saying “HTML5” is more searchable.

Should I use <article> or <section> for a blog post?

<article> for the post itself, since it stands alone and could be syndicated. Use <section> inside it if you’re grouping parts of the post under their own headings. If you’re unsure, the honest answer is usually <div>.