The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

@devbanana 5. No one has yet mentioned mobile phones yet though. On such devices, you can only move with a keyboard (touch phones like iPhone excluded). They usually also have limited CSS support. Exposing navigation first for such devices makes navigation much easier, especially for cases where not all of your navigation is in one place, and thus you force the user to get to a few subsections before reaching what they're after.

Alike to what has been said earlier, if you provide skip-links and have navigation at the baseline, you not only would improve accessibility (alike my earlier post) but in the mobile StyleSheet (which works for non touch phones) you can declare the skip-links visible. This will enable mobile users to navigate the skip-links via their mobile keyboard and it will jump them to the section of the page where the navigation (or content) is located with ease.

I don't even make it an "H" anymore
Also because I use the Company name in the Tagline, together with the UVP (which tells a lot more about the company : Company Name - What we do best / why you should hire us)

Yeah, ditto, except I've stopped using a header for that at all. Since the <title> tag was already taken, I've had to try this (which seems to work ok) for logos:
<p id="naam">Logo text and possibly tagline if it's short<span>(posisble image replacement)</span></p>

Usually after navigation then is my h1. Older pages don't have this, as the company name used to be the h1, but I think this is now the right direction.

Originally Posted by boen robot

4. You can move easily with the keyboard without explicitly specifying tab index everywhere. I personally avoid that, as it too often creates confusion for non blind users, myself included.

I've been terrified to touch those as well. Once I went through a bank page and the tab index in the form made a question that visually next to question #2 come AFTER the submit button. I have no clue why.

There's a thread in the CSS section where a guy was told by his SEO guy to move everything, even the header, after the main content. Google wasn't finding their keywords. I thought that would be one of the most confusing setups anywhere: content, sidebar, sidebar, header with site nav, footer.

Alike to what has been said earlier, if you provide skip-links and have navigation at the baseline, you not only would improve accessibility (alike my earlier post) but in the mobile StyleSheet (which works for non touch phones) you can declare the skip-links visible. This will enable mobile users to navigate the skip-links via their mobile keyboard and it will jump them to the section of the page where the navigation (or content) is located with ease.

But if you force users to "Skip to navigation", you're doubling their time to reach the content. Assuming that link is the very first, and you're after the second navigation link, consider:
Arrow, Click, Arrow, Arrow, Click
vs.
Arror, Arrow, Click
And note that pressing a single key several times usually takes less time than pressing a different key once. Miliseconds of a difference, for sure, but when you add it up, the experience can start to get frustrating.

The sacrifice is that you're slighly increasing the time it takes to reach the content from the start. Assuming your "Skip to content" is the very first, after which is the navigation, users will have to
Arrow, Click
to get to the content, whereas otherwise they'd get it immediatly after the "Skip to navigation" link without doing anything. However, you get that penalty only once - when the content is first reached. If the user has accidently gone to a wrong page (a misplaced key press sequence, a misleading title, or simply a boring page), it won't take them additional time to get to the navigation and find their way around. If the navigation is at the bottom, and you're after the second navigation link, consider:
back-to-top-key(-combo), Arrow, Click, Arrow, Arrow, Click
vs.
back-to-top-key(-combo), Arrow, Arrow, Arrow, Click

Of course there may be some edge cases where the opposite might be more productive, like if you have just three navigation items, and assuming there's a go-to-bottom-key(-combo) (and I don't know if any mobile phone or screen reader has one)
go-to-bottom-key(-combo), Arrow, Arrow, Click
is just as efficient as
back-to-top-key(-combo), Arrow, Arrow, Click
while at the same time it eliminates the "Skip to content" penalty.

boen_robot, and it works the other way as well. If you force people with disabilities to have content read to them (as in the study shown way earlier in the thread) that many do, you are going to rapidly increase the amount of time it takes them to read the content (after having to listen to navigation on every page).

PS: I have just noticed you have contradicted yourself and have invalidated your entire statement. You initially stated that you wanted navigation before content, but having to scroll though navigation to read the content takes much longer and many more clicks than passing over a single “skip to navigation” link at the top (with navigation at the bottom which was my suggestion in the first place). If you honestly expect me to believe that having to scroll down past a single link (ignoring to read the content or clicking to read the navigation) will "double" the amount of time to do anything (against a full navigation list), you really need to do some genuine usability studies instead of making up false facts.

You initially stated that you wanted navigation before content, but having to scroll though navigation to read the content takes much longer and many more clicks than passing over a single “skip to navigation” link at the top (with navigation at the bottom which was my suggestion in the first place)

The point is, you don't have to scroll through the navigation to get to the content. Let's say you don't have a screen reader and so don't have any of the other ways of getting through the page. But still keyboard only. What's the difference between
* skip to site menu
<content>
<navigation>

and

*skip to content
<navigation>
<content>

?
Same skip link. Same number of clicks, assuming you are using the skip link.

Good point Stomme poes, there is no real difference which means that again we are left with positives and negatives for content before navigation or navigation before content. I will have a look for more usability studies to see perhaps if theres some more examination into the subject when I get a few spare moments.

