What Is Div Soup? (And Why Everyone's Building It)
"Div soup" is a term for websites built with <div> tags instead of semantic HTML. A navigation is a <div> with JavaScript click handlers, not a <nav>. A button is a <div> styled with CSS, not a <button>. Headings are <span> tags with large font sizes, not <h1> through <h6>. These websites look beautiful. They pass design reviews. They impress stakeholders at presentations. But they're broken in ways that cost companies millions of dollars in lost revenue, remediation expenses, and litigation risk. Let's break down what "pretty but broken" actually costs.
Why Div Soup Happens
Div soup happens when developers use <div> tags as generic containers and then layer on JavaScript and CSS to make them behave like proper HTML elements. Example of div soup: <div class="nav-button" onclick="submitForm()"> <span class="button-text">Submit</span> </div> Example of semantic HTML: <button type="submit">Submit</button> The button version works with: The div version requires JavaScript for all of this. And if that JavaScript fails (connection issues, browser incompatibility, old device), the button doesn't work at all. Why do developers build div soup? But div soup has costs. Lots of them.
Keyboards (Enter and Space trigger submission)
Screen readers (announced as a button)
Mobile voice control (recognized as interactive)
Assistive technology (proper semantics)
Browsers (built-in form submission)
Search engines (understood as an action)
Design freedom: A <div> is a blank canvas. It looks like you have infinite styling options.
Framework habits: Modern SPA frameworks (React, Vue, Angular) often abstract away semantic HTML in favor of components.
Inexperience: Developers who've never worked with semantic HTML don't know what they're missing.
Design tools: Figma exports often produce divs, not semantic HTML.
Misguided optimization: Some developers think less HTML = faster loading. (It's the opposite.)
Cost #1: Development Time and Maintenance
Building interactive elements with divs takes more code. More code means more bugs. More bugs mean more maintenance. Semantic HTML button: Div soup button: On a typical website with 20-50 interactive elements, this adds up fast: And that's just the initial build. Div soup is harder to maintain: Lifetime maintenance cost for div soup: +$10,000-$30,000 per year
HTML: 1 line (<button>Submit</button>)
JavaScript: 0 lines (built-in form submission)
CSS: 2-5 lines (styling)
Total: ~1 day to ship a polished button
HTML: 3-5 lines (nested divs/spans)
JavaScript: 15-30 lines (click handler, keyboard support, focus management, hover states)
CSS: 20-50 lines (styling all states and responsive variants)
Testing: 2-3 hours (keyboard, mouse, mobile, screen readers)
Bug fixes: 4-6 hours over the lifetime of the project
Total: ~3-5 days to ship a button that mostly works
Semantic HTML: 20-50 elements × 1 day = 20-50 days of dev time
Div soup: 20-50 elements × 4 days = 80-200 days of dev time
Cost difference: 60-150 extra days of development = $48,000-$150,000 extra (at $800/day for a developer)
Onboarding new developers: They need to understand your custom button system. With semantic HTML, it's obvious.
Bug fixes: When your custom button breaks, you need to debug JavaScript. A semantic button rarely breaks.
Refactoring: If you want to change how buttons work, you're rewriting JavaScript everywhere. Semantic buttons use CSS—one change everywhere.
Testing: Custom JavaScript buttons need extensive testing across browsers and devices. Semantic buttons work everywhere by default.
Cost #2: Accessibility and ADA Litigation Risk
Div soup is almost always inaccessible. Your custom button doesn't work with keyboards. Your custom navigation doesn't work with screen readers. Your custom form doesn't work with voice control. This creates two costs: Lost customers: About 15% of the population has a disability. Add another 15% experiencing temporary accessibility barriers (broken mouse, arm in a sling, lost glasses, etc.). That's 30% of your potential customers who can't use your site. ADA litigation risk: Website accessibility lawsuits have exploded. In 2024, there were over 3,000 federal accessibility lawsuits. Settlement amounts averaged $25,000-$100,000 per case. If your website is inaccessible and someone sues: A single lawsuit can wipe out years of development savings from using div soup. Annual risk calculation: Cost to fix with semantic HTML from the start: $0
Average e-commerce site: 100,000 annual visitors
Visitors excluded by inaccessibility: 30,000
Average conversion rate: 2%
Lost conversions: 600 per year
Average order value: $100
Annual revenue loss: $60,000
Legal fees: $15,000-$50,000
Settlement: $25,000-$100,000
Remediation: $5,000-$50,000 (to fix the accessibility violations)
Total: $45,000-$200,000
Probability of lawsuit in a year (inaccessible site): 5-10%
Average settlement + legal + remediation: $100,000
Expected legal cost: $5,000-$10,000 per year
Plus revenue loss: $60,000 per year (as above)
Total annual cost of inaccessibility: $65,000-$70,000
Cost #3: SEO and Organic Traffic
Search engines struggle with div soup. They can't understand the structure. They don't know what's navigation, what's content, what's important. Semantic HTML signals to search engines: Div soup has no signals. Google has to guess. And when Google guesses wrong, you don't rank. Result: ranking drops 20-40% compared to semantic competitors. And this gets worse over time. Your competitors with semantic HTML gradually outrank you. By year 3-5, you could be losing 50%+ of organic traffic. Annual SEO cost of div soup: $40,000-$80,000 per year
<nav> = navigation (don't rank this heavily)
<article> = main content (rank this heavily)
<h1> = page title (important)
<h2>, <h3> = subtopics (important)
<a href> = links (crawlable)
Website with semantic HTML: 100,000 organic visitors per year
Website with div soup: 60,000-80,000 organic visitors per year
Difference: 20,000-40,000 fewer visitors
At 2% conversion and $100 average order: $40,000-$80,000 lost revenue per year
Cost #4: Performance and User Experience
Div soup requires more JavaScript. More JavaScript means slower load times. Slower load times mean higher bounce rates and lower conversion. Semantic HTML site: Div soup site: Research shows: In this example, the div soup site is 3 seconds slower. That's: On 100,000 annual visitors:
HTML: 50KB
CSS: 20KB
JavaScript: 10KB (minimal interaction code)
Total: 80KB
Load time: ~1.2 seconds (on 4G)
Bounce rate: 30%
HTML: 100KB (divs, divs, more divs)
CSS: 80KB (styling all the custom divs)
JavaScript: 150KB (making the divs interactive)
Plus framework overhead: 100KB (React, Vue, etc.)
Total: 430KB
Load time: ~4+ seconds (on 4G)
Bounce rate: 50%
Every 1 second delay in load time = 7% drop in conversion
Every 1 second delay = 11% drop in page views
Every 1 second delay = 16% decrease in customer satisfaction
21% drop in conversions
33% drop in page views
48% drop in customer satisfaction
Semantic: 70,000 stay on site, 1,400 convert = $140,000
Div soup: 50,000 stay on site, 1,078 convert = $107,800
Annual cost of poor performance: $32,200
Cost #5: Mobile Performance and Experience
Mobile is where the performance gap widens. 4G connections are slower than desktop. Low-end devices have less processing power. Div soup becomes unusable. Mobile traffic is 60% of web traffic. If your div soup site is slow on mobile, you're losing 60% of your audience.
Semantic HTML on mobile: Fast, snappy, works on 5-year-old phones.
Div soup on mobile: Sluggish, crashes on older devices, JavaScript takes 6+ seconds to load and parse.
Desktop visitors: 40,000 (2% conversion) = 800 conversions
Mobile visitors: 60,000 (0.5% conversion on slow site) = 300 conversions
With semantic HTML mobile: 60,000 (1.8% conversion on fast site) = 1,080 conversions
Mobile performance cost: 280 lost conversions per year = $28,000
Cost #6: Rewriting Div Soup Later (It's Expensive)
Eventually, someone realizes the site is inaccessible, slow, and not ranking. Then comes the "accessibility overhaul" or "SEO rewrite." This is where div soup gets really expensive. You can't just add semantic HTML—you have to rewrite the entire frontend: You just spent $100,000+ to build what should have taken an extra 10-20% effort on the first project.
Audit existing code: $5,000-$10,000
Rewrite HTML to semantic: $20,000-$50,000
Refactor JavaScript (remove custom event handlers): $15,000-$30,000
Rewrite CSS (work with actual HTML elements): $10,000-$20,000
Add missing alt text, headings, form labels: $5,000-$15,000
Testing and QA: $10,000-$20,000
Total rewrite cost: $65,000-$145,000
The Total Cost of Div Soup Over 5 Years
Let's sum it up for a typical mid-size website: That's over $1.1 million in costs over 5 years from choosing div soup over semantic HTML. For comparison, building with semantic HTML from the start would have added maybe 10-15% to initial development costs (not 50%+) and eliminated all of these downstream costs.
Semantic HTML 5-year total: $200,000-$250,000
Div soup 5-year total: $1,160,000+
Total cost difference: $900,000+
Why Companies Still Build Div Soup
None of these reasons justify $1 million in lost value.
Short-term thinking: Launch fast, worry about consequences later. But consequences compound.
Designer-driven development: Designers want pixel-perfect control. Div soup seems to offer that (it doesn't—CSS can do it with semantic HTML).
Resume-driven development: Developers want to use the latest framework. Sometimes that means avoiding semantic HTML.
Lack of knowledge: Many developers genuinely don't know semantic HTML exists or why it matters.
Tool defaults: Figma to React pipelines often default to div-based output.
The Solution: Build with Semantic HTML From Day One
You don't need to choose between beautiful design and accessible, performant, SEO-friendly code. They're not mutually exclusive. Semantic HTML with modern CSS can be: Start with semantic HTML. Layer on CSS for design. Add JavaScript only when necessary. You'll ship faster, at lower cost, with better results.
Beautiful: CSS handles all visual design. Semantic HTML is completely customizable.
Performant: Less code, faster load times, better conversion.
Accessible: Works for everyone, reduces litigation risk, expands your market.
SEO-friendly: Search engines rank it higher.
Maintainable: Easier to update, fewer bugs, lower lifetime costs.