By Craig Buckler

Should Your HTML Source Order Match Your Layout?

By Craig Buckler

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.

  • mikeiavelli

    I totally agree. I’ve always done my best to put the primary content at the top of my html documents: 1) For SEO 2) For accessibility reasons. A text-to-speech software shouldn’t have to go through the navigation links, profile, popular posts, etc. I even put the website’s name (with the link to my homepage) after my primary content, as it does not give any semantic or SEO advantages in my case.

  • powerpotatoe

    I code logically, not necessarily in line with the visual layout but usually very close. If some visual element is near the top of the visual page, I will want to see the corresponding code in a similar order in the HTML. Typically, the visual layouts I work with read top to bottom, left to right. It seems more effecient organizationally to order the corresponding code top to bottom. But I think it comes down to personal preference, and of course the demands of the design and application.

  • I agree with you, 100%

  • Phil Rae

    When creating a site in HTML, try turning off all styles – that’s how a blind person/search engine sees your site; and as such, clearly makes it obvious that it should follow a linear natural order.

    On another note, 100% CSS layouts are possible – use absolute positioning and you can place items using exact pixels. As a bonus, it tends to work perfectly in older browsers too (IE6, I’m looking at you).

    • The way a screenreader views your site is totally not the same as how a text-only browser or search engine sees it; this is a misnomer.

      Screenreaders do present content in source order, that’s true, and they can see some kinds of meta-information, such as the ALT text of images. But they’re also affected by visual CSS (eg. content hidden with display:none is also hidden to a screenreader), and they’re affected by JavaScript.

      A closer analogy would be to have a sighted user view the page and then read it out to you over the phone.

      • Anonymous

        “misnomer” doesn’t mean what you think it means. You mean “misconception”

  • Michael Tuck

    I lay it out following the flow of the page unless there’s an overwhelming need not to do so. To date, I’ve not seen that overwhelming need in my own work, though I’ve come across valid examples in other structures. And Phil and mikeiavelli are both absolutely right, the linear flow aids in accessibility.

  • Andrew Tetlaw

    I hope I didn’t come across, in my article you refer to, as saying source order should always match display order. I’m not sure anyone is saying that.

    What I was attempting to say was that those who would say floated layouts are the only way to achive source-order independance, and that source-order independance precludes other layout techniques are not being 100% honest.

    I too believe in logical source ordering. And if my excerpts were to be displayed on the left of the main content, I also wouldn’t want them to appear first in the source order. I agree.

    But we’re not really talking about source-order independance. If we were then we’d have the equivalent of XML and XSLT.

    I think the whole issue gets overblown and somehow becomes a battle of purity versus impurity. Which is sily. You make your own logical choice for the situation at hand. You’re main navigation links may not be your primary content, but you may want to have that HTML first so that on minimally-supportive clients (say non-smart phones) the main links appear first.

    • Michael Tuck

      Excellent points, Andrew. These kind of discussions can always go to one “edge” viewpoint or the other; though this one isn’t (yet) heading that way, it’s good to have a voice of moderation and common sense stake out ground up front.

    • Thanks Andrew.

      The main issue for me is WCAG C27: Making the DOM order match the visual order. While it’s only a suggested technique, many could read it in isolation and conclude it’s a W3C “rule” which should apply to all page code.

  • Yuguo

    We have a blog. In post pages we putting Header(which have navigation in it) after the Wrapper(which wraps the content) in the DOM. So the screen reader can read the content just when the page loads.

    And in Index page we put Header before Wrapper, because we think that’s important to everyone. this is a sample.

  • Avangelist

    If you read any of the articles on the subject by Jeremy Keith you will realise that it is far more intricate if you want it to be.

    Within an article, you may have a header, hgroup within that header, you could have a nav, an aside, a footer all realting to the article.

    The DOM semantic still remains, you have overarching page hierarchy but then each level has it’s own grandparent, parent, child, grandchild tree for you to deal with.

    It is impossible to cater to every requirement and there are many additional techinological supports which may aid.

    Microformats extend your usability and in some areas accessibility but they will never solve every use case.

    Without sounding crass, I have often wondered what the statistics are for expert/heavy users of web services for people who are visually impaired or disabled for example.

  • Absolutely — and that was one of the points I hoped to get across.

    A single page can have multiple sections, articles, headers and footers so it remains important to order your document logically. If you follow the visual layout, HTML5 semantics do not necessarily provide a solution.

  • Anonymous


    Anything less would be an accessibility felony.

Get the latest in Front-end, once a week, for free.