boen_robot, and it works the other way as well. If you force people with disabilities to have content read to them (as in the study shown way earlier in the thread) that many do, you are going to rapidly increase the amount of time it takes them to read the content (after having to listen to navigation on every page).

PS: I have just noticed you have contradicted yourself and have invalidated your entire statement. You initially stated that you wanted navigation before content, but having to scroll though navigation to read the content takes much longer and many more clicks than passing over a single “skip to navigation” link at the top (with navigation at the bottom which was my suggestion in the first place). If you honestly expect me to believe that having to scroll down past a single link (ignoring to read the content or clicking to read the navigation) will "double" the amount of time to do anything (against a full navigation list), you really need to do some genuine usability studies instead of making up false facts.

As far as mobile phones are concerned, I'm talking out of first hand experience. I've also seen a few friends browsing the web with their phones. I admit I haven't done a real lab usability study with varying participants though. I've also personally had to deal with browsing the web with keyboard only, as I had no working mouse around (BTW, fun fact, YouTube has tab index support within its Flash player... I found that priceless when I wanted to replay a video; beats F5, then having to wait for the player to reinitialize).

But if you force users to "Skip to navigation", you're doubling their time to reach the content.

and

The sacrifice is that you're slightly increasing the time it takes to reach the content from the start.

?
With the second, I'm referring to "the start of the current page" (maybe I should have said that explicitly... sorry), and with the first, I mean the time from the first visit to the site from whatever page - you'll be forcing users to click "Skip to navigation" on every page, even ones they KNOW are not the ones they are looking for (but know they need to click anyway, in order to reach the content; e.g. when the right page is in a subsection of your site and the sub menu is only exposed once you're in the subsection; or they simply don't remember the right location, and go to the right page by going to another page which they know contains a link to the right page). Skimming through any content, and reading the content are two different things if you ask me.

you'll be forcing users to click "Skip to navigation" on every page, even ones they KNOW are not the ones they are looking for (but know they need to click anyway, in order to reach the content

We have two scenarios here, having navigation before content in which users will need to hit the skip to content each time they want to avoid being read the navigation. Or we have content before navigation (which was my intention) and having a skip to navigation link. Now this leaves two scenarios, people will either have to “skip navigation” on every page to read the content, or they will have to “skip content” to read the navigation... each has its own advantages and disadvantages. If the end user knows the page they want to read there will be a reduction in the amount of “skips” needed to be achieved however if they do not know where they want to go it will be the opposite. In essence clicking a skip-to link is something which will have to be done to avoid either having repetitive navigation or full content being read aloud.

My preference would be to having content before navigation on the basis that going by the idea of “nope this isn’t the page I wasn’t, *skip*” is much less out of place (for me) than “navigation being read out YET again *skip*” plus to me it feels more natural to have the list of places you could navigate too after you have finished reading the page (to follow through). In retrospect perhaps if you had the introduction block as I stated before, before the skip links you would be able to make a more informed choice if you wished to continue reading or if you would prefer to skip to the navigation to browse elsewhere.

Logo – Make sure your users are aware they are still on your website.

Introduction Panel / Tagline – Give the user an introduction to what the page of the site is about.

Skip Links – Provide accessible users the method to jump down the page to the section they require.

Content – Provide what the people who visit your website are after.

Navigation – Provide this last so it is not repeated upon each load of a page, users can get here through skip links if required.

My preference would be to having content before navigation on the basis that going by the idea of “nope this isn’t the page I wasn’t, *skip*” is much less out of place (for me) than “navigation being read out YET again *skip*” plus to me it feels more natural to have the list of places you could navigate too after you have finished reading the page (to follow through).

AlexDawson, I like your suggestion for the source order. Waiting to put the skip links until after something that summarizes the page makes perfect sense to me. I would just use the h1 of the page, however, which is the site's tagline on my homepage and the page "headline" on interior pages.

But this may not be necessary since the title of the webpage is generally whatever the h1 is followed by the sitename. Devbanana, if you're still following this, does JAWS read the page title for every page?

Maria

P.S. It's been a while since I started this thread but it has been very useful for getting me what I was after -- research-based or at least well-considered advice about best practice HTML source order taking into account SEO, accessibility and usability on a number of devices. Devbanana's perspective is particularly useful and fascinating! Thanks everyone.

But this may not be necessary since the title of the webpage is generally whatever the h1 is followed by the sitename. Devbanana, if you're still following this, does JAWS read the page title for every page?

When I say a tagline I do not mean something which would equate to the title, the title of the page is simply a short but straight to the point detail of what the current page is (like a heading for a contents page). Taglines are intended to be a summary of the pages content in opposition to a description of what the page is, therefore you could have something like “SitePoint has an experienced and well educated bunch of individuals in the driving seat, all of whom have their own story to tell” and have that as the tagline for the About Us section. The title gives the simple heading, the tagline provides a description of the content (almost like an introduction) so they are independently different.

