TL;DR: Shipping an MVP with div-soup instead of semantic HTML doesn't save time — it defers the cost to a retrofit project later, which is almost always more expensive than building correctly the first time. Native elements ship behavior and accessibility for free; custom components don't.
Every MVP team has made this trade at least once: the deadline is two weeks out, the designer handed over a Figma file full of custom buttons and dropdowns, and the fastest-looking path is a <div> with an onClick handler. It compiles, it looks right in the demo, and nobody in the standup asks whether it's keyboard-navigable. That shortcut feels free. It isn't — it's a loan against future engineering time, and the interest rate is brutal.
This is exactly the trade teams building MVPs make every day, and it's exactly the trade that compounds. Teams offering MVP development services that bake standards in from day one skip this whole retrofit cycle entirely, because the first version of the product is already built on markup that behaves correctly instead of markup that merely looks correct.
None of this is an argument against moving fast. It's an argument about where the speed comes from. Semantic HTML isn't the thing you sacrifice to hit a deadline — in most cases, it's the thing that gets you there faster, because the browser already did the hard part.
"A shortcut here, a workaround there" is how one write-up on fast-tracked MVPs described the pattern, and it's precise: no single shortcut looks expensive in isolation. A fake button here, a <span> standing in for a heading there, a form field with no associated <label> because the placeholder text looked close enough. Each decision saves a few minutes. None of them gets flagged in review, because the page renders fine and nobody's running a screen reader against the demo build.
The debt shows up later, and it shows up as a much bigger bill than the sum of what it saved. Strategic debt — a conscious, documented shortcut you plan to repay — is a tool. Uncontrolled debt, the kind nobody wrote down and nobody owns, is a disaster waiting for a deadline. Standards debt is almost always the uncontrolled kind: nobody decided to skip semantic markup, it just happened by default because nobody decided to keep it either.
Often, yes — because native elements arrive with behavior you'd otherwise have to write yourself. A <button> is focusable, triggerable with Enter and Space, and announced correctly to a screen reader without a single line of extra code. A <div> styled to look like a button gives you none of that until you add it back by hand.
<!-- Costs more: a div pretending to be a button -->
<div class="btn" onclick="submitForm()">Submit</div>
<!-- Now add back, by hand, what a real button gives you free: -->
<!-- tabindex="0", role="button", keydown listener for Enter/Space, -->
<!-- :focus-visible styling, aria-disabled state management -->
<!-- Costs less: the element built for this job -->
<button type="submit">Submit</button>The right-hand version is shorter to write, has no behavior to debug, and is accessible on arrival. The left-hand version compiles just as fast — but every item in that comment block is a ticket somebody eventually has to file, usually during a QA pass or, worse, after a user complaint.
The same math applies to <nav> versus a styled list of links, <label> versus placeholder-only inputs, and <dialog> versus a hand-rolled modal with manual focus trapping. In each case, the native element is not the slower, more careful choice — it's the one with less code to write and less code to maintain.
header, nav, main, footer) — free to add while you're laying out the page, expensive to retrofit once content is nested three divs deep.for/id, or wrapping the input) that costs nothing today and saves a full forms audit later.outline: none and never replacing it is the single most common, most avoidable regression in this list.Debt doesn't get created by skipping accessibility. It gets created by skipping the decision about it. Nobody wrote "keyboard-navigable" into the ticket, so nobody built it, and six months later it's a retrofit project with its own epic and its own sprint. The absence of a decision is itself a decision — it's just one nobody can point to afterward.
This is why "shift left" matters more as a process change than as a technical one. Baking a standards checklist into your definition of done means every ticket that touches markup gets evaluated against the same short list — semantic element used, label present, focus visible — before it's called finished, instead of accessibility becoming a separate pass that competes with new features for calendar time.
| Decision point | Cost to build right the first time | Cost to retrofit post-launch |
|---|---|---|
| Semantic markup | Swap a div for the matching element while writing the component | Re-audit every page, verify nothing visually shifted, re-test with assistive tech |
| Form labels | One attribute or a wrapping element per field | Legal/compliance review, full forms audit, user-facing fix rollout |
| Focus states | Keep (or restyle, don't remove) the browser default | Component-by-component CSS audit across every interactive element |
| Custom widgets | Reach for a native element (dialog, details, select) first | Rebuild with ARIA roles, manual focus trapping, and keyboard handlers added after the fact |
The same choice that saves build time also tends to help performance. Every custom component you build instead of using a native element is JavaScript the browser has to parse and run on the main thread. A hand-rolled dropdown, modal, or accordion ships more code than <select>, <dialog>, or <details> — code that has to be downloaded, parsed, and executed before the interaction even works. Less custom JavaScript generally means a lighter main thread, which is directly relevant to metrics like INP. If your team already tracks Core Web Vitals, semantic-first markup is one of the few decisions that helps both the accessibility audit and the performance budget at once.
Not meaningfully, if you reach for native HTML elements first. Using <button> instead of a styled <div> costs you nothing extra to write and comes with keyboard support, focus handling, and screen-reader semantics for free. The slowdown people blame on accessibility is usually the cost of retrofitting ARIA onto custom components after the fact, not the cost of building accessibly from the start.
Landmark elements (header, nav, main, footer), one <h1> with a logical heading order beneath it, every input paired with a real <label>, visible focus states, and alt text on meaningful images. None of that is a feature you can descope — it's the baseline the rest of the page sits on.
For most MVP surfaces, semantic HTML gets you most of the way there without a single ARIA attribute. ARIA exists to patch gaps where no native element fits — custom widgets, live regions, complex interactive patterns. If you're adding ARIA to a div that could have been a button or a nav, that's a sign to swap the element, not add more attributes.
There's no universal multiplier, but the shape of the cost is consistent: before launch, it's a markup decision made once. After launch, it's a retrofit project — auditing every screen, re-testing with assistive tech, and often rebuilding components that were never designed to expose focus or state in the first place. The second path touches far more surface area for the same outcome.
Yes. If it isn't written into the ticket or the definition of done, it quietly becomes optional, and optional work is the first thing an MVP timeline cuts. Teams that keep accessibility out of scope documents are the same teams writing "accessibility pass" tickets six months later.
Indirectly, yes. Native elements like <button>, <dialog>, and <details> ship behavior the browser already implements, so you write and load less custom JavaScript to replicate it. Less JavaScript to parse and execute generally means less work on the main thread, which helps metrics like INP — the same shortcut that saves build time also tends to help performance.
Further reading on the spec side: MDN's overview of semantic HTML elements, and the W3C WAI's practical guidance on writing HTML with accessibility in mind. Neither requires a framework change — just a different default when you reach for the next element.
The MVP mindset isn't wrong. Shipping something real, fast, and testing it against actual users is still the right way to de-risk a new product. The mistake is treating semantic HTML and accessibility as the optional part of "real" — they're not a polish pass you add once the product proves itself. They're the foundation the rest of the build sits on, and foundations are always cheaper to pour correctly than to jack up later.