Semantic HTML Is an Accessibility Feature, Not a Formality

Two pages can render pixel-for-pixel identically and be built from completely different underlying HTML — one using elements chosen for what they actually mean (<nav>, <button>, <article>, <h2>), the other built almost entirely from generic <div>s and <span>s styled to look the part. Visually, no difference. For anyone using assistive technology, the gap between those two pages is enormous.

What semantic elements give you for free

A <nav> element tells a screen reader "this is a navigation landmark" — letting a user jump directly to it, or skip past it, using landmark navigation rather than reading through every single link linearly. A <button> is keyboard-operable and correctly announced as a button with zero additional code. A properly nested heading hierarchy (<h1> through <h6>, used for actual document structure rather than font-size shortcuts) lets a screen reader user pull up a list of headings and jump straight to the section they want — a navigation pattern many screen reader users rely on constantly, the way a sighted user might scan a page visually for the section they're looking for.

None of this requires ARIA, JavaScript, or extra markup — it's the default, built-in behavior of choosing the HTML element that actually matches what the content is, instead of a generic container styled to merely look like it.

Where "div soup" comes from

This isn't usually a deliberate choice — it accumulates from a few common habits: a design tool (Figma, Sketch) exports layers with no inherent semantic meaning, and a literal-minded implementation just wraps each layer in a <div>; a component library's default examples use generic containers and a real implementation never revisits that; or a fear of fighting default browser styling on semantic elements (a <button>'s default appearance, for instance) leads to reaching for a <div> with a click handler instead, on the assumption it'll be easier to style — when in practice, resetting a button's default styles takes a few lines of CSS and keeps everything else it provides for free.

The fix costs less than it seems

Swapping a clickable <div> for an actual <button>, or a series of styled text blocks for actual <h2>/<h3> tags, is almost always a small, low-risk change — same visual output, same CSS in most cases, dramatically different experience for anyone navigating by structure rather than by sight. It's one of the highest-leverage accessibility fixes available, precisely because it's not really "extra work" — it's using the tool that already exists for the job, instead of reconstructing a worse version of it from generic parts. MarketMan's accessibility scan catches the missing labels and roles that div-soup markup produces, and its SEO audit flags the broken heading structure.