Semantics — Why Bother?
A great deal has been written about semantic markup and its importance. Some of this material has been written by purists who defend semantics because they like the logic and structure that semantic markup can convey. That’s all very well and good, but what does semantic markup mean? And what practical usage does it have?
Semantic means to have, or convey, meaning.
In an Extensible/HyperText Markup Language (XHTML/HTML) context, this translates to using elements that actually convey accurate information about the content they enclose. If you have a page header or sub-header, it should be in an H tag (heading element). If you have a nice testimonial quote, it should be within blockquote element rather than basic paragraph tags with applied style. Remember the saying It does what it says on the box?
Well, markup provides the boxes for all page content. Semantic markup ensures that your boxes have the right labels. It goes a long way to ensuring that software doesn’t have to open the box and analyse the contents first before figuring out how to render them. After all, if you open a can labeled “Beans,” you expect to see beans, not peaches. If can labeling was as variable as some of the page markup on the web, meal times would be a lot more… well, interesting, if not exactly edible.
Markup First, Style Later
When marking up new content, your first thought should be What kind of content is this phrase?
and not What does this say?
or How should it look?
Concentrate on describing the content by applying the correct semantic markup first. Examine every piece of text on a page to determine what type of content it is and how best to convey that through markup. The humble p element should be your last resort — not your first choice.
Only when this process is complete should you start to look at graphical styling via your Cascading Style Sheet (CSS). If you have made good use of the full range of markup that is available — rather than just relying on p tags and the odd header element — you may even find that your pages are easier to style. You will probably end up with a larger set of elements to style on a single page and you may not have to create so many specific classes or ids to achieve a given effect.
Why Does Semantic Markup Make A Difference?
Well, for a start, you have no real idea how many of your visitors won’t actually see your pages using a graphical browser, so you can’t rely upon purely graphical renderings to convey meaning. Styling your quotes using p tags with added styling to render the text dark red or bright green is pretty pointless if some of your visitors won’t ever see the pretty effect. Google certainly won’t, and that’s one pretty important visitor.
However, from an accessibility point of view, a great deal of the assistive technology out there is reliant upon semantic markup. The assumption is that headings will be in enclosed in H tags; quotations will be marked up properly and lists will use list markup and not just rely on hard-coded line breaks. JAWS, for example offers users the option to jump from header to header without reading the intervening text. This is the audio equivalent of a sighted user scanning a page to see what topics it includes before settling down to read a particular paragraph. However, this feature is useless if a page doesn’t contain any header markup. That line of text at the top of a page may look like a header but, unless it’s marked up correctly, it’s not a header and it certainly won’t sound like one.
Similarly, some screen readers may automatically change voice when encountering quotations that are correctly identified using markup. If you don’t use appropriate quotation markup, it becomes extremely difficult to separate, for example, testimonials, from their surrounding text. Conversely, if you use blockquote inappropriately to simply indent plain text, screen reader users may be presented with a page that no longer makes sense.
Finally, using semantic markup offers the best method of future proofing your content and ensuring that it continues to make sense via a whole range of user agents now or in the future.
Different Strokes
Although adopting semantic markup will, by definition, tend to lead you towards particular approaches and practices, it is worth bearing in mind that there may not be a hard and fast rule in every situation. Even within semantic markup, there is room for a number of equally valid Best Practice approaches. For example, should a page have just one H1 heading element or is it okay to have more than one? There are good arguments for both sides of that particular discussion.
Right and wrong are concepts that should only have limited usage within web design once you get beyond the appropriate World Wide Web Consortium (W3C) specifications. Beyond these documents, there is only opinion and user feedback. The latter is particularly important and should never be under-estimated. Given that web pages are supposedly intended for use by users, this does seem to be stating the obvious but there are times when user feedback can get over-looked in the pursuit of semantic perfection. And that just has to be plain wrong!
Opinions, however, are just that. They are not rules and they are open to discussion. Listen to as many points of view as you can, then think about it on your own until you reach your own informed decision. At the end of the day, that’s what applying semantic markup is really all about — thinking about your content first.
James Mills responds:
Posted: April 17th, 2007 at 8:32 pm →
Nice! What more is there to say? Really good article, some great starting points for people too. Completely agree…
Mike Cherim responds:
Posted: April 17th, 2007 at 10:01 pm →
I agree, Mel. It’s more than just being proper. If a print publisher was going to layout a book they wouldn’t use 24pt bold text for the body and 12pt normal text for chapter headings. If it were a book the meaning — visually, of course — would be lost or at least confused by doing this. And in print, barring entirely separate media, visual meaning is the only way to convey meaning.
We’re lucky on the web in that we can assign value to the to a page’s parts by using a pre-determined set of elements, namely X/HTML, that have an international value or meaning on all levels, not just visual. This makes the web infinitely more powerful as an accessible, universal medium. Thus it’s very important the proper elements be used for their intended purposes to retain this universality.
On a development level, I feel, though not equally, that it’s also important to use semantic classes and IDs as well. Doing this makes the mark-up more universal, in addition to the content.
Excellent article!
Mel Pedley responds:
Posted: April 18th, 2007 at 5:22 am →
You certainly can’t buy-in to semantics part-time. You either follow the pre-defined schema as closely as possible (and on the Web, that means W3C compliancy) or you might as well forget the whole idea. Going halfway is likely to bring little return for a lot of effort.
Applying semantics to CSS is certainly a good way to start focussing the mind to think semantically. It can also be extremely useful when you return to a design after a year or two. It’s a lot easier to immediately recall what
.error_msgor.success_msgwere actually used for instead of struggling with.redor.green. Ditto#hotelBookingmakes far more sense than#form1.In the long term, semantic content should also lend itself to being read and parsed by machines - which opens up opportunities to share and re-use content in a multitude of different ways as each application/machine applies its own parsing rules to a common schema. So a pinch of semantic content can go a lot further than a whole handful of poorly defined material. Given that maximising content propagation, and therefore, potential audience, has to be at the top of almost every web master’s list, a semantic approach makes perfect sense.
Spider Trax » A Musical Web responds:
Posted: April 18th, 2007 at 8:49 am →
[…] In fact, I recently wrote an article entitled Semantics — Why Bother? on this very subject for Accessites. That started me thinking about XHTML and schemas in general and why it can sometimes be hard to get the concept of a semantic information system across. […]
Dennis responds:
Posted: April 18th, 2007 at 9:38 am →
Great article! Good XHTML and semantic markup is also beneficial for Search Engine Optimization (SEO).
Elliott Cross responds:
Posted: April 18th, 2007 at 10:13 am →
Good article! I really enjoyed and thought a lot about the ‘Markup first, Style later’ part as I still struggle as a newer designer with that aspect. I often find my thoughts working on how a site is going to look and then trying to get the code to fit that look. I have also found that some sites that I have looked at for inspiration get a case of div-itis, with symptoms of class-itis and id-itis. I will continue to strive to improve my skills, and the accessible, semantic coding community are a great inspiration to me to learn more, work smarter, and strive to be the best!
Thanks again!
Tommy Olsson responds:
Posted: April 19th, 2007 at 3:03 am →
A very good summary, Mel! There’s only one little detail with which I disagree:
The
pelement should be your first choice for paragraphs of text, and should not even be considered for anything else.I would say that the last resort should be the
divelement, since it conveys very little semantics.Mel Pedley responds:
Posted: April 19th, 2007 at 5:13 am →
@Tommy: Good point. How about
The point I think we need to bear in mind is that you should rule out other markup such as headings, lists, quotes etc. first before deciding that your text is actually a paragraph - at which point you can mark it up accordingly.
pbeing the penultimate resort then?Roho responds:
Posted: April 19th, 2007 at 8:47 am →
I have looked at the subject of semantics from a different angle. With the upcoming of xhtml and css based web design and the farewell to table based design many web developers have fallen into the habit of using loads of
divs in their markup. I have thought that it should be possible to only use clean semantic markup. I have tried and made quite some progress.Mike Cherim responds:
Posted: April 19th, 2007 at 9:23 am →
I appreciate what you’re saying in your article, Roho, but I feel the use of a few
divelements — which do have semantic value in that they identify divisions on a given page — and the so-called “divitis” are two separate things. Moreover, once things get a little more complex, trying to do without a fewdivs (as you probably know from experience) can make a simple task quite complex. Keep up the good work, though. Hopefully the end result will be that you’ll make people think and try to do away with extraneous divisions.UpperCanuck responds:
Posted: April 20th, 2007 at 11:50 am →
Nicely stated. I couldn’t agree more. I would also add that using semantic code also allows one to use various add-sons, mashups, components, et all more effectively. The use of semantic code forces a designer to be one with the concept of structure as much as visual results.
Andrew Rickmann responds:
Posted: April 20th, 2007 at 12:20 pm →
I agree with that Mike.
While it is certainly good practice to avoid using Div tags if you don’t need them there isn’t a lot to be gained from avoiding them altogether.
Colin responds:
Posted: April 21st, 2007 at 12:04 am →
I think the common resort to a DIV or P element is because of their inherent rendering as block elements. Not that it’s an excuse, but it’s one less line of CSS code to display a span as block, although a span with a class or id would make a lot more sense in these cases.
MrQwest responds:
Posted: April 23rd, 2007 at 5:07 am →
This is a very good article! I used to design websites around 8 years ago, and every page i done was created from tables! As much as it worked, it was messy behind the scenes!
I’ve now got back into web-design, and I’m learning about (X)HTML, CSS and semantics. This article has gone a long way to explain what semantics are, and why we should use them! Most article’s I’ve read have only confused matters!
Thank you for enlightening me
Ratatat responds:
Posted: April 23rd, 2007 at 2:20 pm →
@Tommy:
‘Fraid you’re wrong about the div tag, sir. The div is as semantic as all the rest. It clearly defines a division/section in a document. Therefore, using divs to separate masthead from content from navigation, etc, is perfectly semantic. Let’s not make it harder than it is, shall we?
Dustin Diaz responds:
Posted: April 23rd, 2007 at 4:25 pm →
I would say that semantic markup is a good starting point. But not the end all be all. It’s a guide to put you in the right direction, but when you’re building web apps to perfection and speed, a lot of times you do whatever it takes to get it working exactly the way you want it - and you have to break a few rules along the way. That’s just my sense on it, of course - I have a heavy js slant on the topic. Any simple blog or marketing website is a case for easily implementing semantics.
Mel Pedley responds:
Posted: April 24th, 2007 at 4:00 am →
How does using semantics interfere with the ability to build web apps? Surely one of the reasons to build something that’s web or browser based is to make it portable - ether across systems or user agents? As I see it, using semantic markup in that situation would actually help, wouldn’t it?
JP Concepts » If you’re into accessible design, read this! responds:
Posted: April 26th, 2007 at 10:57 am →
[…] I just got finished reading an excellent article on page design semantics. The article covers the reasoning behind designing accessible websites by using tags that convey meaning to the page. For example if you are writing a headline on your page, then doesn’t make sense to use the H tags for the headline, same with quotes, their are so many designers who use the paragraph tag for quotes and add a splash of CSS to make it pretty, doesn’t make more sense to use the blockqoute tag? Anyway I highly recommend you read this article if you want to learn about a big part of the future of web design. Peters out! Doh… to much American Idol I guess Filed under: General — admin @ 3:57 pm | […]
Stevie D responds:
Posted: May 11th, 2007 at 7:29 am →
@Ratatat:
A [div] is not a semantic element - it doesn’t convey any information beyond “Here is … er, something”.
Yes, it may be correct and beneficial to enclose the branding in one [div], the main content in another and the sidebar in a third. But that just shows how little semantic value the [div] has - it can mean anything.
Other elements tell you what they contain. A [ul] has a list, not anything else. A [h2] has a subheading, not anything else. And so on. That is what those elements mean. A [div] doesn’t mean anything; it’s just a way of structuring and styling your page.
Semantics - Why Bother? | Magna Creative Blog responds:
Posted: July 10th, 2007 at 9:52 am →
[…] Article by Mel Pedley […]
Paul Nash responds:
Posted: July 11th, 2007 at 4:26 am →
A good article indeed, but it sits on the fence with regard to headings. A clear standard policy would be helpful here. It seems that one of the reasons for restrictions in this area is the inability of JAWs to allow tabbing through headings that don’t follow a simple numeric order (using the H key). If JAWs meets a second H2 heading halfway down the page — a perfectly normal piece of layout — it jumps back to the top of the page.
There is little point in applying good semantic markup rules if your reader can’t peruse the basic structure of the page.
Mel Pedley responds:
Posted: July 11th, 2007 at 8:21 am →
I don’t feel I sat on the fence. The article was intended as an introduction to and an explanation of the reasoning behind semantic markup. I think that if I’d delved into the “whys” and “wherefores” of heading order, I’d have ended up with a much longer article and lost a few of the readers I was hoping to reach partway through.
I’m strongly in favour of using headings that follow a logical heirarchy as a method of imparting a good structural foundation to pages but, like many web accessibility topics, as soon as you start to delve a little more deeply, you find out that it’s not as simple and straightforward as it might first appear. Rather than re-invent the wheel here, I’d recommend Grant Broome’s article on heading usage.
As for JAWS jumping back to the top of the page if it encounters more than one H2 element, that’s a new one on me! It certainly doesn’t fit in with my understanding of header handling within JAWS. Nor does it seem logical. I can think of numerous instances where a single page might, quite correctly, have two or more H2 elements. Could this behaviour perhaps relate to a very specific situation?
Grant Broome responds:
Posted: July 11th, 2007 at 11:32 am →
@paul
Hi, have you got a sample page? Because I haven’t been able to replicate that behavior.
Are you talking about a page with noH1? I’m quite interested in this.
@Mel, thanks for the link