Usability on the Web is becoming increasingly important. Every day, new techniques and methods are developed to improve the way people interact with documents, making it easier to get things done. One facet of usability that isn’t often written about is that of source order. It’s easy to forget that document source order can have a strong influence on usability, as CSS gives us so much freedom with document styling. It’s important to keep source order in mind, as it can have strong adverse affects on a wide range of readers.
Which comes first? Navigation or content?
I have read in the past that certain developers feel that content belongs before site navigation. Their reasoning usually has to do with the belief that screen reader users prefer the content to be first instead of having to skip their way over a site navigation. Personally, I think site navigation fits best near the top of a document.
A lot of usability has to do with what people expect when faced with something. If your product doesn’t fit that user expectancy, the person is often confused. The majority of webpages have a global site navigation appearing first, followed by page content and various other elements. We all have been accustomed to this, including screen reader users. It follows normal convention and therefore becomes expected (most of the time).
This goes beyond navigation and page content, however. Secondary content is often misplaced in the source order because it’s easier for the developer to style a container element if it’s in the right place. The fact of the matter is, CSS gives a universal freedom to do anything you want to alter the display of a document without disturbing source order.
This is one of the major reasons I choose to apply markup to a document before even considering the style. Thinking about the style at the same time would set up a trap for non-liner source order. Keeping only the markup in focus initially will ensure that content sections are properly ordered and make sense.
Structural labels are very important for screen reader users
Tying in with source order, it’s really important to properly label your content sections with well written headings. Screen reader users are able to navigate a document extensively based on heading structure. If headings are vague or confusing, they will act as a hindrance for a screen reader user and make the document much more difficult to understand.
Your headings should strengthen the overall structure of your source order and further define how the document reads. Providing effective headings within a well thought source order can make any webpage that much easier for screen reader users or someone with a text based browser.
After reading usability test results, structural labels provided by headings have proven to be one of the most used features of a document. They’re universally regarded as useful by screen reader users, and the majority said a good heading structure really assisted with reading a document.
Skip links – useful or confusing?
Skip links can also sometimes be a usability debate. Some say that when a reader comes upon a hyperlink, they expect that link to target a different document. On the other hand, others say that skip links can be used very effectively and provide a nice service for screen reader users as well as those employing a text-based browser.
I think skip links can be very beneficial to both screen reader users and those with a text-based browser; it comes down to the link text. If you’re using a skip link to provide a shortcut to the primary or secondary content, use link text to describe it as such. It may seem like an obvious rule, but it should be said.
Usability testing has shown that experienced screen reader users hardly make use of skip links, but novice users rely on them heavily. Many times, the experienced users were able to much more effectively read a document using the heading structure as opposed to skip links. This is mostly due to the simple fact of experience. The more you use a piece of software, you become more proficient at it, and find more effective ways of accomplishing tasks. A novice screen reader user is much more likely to use a skip link and take advantage of what they have to offer.
Source order deserves a second look
While it may seem quote low level, keeping source order in mind will be of great benefit to many. Not only does it preserve accepted conventions of usability, a good source order helps to retain document longevity as well. In my opinion, one of the best ways to ensure a proper source order is to separate your development process into a markup stage and a style stage, in that order. Beyond that, testing with text-based browsers or disabling your style will help guide your placement of skip links.
Comments
Good article.
Another tip: viewing your page with css turned off is a quick way to see if your source is ordered correctly. Just ask yourself how easy it is to read the actual content when styles are turned off.
Question: just wondering why your headings go h2, h3, …, h5. I’m not sure this reflects the natural document outline?
@Michael McLoughlin: Yes I definitely agree that disabling CSS is a great way to determine your readability.
My overall site structure is lacking when it comes to heading order, but I try to be strict when it comes to the article itself. It’s one of those things I overlooked during initial development and need to revisit in the coming weeks. As of last week, I really realized that I Need to Pay More Attention to My Headings.
You may find good arguments for both putting navigation first or putting content first. Skiplinks are useful to necessary if you put navigation first. If this skiplink points to the first heading in content you have both: Identical navigation with skiplink as well as heading. Just give this heading an ID. Often the question is not “this or that” but “this and that”.
@Siegfried: Yes, from reading some of the actual studies put together by usability professionals, there were people who preferred to have the content first. The idea I took home however, was that even though readers may prefer the content to be first, they expected the navigation to come first because it was what they were used to.
I can’t get totally comfortable with the notion that navigation should naturally precede content. If a web page is essentially a message, then preceding navigation is a barrier to the message, even if it’s useful in some other important regard. The fact that low vision and blind users have become accustomed to those barriers doesn’t mean that the barriers are intrinsically necessary, or that those users are incapable of developing new expectations.
Ideally, we could separate the process of getting a webpage’s message from the process of learning how to use a website. In reality it’s necessary to grapple with issues like this one. I certainly don’t advocate ignoring user’s expectations. But I am cautious about the particular component of inertia in the usability discourse.
I prefer to make navigation easily accessible, ideally through header navigation, because I like to think of a webpage as a message first and as an appliance second. But that’s just the ideal, and in the real world of the web (?) I agree that user’s expectations are important.
Fantastically hyperbolic title =)
The Hudson Weakley study has some fundamental flaws, is usually misquoted, and addresses only one of many use cases for presenting content first.
First, half of the participants in the expectation survey in a follow-up interview volunteered that the content first model may actually be more usable than what they expected to find in the wild. The survey does not investigate if the expectation of navigation first actually translates into a usable experience – it is simply a reflection of how the majority of web sites were in 2005. I suspect that had the study gone further we would have learned that same users expect the most sites to be built poorly and hard to use.
Second, the sample size is extremely small. The one participant (of four) who struggled may have done so for a number of reasons not related to source order. Moreover, the study is specifically about accessibility – usually a permanent condition that can not be learnt away – and in this situation learning to use a piece of software is not a disability. I wonder if we revisit that same participant now – some 18 months later – if the results would be the same?
Third, in some of the tests the participants were not allowed to use their usual navigation strategies because doing so revealed usability problems related to source order whereby the order of the links didn’t make sense.
@Terrence Wood: What a fantastic reply, thank you so much for taking the time to go into the detail you did. You bring up some really solid points in that there are absolutely some issues with the study. It’s a great question to ask: Do readers really prefer navigation to be first? Or are they simply used to poorly constructed websites? In practice, Terrance, do you find yourself including content prior to site navigation?
I’ve used the same basic source order for the past 5 years or so where the visual design is your typical header, 2 or 3 cols, footer and nav is typically 5-9 wide and 2 deep. I prefer a content first source order because it tests well with screen reader users (and mobiles), removes the need to reinvent the wheel each time your content needs change, and it works regardless of the design you put on top of it – just add/subtract a couple of containers depending on the visual designs needs.
1. skip links = ‘main content’, ‘links in section name’ (optional), ‘site menu’ marked up as and not preceded by any headings
2. Site Branding – plain text – why waste my best heading?
3. Content title – , followed by sub-headings, and sub-sub-headings as required.
4. Site menu –
5. Current section: Section name – (i.e. links in ‘section name’)
6. Main sections – (links to main sections)
7. Search and help – (search form, sitemap, privacy, accessibility etc)
My tags got eaten… basically the idea is to start the content of with h1, and use h2, h3 as required. Navigation kicks off with h2 with each section as h3, this helps screenreader users by ensuring the navigation is included in the headings listing.
The skip links are marked up as an unordered list. For minimal content sites (one or two headings, few links) omit the skip links.
Jon, to answer your other questions: It’s a learnt behavior to expect navigation first and it’s a result of table based web design from the 90’s where source order was entirely determined by the visual design. And it continues today due for the same reasons – easy floats etc.
In terms of what users actually prefer, I tend to agree with what the Hudson Weakley study *actually* found i.e. it makes little or no difference to user, but good structure and descriptive headings *greatly* improve the user experience.
@Terrence Wood: Thanks so much for coming back with your replies. It’s good to read that other people have strong opinions on issues such as these, as they can have influence on many things in development and design. Do you feel that site navigation should be visually displayed after content as well? That is, when speaking about the design when it is rendered with full CSS support to a reader who is not using assisting technology.
Since you’re asking for an opinion then yes, in my view most navigation traditionally placed at the top or in the left or right sidebars could be placed after content or completly omitted from most sites. It might be too radical for decision makers studying some wireframes but consider:
1. we know that gallery style pages perform well
2. users ignore navigation areas
3. The primary ‘navigation’ for most sites is a search engine referral (or myspace).
4. RSS and social networking, and content based navigation (c.f. footer here) will continue to grow which negate the need for traditional navigation devices.
@Terrence Wood: You’ve got some extremely interesting points, and while they may be extreme, should absolutely be considered. Just because everybody is used to something doesn’t mean it can’t be better. I’m especially intrigued by your opinion that traditional navigation schemes will begin to find their way out in favor of content based ‘guides’ if you will. It does seem that having both a traditional navigation as well as an extensive contextual navigation is a bit overboard. Perhaps using space more effectively is in order in certain circumstances. I do, however, feel that a traditional navigation does have a place in many situations.
Fantastic post but in my brief scan of the comments you all miss the point entirely. Source ordered content is for search engine optimization. Having your navigation/skip-links/etc above your content can only confuse the spider more. Skip links are designed to help these improperly source order docs with mobile/screen readers. If you want good SEO, content should always come first. Followed by h1, nested h2’s with nested h3’s. sidebars/etc and then header nav. As far as layout/usability concerns, well that’s why we have CSS…
A website that was solely based on search engine referrals would be good, providing the person knew what they were looking for. If Jon hadn’t got the ‘recent comments’ section on this blog, I may have never found this article.
In reality, people use a lot of different techniques in accessing and searching for content – some use in-content links, some search, some use RSS to collate data, etc.
I think part of the problem lies in the fact that data all over the Internet is fragmented over many HTML pages – and perhaps this delivery mechanism is not fit for today’s WWW (perhaps it was in the early 90s). You don’t get that with a book – all the information is in one place, very easily accessible.
Books don’t have global navigation or advertising strewn across their pages – most should have a contents page and an index section. Yet, when a book becomes a tool, flicking through 500 pages is a lot harder than having a computer index the book and pull out the chunk you need.
Regarding source order – I find that if a documents reads well with CSS disabled (as mentioned earlier) then it is fit for the Internet.
[…] lack of source order control […]