Warning: I am about to discuss code.  Your eyes may experience a slight “glazing over” sensation.

I’ve spent the last year or so devouring countless books, tutorials and articles pertaining to CSS, web standards and blog and CMS technology.  In many ways it feels like I’ve had to unlearn everything I’ve been practicing for the last half dozen years or so and start from scratch.  This transition was not an urgent necessity—I could have very well continued to build websites the way I always have and they would work just fine.  For now. 

But I know that the web will look and function very differently than it does today in a few years time, and I intend to be prepared.  I am not only looking out for my own career, but for my clients’ investment in the web as well.  They may not want to know about web standards now, but soon they will (or at the least, it will surely affect them), and I need to be an expert when that time comes.

One issue that I admit I am not entirely up to speed on is the issue of semantic markup (I admit this only because I know that I am not alone, don’t front).  But I will say that with every website I code, I stretch myself, and try to incorporate better and better standards.  I know where I am headed, and that’s a start.

First, a definition. 

Semantic markup involves marking-up content using element types that describe the content (rather than just how it should be presented). As it also provides structure, assignment of element types to content in HTML is also often described as structural markup.

Benefits of semantic markup

Semantic markup enables content to be shared more readily. Computer programs (for example, search engine indexing programs) are able to more accurately interpret content when semantic markup is used:

*content types are explicit, for example, an image, tabled data and a list are understood be intrinsically different content types
*content hierarchies are explicit, for example, text marked-up level-one heading element can be assumed to be more significant than text marked-up as a level-two heading element
*content relationships may be more apparent, for example, parent-child relationships may be assumed in the decision to structure a document using heading elements; the level-one heading one is the main topic, level-two heading a sub-topic, and so on

Semantic markup is also used by assistive technologies, such as text-to-speech browsers, for example:

*Heading elements can be used to quickly navigate within webpage content (emulating the process of scanning available to sighted users)
*Attributes can be added to aid pronunciation of words and phrases taken from languages other than that set as the document’s ‘native’ language

In other words, the little chunks of code that we web designers write to make a website look the way we want it to also serve to provide meaning to search engines and devises that the visually impaired use to translate from visual to audio so they may “hear” websites. 

If this is new to you, let that sink in for a minute. 

In the past we didn’t need to worry too much about writing “clean code”—(browser and other) technologies weren’t advanced enough to handle it anyway and so we didn’t have to be advanced either.  That was then.

Why should we care, and why should we educate clients?
For our clients, it’s about missing opportunities.  Imagine missing a whole segment of your target market because they are “hearing” your website on a screenreader and can’t make sense of the information because it wasn’t coded properly.  Imagine losing rank on search engines because your website isn’t coded as well as your competitor’s. 

Sharing the reasons why I might choose a strong tag rather than a b (bold) tag would probably bore a client to tears, but I’d bet that “missing opportunities” would make for an interesting discussion.

I have engaged in debate with other web designers about such issues and I hear things like:  “I use the b tag and never the strong tag because they both result in bolded text, why should I waste my time and use two different tags to achieve the same result?”

The reason is that “strong” and “b” mean two completely different things. Sure, visually, they look the same.  But one is used for decoration (bold) and one implies emphasis (strong), the way we speak with emphasis by raising our voice.  When a website is translated from visual to audio, for example, this matters.  And it will matter more and more as time goes on, mark my words. 

“It looks good on the outside and it doesn’t matter what’s going on behind the scenes in the code” (as long as it validates) is like saying that you used spell check and saw no errors, so “great!” But what if you used the word “procreate” instead of “concentrate” (you know you’ve done this, lol).  They are both spelled correctly and will validate, right?  Same thing with semantic markup. 

P.S. If you’re a designer, here is a handy semantic markup guide from David Shea.  I intend to pin it on my wall. 

If you want to learn more, definitely pick up a copy of Dan Cederholm’s (http://www.simplebits.com) Web Standards Solutions, it’s by far the best book I’ve read on the topic.