Should Your HTML Source Order Match Your Layout?

Back in the bad old days of web development, table-based layouts ruled. While they were relatively easy to understand, complex designs required nasty, deeply-nested table structures which followed the visual layout. If the CEO or web designer subsequently decided that a right-hand navigation bar would be cool, the poor web developer had to change the HTML structure on every page.

When CSS first appeared, layout independence was heralded as a key benefit. In other words, the order of the HTML content source didn’t matter — CSS could be used to create any visual design. Elements could be rearranged by changing a few style properties in one file. In theory.

In reality, we know design changes can be far more difficult and it’s often necessary to change the HTML source. As Andrew eloquently stated in Give Floats the Flick in CSS Layouts:

Pure CSS layouts are pure fiction. All current CSS layout methods rely on the document flow to some extent. CSS lacks a way to describe a layout that is completely independent of the order of the markup, although it may gain one in the near future.

In addition, the Web Content Accessibility Guidelines recommend that your DOM order matches the visual order. The main reasons:

1. If a blind person using a screen reader which follows the source order works with sighted user who reads the page in visual order, they may be confused when they encounter information in a different sequence.
2. A visually impaired keyboard user may have trouble predicting the tab-key focus if the source order does not match the visual layout. In addition, setting tabindex attributes that result in an order different from that in the DOM can cause problems with some assistive technologies.
3. There may also be situations where the visually presented order is necessary to the overall understanding of the page.

Andrew also points out that HTML5 semantic elements effectively make the source order irrelevant. The article element contains body content, nav contains navigation, and aside contains the complementary content. A parsing application can therefore find content within semantic tags rather than making an arbitrary decision based on its location in the source.

It all sounds sensible enough. So why do I feel slightly uncomfortable?

Let’s forget web technologies for the moment. When you’re creating a document, it makes sense to order elements by their relative importance. A main title is followed by body content, secondary content, links to associated resources (navigation) and a footer. The final layout rarely matters — it should be in the back of your mind, but there’s little need to consciously consider it.

That’s how I approach HTML.

I should point out that I won’t necessarily apply strict constraints. For example, I’m happy to place navigation in the header especially if there are just a few links. But, in general, I like my HTML to be logically ordered.

It’s important to consider a blind user sitting next to their sighted helper but, realistically, how often does that situation arise? When it does, how much confusion would be caused if the screen reader read the main body content before a left-hand navigation menu? Is a “skip to content” link more preferable?

With regard to tabindex settings, the WCA Guidelines highlight the main issue: tabindexes are specified in HTML whereas the visual order is defined in CSS. If the user applied an alternative stylesheet, the tabindex order would not necessarily be correct.

But is there any reason to define tabindexes if your HTML is logically ordered. In my opinion, it’s better if the user can tab through the primary content links before encountering several dozen navigation items. Perhaps this causes some initial confusion but, again, is it more than a few seconds disorientation?

Then we come to HTML5. While I foresee a bright future for the technology, we’re not there yet. Few systems distinguish between content placed in an article tag from that placed in a header — even browsers don’t care.

You should also note that a single page can have multiple article, header and footer tags. For example, let’s consider a page with a full blog post and excerpts/links to a couple of related posts. All these items could appear within their own <article> tag. If the visual layout places places excerpts on the left of the main content, is it logical for them to be ordered above the primary content in the HTML5 source?

HTML5 offers semantic tags, but that’s not a reason to create illogically ordered documents.

We should also consider maintenance implications. Designs and layouts evolve. Assuming a change can be handled with CSS alone, should the web developer then modify the HTML source to reflect the visual update? It’s additional development and testing for little real benefit.

Finally, there’s one overriding reason why content authors would not necessarily want order HTML according to the visual layout: Search Engine Optimization. Google, Bing and the other engines apply more weight to content at the top of the document. I can’t see that changing even when they become fully HTML5-aware.

I don’t have all the answers and I wouldn’t say you should never do it but, for me, ordering your HTML source according to the visual layout seems like a backward step. The potential drawbacks outweigh the relatively minor and fairly obscure accessibility benefits.

Perhaps common sense is the best all-round solution. Designs should be influenced by the content — not the other way around. Keep your HTML logically ordered and, when there’s a choice, defer to the physical layout.

I’d be grateful to hear your opinion.