Tags Have Meaning: Why div Soup Fails

When a page is built from nothing but div and span tags, we call it div soup. The markup looks fine on screen but means nothing underneath.

Most HTML tags carry built-in semantics: a button is a button, a heading is a heading. The browser already knows what each one is for.

A div is a generic box with zero meaning. It groups things visually but tells the browser and assistive tech nothing about its role.

Pick the right tag and you get behavior for free. A real button is focusable, clickable by keyboard, and announced as a button. A styled div is none of that.

A screen reader reads the page from its semantics, not its pixels. Div soup gives it nothing to announce, so users hear a flat, confusing blur.

Native interactive tags like button and a join the keyboard tab order automatically. A clickable div is invisible to keyboard-only users.

You can fake a div into a button with ARIA roles and key handlers, but that is fragile extra code reinventing what HTML already gave you.

Semantic tags mean less code to write and maintain. The platform handles focus, clicks, and announcements, so there is simply less for you to break.

The div is not evil. It is the right tool for pure layout grouping, like a flex wrapper, where no meaning is needed at all.

Before you type div, ask: is there a meaningful tag for this? A nav, a header, a button, a list? Reach for that first, fall back to div last.

Choosing real elements makes a page accessible before you add a single attribute. Good markup is the cheapest accessibility win there is.

Let us test the cost of div soup.

Tags have meaning, and a div has none. Reach for real elements first to get focus, keyboard, and screen reader support for free. Save div for layout. 🎉