Both my JAWS copies read out the <title>, as well as immediately starts listing things like how many links and headers are on the page... I know it used to be, you had to ask for that, but it's become defualt (I'm sure you can turn it off).

I still usually want the company/site name in the title, while the main part of the title is pretty much the same as the h1 for that page. Plus with small tabs you at least see the name of the page even if your tab cuts off the whole title.

Alex, I clicked one of your links, the sarah longneck thing, and don't see the p?? Or is that only on inner pages? I looked in source.

Stomme poes, in the sarah longneck website the paragraph is in the source as follows...

Code HTML4Strict:

<p>That's right! I love to put together totally awesome videos. I'm technically proficient, easy to work with and I don't stop till it's perfect. So what are you waiting for?</p>

Some people used H1 tags or other ways of formatting the tagline however the point is that an overview of the page or site does have very real benefits in terms of usability (and in this threads purpose, accessibility).

No problem, I wanted to point people to what I was meaning by a tagline. They have gained popularity for a good reason which is that a summary of a page before going into the “meat” of the document does have some genuine benefit to the end user.

Alex, I think what you're talking about is an abstract, a summary, a prologue, or an intro. The tag line is a marketing slogan, meant to be catchy and closely associated with the product or service. For example, "Quality is job one" (Ford), "Progress is our most important product" (GE), "Better Things for Better Living … through chemistry" (duPont), and "The truth is out there" (The X-Files), are all well known tag lines.

From a marketing perspective, the tag line is probably more important than the logo, though not as long lived.

cheers,

gary

Anyone can build a usable website. It takes a graphic
designer to make it slow, confusing, and painful to use.

gary.turner, indeed that is what I was putting forward however in web design these abstracts have become commonly (even if wrongly) referred to as "taglines" possibly due to the separation between content, navigation and logo (being pushed somewhere in between).

The tagline, is been used for ages by marketing guys, to say something clever & attach the emotions of the brand to it.
However, for optimal ROI and usability, it's not recommended to use a clever tagline on your website.

One of my clients tagline is "your source of live" (it's a water cooler company, source of live = water".
Now take this tagline + logo alone without the website content.
You have Sip-Well ... your source of live

Does it say anything about what they do ? NO
Does it say what makes them special in their industry ? NO ...

so I came up with an other tagline, not the fancy arty marketing talk
just to the point & as clear as it can be.
Sip-Well ... the Belgian water cooler expert.
Does it say what they do ? yes ... water coolers
Does it show demographics ? yes ... they operate in Belgium
Does it say why they're special ? yes ... they're the specialist (& every piece of content on the website proves this)

guidelines for a good website tagline:
- a short sentence (6-8 words) that describes the characteristics of the company & what makes it good.
- clear & informative
- differentiating & showing an advantage (for the visitor)
- a tagline is not a motto ! a tagline should bring a value proposition
- personal, vivid, smart

I'm not claiming that the new tagline fulfills all the above criteria at all. We didn't had the time to spent a lot of effort on it. But it did say a lot more then the first one.

About the intro Alex talks about.
We call that the welcome blurb.
It's a short summary what the company does, what makes it good, what the extra value is for the customer. A bit like the tagline, but longer.
Don't mistake the word "welcome blurb" with the text you see on a lot of websites that goes like: welcome to our website. Putting that text on the website is one of the most stupid things you can do (imagine that you wouldn't be welcome).

Guidelines for a good welcome blurb:
- It's present on the home page, preferable in the viewport.
- it's not a mission statement
- it should be 30 words maximum
- should contain real content. (3000 products, 200 locations worldwide, specialised in ..., 24/7 support, etc ...)

I think calling it a welcome blurb is slightly inaccurate portrayel of what I was trying to get across what would be useful. I prefer gary.turner's naming convention of an abstract for the reason that a Blurb tends to refer to a promotional message (usually only on the front page) which on a website might seem like irrelevant spam and really about as valuable as a tagline (not much). Where as an abstract is by definition a brief summary declaring the most important points to emphasise what you are about to read, which seems to me much more professional and objective reasoning behind why someone should choose you over another company.

I think calling it a welcome blurb is slightly inaccurate portrayel of what I was trying to get across what would be useful. I prefer gary.turner's naming convention of an abstract for the reason that a Blurb tends to refer to a promotional message (usually only on the front page) which on a website might seem like irrelevant spam and really about as valuable as a tagline (not much). Where as an abstract is by definition a brief summary declaring the most important points to emphasise what you are about to read, which seems to me much more professional and objective reasoning behind why someone should choose you over another company.

The welcome blurb is only used on the homepage.

The abstract you're talking about, is just standard the first paragraph (sometimes 2 or 3) of a content page for me.

I'm just using the terms the experts used.
Don't know anymore in which book I read it, but it should be one of these: 'Don't make me think', 'A call to action', 'Webdesign for ROI', or one of Jakob Nielsen's books)

Anyway it's not about how it's called, it's about what it does, & we're on the same line about that.