Free Functionality

Properly using <label>s means you can click the label to enter the text field. Many browsers will add logical default functionality to many tags per the official specification, meaning you can use fewer JavaScript plugins and write less code than a site made entirely out of <div>s and <span>s.

Accessibility

Related to free functionality, semantics mean a lot to screen reader software. Text in front of an input field won’t be read in quite the same way as a <label> will. Screen readers will ignore most of your CSS, so it’s mostly up to the structure of your HTML.

Logical CSS

Why use a div #header when you can use a <header> and style that directly? Semantic tags make it easier to mark things up and make your style much more portable; if you have a certain style for strikeout and always use <del> elements the style is much more portable. <del> means the same thing to everyone, but everyone will name their .deletedText class differently.

It also helps keep everyone on the same page in large projects; no one enjoys learning other people’s esoteric class naming conventions.

SEO

Search engines like Google have made increased use of semantic HTML and metadata. Google’s Rich Snippets also use special metadata meant to convey semantic content.

Why it’s not all that common

It takes work, and people are used to judging a website by how it looks and works. Often there’s no accounting for semanticness because people who write the business case for apps don’t understand it or why it’s important.

It’s very hard for non technical people to understand or evaluate HTML semantics.

If a website looks good and it appears to work, why fret? Many people may not even know there is anything more to it. Similar to accessibility, this tends to get ignored until someone on your team really understands this.

If you want semantic HTML to be a priority on your project, you need to present the case for it. Showing your team/boss how your website works in a screen reader is also a helpful tool.

The answer to that is simply to convey information and to structure your document.

When you use spans and divs, you document does not have a structure. There is no lists, no paragraphs, no tables, no hyperlinks. Nothing. There is really no point to choose HTML as a markup language and then ignore the vocabulary it offers to express and structure your content. Structure is the important word here btw. HTML is for structuring not displaying. That’s what CSS is for.

If you markup your code semantically, you are giving human readers as well as machines a chance to understand the data inside your elements. If you use span and div elements all the way, you will not have this extra information and inferring them from the values alone might not be possible.

Likewise, if I want to scrape websites and only extract the headings to create Table of Contents for them, my spider would need to know what the heading are. It cannot do that without the appropriate elements.

Last but not least, if you use divs and spans only, you will have a hard time styling these with CSS. CSS Selectors work on the structure of your document and if that is mostly ambiguous structure, CSS rules get iffy to apply. How do you decide whether div div div really refers to table tr td or body ul li? You’d have to add classes and ids then, but then you are reinventing the wheel.

Also see the recommendation of the W3C

Using the appropriate semantic elements will make sure the structure is available to the user agent. This involves explicitly indicating the role that different units have in understanding the meaning of the content. The nature of a piece of content as a paragraph, header, emphasized text, table, etc. can all be indicated in this way. In some cases, the relationships between units of content should also be indicated, such as between headings and subheadings, or amongst the cells of a table. The user agent can then make the structure perceivable to the user, for example using a different visual presentation for different types of structures or by using a different voice or pitch in an auditory presentation.

To add to the already good answers here, one thing I haven’t seen mentioned is forward compatibility. As the spec evolves it is possible that additional functionality be specified for certain semantic elements. If your code is semantically correct it will be able to take advantage of this functionality with no, or minimal maintenance.

One reason you don’t see a lot of sites following semantics perfectly is that there isn’t a business case for it a lot of the time. If it drives sales (or a related category like exposure) then it is worth their money to write semantic HTML.

The best case I can make for semantic use of tags is when you are consuming or using HTML with a tool. For instance, using semantic tags allows you to directly style elements without fear of adding or removing styles from something else. Additionally, if you ever have to parse HTML using a scraper or anything of the like then you would certainly appreciate well-formed and semantic HTML as it becomes easier to write XPath and DOM queries to find what you need.

I should note that classes are not a direct replacement for semantic tags. I have a reusable classes [error, information, warning] that convey different meanings and therefore styles based on the tag they are attached to.

Because it can be useful or needed for crawlers and web services (AKA computers communicating with computers). If you write:

<span class="time">Sep 16 at 2:17</span>

…the web crawler will not necessary understand it as a date, an a time stuff. Or it will be much more difficult to locate it as a date information.

If you use:

 <time datetime="2012-02-11 16:24:02">feb 11 2012 at 16:24:02</time>

…it will be much more easier for any crawler to find and analyse the stuff.

When I say crawlers, I don’t mean search engines necessarily 🙂

I run a small web consulting company, and our current approach is to not use the new HTML5 tags because we’re trying to balance many factors. In this case, the balance is between usability, usability, and SEO:

• SEO: What other answers here said – it might help a little bit for SEO, although based on my experience the more obvious an SEO strategy is, the less likely it is to help.

• Usability #1: It’s reasonable to assume that HTML5 tags confer some sort of usability advantage. For blind users it’s certain that whatever fallback their accessible browser provides them is going to be better than anything I’m going to be able to provide. For your typical user it’s a lot more debatable. Maybe using an unskinned media player your browser provides is easier for you to use than the less familiar widget I’d otherwise put in there. Or maybe your browser’s default is crap (like the way Chrome Windows’s default MP3 player just stops working periodically).

• Usability #2: Old IE. Old IE requires a bunch of HTML5 shims that bloat the page in order for any of these tags to work. You have to add some script to the head tags that calls CreateElement() in a loop across all the HTML5 tags you’re using. If you’re not going to go around combing each page for the tags you have in use, that means every HTML5 tag. This needs to run on every single page, inline, meaning no caching. And bad news: old IE is the slowest to execute Javascript, so it creates a nice little lurch while it loads. Then you’ve got to barrel in a bunch of old IE-only Javascript and CSS, and often Flash, to make all the newer unsupported elements render correctly. You can feature detect before deciding to load the old IE code, but then you’re making old IE users wait until enough scripts have loaded to do that feature detect before even starting to request all the stuff that makes those tags work. You could browser detect and only send the old IE stuff to users with those browsers, but that can make caching tough or impossible depending on your platform. Delivering different code to different users also means testing is more complicated – ever have an asynchrony bug? How about one that only occurs on a specific browser? And only in production? Sign me up. So, you’re probably just going to send that bloat to everyone.

Until IE8 dies, the value in these newer HTML5 tags just isn’t high enough for the performance problems they bring. We’re yet to work with an audience where it’s even close to dead*, but someday.

*Our most recent metrics show IE8 at 6% for the site with the fewest IE8 visitors, and 24% with the most IE8 visitors. Far, far from dead.

The short answer is “No good reason in practice.” Almost all arguments given in favor of “semantic” markup are just thoughts of what could or should happen, rather than something tangible. For example, search engines are often referred to, but there is no public evidence of their caring the least about time or output or address.

Indirectly, we can infer that they won’t care in the foreseeable future. The schema.org site, by some leading search engines, clearly favor a specific approach to “semantic markup” based on something completely different, namely microdata (itemscope and related attributes). And they actually do this mainly for large commercial or community sites.

Using span or div works more nicely than the HTML5 novelties, as the latter are not recognized by old versions of IE even for the purposes of styling. So you need some trickery to make them “work” even as container elements.

However, there are some “semantic” elements that have real meaning assigned to them by browsers, assistive software, or search engines. Using h1 for the main heading has always been good practice for such reasons. Using label for form field labels has real impact on usability and accessibility. And so on; see The pragmatic guide to HTML: Principles.

HTML is not just a UI language, it is a data structuring language as well. It was designed to help heterogeneous machines have one common way of identifying the type of information coming for the server. Hence so many different tags. HTML pages should be a considered as data structures.