HTML Best Practices for Clean, Accessible Websites (2026 Guide)

Most bad HTML isn’t broken. It renders fine, so nobody fixes it. Then six months later you’re fighting a layout bug caused by a div soup that should have been a heading and a list, and your accessibility audit is a mess. Here’s how I actually write markup in 2026, and the specific things I flag when I review someone else’s code.

Start With Semantics, Not Styling

The single biggest improvement to any page is using the right element for the job. A button should be a <button>. A navigation block should be a <nav>. Text that introduces a section is a heading, not a bolded paragraph. This isn’t academic. Screen readers, search engines, and browser features like reader mode all depend on it.

<!-- No -->
<div class="header">
 <div class="title">Our Services</div>
 <div class="btn" onclick="submit()">Get a Quote</div>
</div>

<!-- Yes -->
<header>
 <h2>Our Services</h2>
 <button type="button">Get a Quote</button>
</header>

That clickable <div> in the “no” example can’t be focused with a keyboard, doesn’t respond to Enter or Space, and gives assistive tech nothing to announce. The <button> gets all of that for free.

Heading Levels Are a Document Outline

I still see pages that jump from <h1> to <h4> because the designer liked the size. Don’t do that. Use CSS for size and keep heading levels sequential. One <h1> per page that describes the page, then <h2> for major sections, <h3> nested under those.

If you need smaller text visually, style it. The outline should reflect meaning, not font size.

Forms: Labels, Types, and Autocomplete

Forms are where accessibility and conversion both live or die. Every input needs an associated label. Use the correct type and autocomplete so mobile keyboards and password managers do the right thing.

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

 <label for="phone">Phone (optional)</label>
 <input
 id="phone"
 name="phone"
 type="tel"
 autocomplete="tel"
 >

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

Note type="email" and type="tel". On a phone that’s the difference between a full QWERTY keyboard and one with a number pad. Small change, real effect on how many people finish the form.

Images: Dimensions, Alt Text, and Modern Formats

Layout shift is almost always images without width and height. Set both so the browser reserves the space before the image loads. Then pick the right format and let the browser choose.

<picture>
 <source srcset="hero.avif" type="image/avif">
 <source srcset="https://i0.wp.com/www.kennykey.com/hero.webp" type="image/webp">
 <img
 src="hero.jpg"
 alt="Storefront on Main Street with a red awning"
 width="1200"
 height="630"
 loading="lazy"
 decoding="async"
 >
</picture>

Alt text should describe what the image conveys. If it’s purely decorative, use alt="" so screen readers skip it. Don’t stuff keywords in there.

Accessibility Is Mostly Not Optional

If you run a business in New York, or sell to anyone in the US, accessibility has legal weight. WCAG 2.2 is the current reference, and the practical checklist is short:

• Every interactive element reachable and usable by keyboard.
• Visible focus styles. Don’t remove the outline without replacing it.
• Color contrast of at least 4.5:1 for body text.
• Labels on every form control.
• Alt text on meaningful images.

You can catch most of this with the built-in Lighthouse audit in Chrome, but automated tools only find roughly a third of issues. Tab through your own site with a keyboard. That finds the rest.

Performance Starts in the Markup

Before you touch a bundler, fix the HTML. A few habits that pay off:

• loading="lazy" on images below the fold, but not on your hero image.
• Preload the one font you actually need above the fold, and use font-display: swap.
• Don’t ship a framework for a page that’s mostly static text. Plain HTML and a bit of CSS load instantly.
• Defer scripts that aren’t needed for first paint with defer or type="module".

<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
<script src="/app.js" type="module"></script>

Validate and Test

Run your pages through the W3C validator. It catches unclosed tags and nesting errors you’ll never spot by eye. Then test the real thing: keyboard only, then a screen reader like VoiceOver or NVDA for ten minutes. It’s uncomfortable the first time and then it becomes second nature.

If you’d rather hand this off, I do this kind of cleanup all the time as part of Long Island web design work, and honestly most of it is just slowing down and using the right tag.

FAQ

Do I need to rewrite my whole site to fix bad HTML?

No. Start with your highest-traffic pages and your forms. Fix semantics, headings, and labels there first. You’ll see the biggest return without a full rebuild.

Is semantic HTML still worth it if I’m using React or another framework?

Yes, and it’s easier than people think. Frameworks render whatever tags you write. Use <button> instead of a clickable <div> and your component is accessible by default.

What’s the fastest way to check if my page is accessible?

Run Lighthouse, then unplug your mouse and tab through the page. If you can reach and use everything, and you can always see where focus is, you’re ahead of most sites.