Why bother with Semantics?

I learned web-design in the age of the W3C validator and used to think something terrible would happen if I launched a site using incorrect HTML. I had a Firefox extension that told if a site was valid or not and it horrified me when other sites didn’t get at least 2 of 3 checkmarks. I can’t even remember what the checkmarks validated. Since then, I have since learned a few things about HTML semantics. One of these is that there is some disagreement and room for interpretation surrounding the HTML5 spec. Other languages and frameworks can make incorporating data into semantic html more difficult that not. Client projects with time and budget contraints make niggling about semantic html impractical. So why get hung up on semantics? HTML5 is quite loose and often the output is the same whether the tag is correct or not. Many clients won’t see their their site on all the different browsers and will never notice if the list of items is marked up as a list or in a paragraph with <br> tags. And in the scheme of things, does it matter? Here are some reasons that it is worth your while to write semantic markup:

More consistant cross browser implementation Although clients might not be up on all the browser rendering nuances, semantic markup makes glaring differences less likely. Even the most bare-bones project expects a certain amount of cross browser consistency in style. Using

normalize and semantic markup can ensure that everything renders pretty much the same. This results in less annoying cross-browser testing and less work.

Accessibility Maybe you would like to support accessibility standards but you just don’t don’t have enough time or money to do so. Or maybe the project is such that no one will ever read your site with a screen reader. Perhaps you are like many and don’t really understand them. Maybe you are afraid to do it wrong. Well you are in luck. HTML5 elements have built-in aria roles. The

<header> element, for instance, includes the aria role="banner" (more about Aria landmark roles.) Now this is by no means all there is to accessibility but it is a start and it requires no extra work or great understanding.

Less typing

<footer> vs. <div id="footer"> you choose. Now I realise this is not always the case as <br> is shorter that <ul><li></li></ul> although once you factor in typing involved in correcting the CSS for various browsers, it is still considerably easier.

Craftsmanship When something is well built it is less likely to break. Sites get old. Technology changes. Even your favourite browser will have updates. You might want to show someone your project a few years from now. Your client might not understand why the site didn’t last through the latest Chrome or Firefox update. There is also pride in a job well done, sleeping well, and not having to worry about your client realising that your site is inaccessible to the

350 million people who use Opera-mini.

Maintainability Code that makes sense is more maintainable. It is tempting not to care about the future of a client project especially when it is going into the hands of other developers. Yet, no one wants the karmic residue of people repeatedly cursing them, even if they aren’t around to hear it.

Bragging rights Let’s face it. No one wants to appear lazy or worse: uninformed. Using semantic, correct, HTML5 means you’re in the know. HTML5 has been around for a while now so there are plenty of articles, explanations, boilerplates… and it’s not that hard. There is no reason to cringe when someone looks at your code. So is it worth the extra time and energy? No one is going to strike you down if you don’t and the W3C won’t give you a stamp of approval if you do. But wouldn’t it be nice to get green check marks on someone’s outdated Firefox extension? I am sure you can think of some other reasons semantic html is worth your while.