The visual appearance of a web page can be more or less independent of the HTML code used to represent it. And that's the way it should be. Content is provided and marked up using HTML, and presentational attributes should be confined to a style sheet. This essay concerns the structural markup and ordering of elements within the HTML code.
The structure of the HTML need not impact on the visual appearance of the site, but doing things well will offer several advantages, and not just to those who are unable to appreciate the visual aspects of the site. The structure of the code has ramifications for search engine optimisation, accessibility, and general usability. The important issues are discussed below.
The title element belongs in the head
section of your document, and according to the HTML specifications is
mandatory. Its content is typically displayed by web browsers in the
title bar, and used as the title of any bookmarks (or favourite if
you're using IE) created from the page. It's also often used by search
engines, as the link text in their results pages, and most search
engines give greater weight to text appearing within the
title element.
It's therefore important to get the title right. For
the main page of your site, the title should be the name of the
site. SEO people
will tell you to include keywords in the title. Well, it's up to you,
but do they really form part of the title of the site? One
thing you can certainly do to help users and search engines alike, is
to avoid adding superfluous prefixes such as "Welcome to …".
For internal pages, the title needs to identify the
page, and also provide suitable context. Just saying "Products" isn't
particularly helpful when the text is shown on a search engine results
page. Typically, there is a hierarchy of information relating to the
site, section, sub-section(s), and finally the page itself. (cf. Bread-Crumb Trails in the companion
essay Website Navigation
Mechanisms.)
One standard practice is to essentially copy the bread-crumb trail
into the title element, obtaining something like "Site
Name > Section > Sub-Section > Page Name". This is not
without it's problems though. For 'deep' sites the title can get
rather long, and is sometimes truncated in applications. The
distinguishing information (i.e. the page title) is at the end, so may
well be lost. An alternative formulation, is one in which the page
title is expressed first, and then further context is provided. The
more natural left-to-right hierarchy is lost, but the distinguishing
information is presented first. The vertical pipe "|" is often used as
the separator in this case. For sites without a deep / strong
hierarchical structure, this is probably the best approach.
Headings are used to describe and delineate the content within a
page. For this purpose, HTML provides the tags
<h1>, <h2>, …
<h6> for up to six levels of headings. Headings
should be marked up using these tags, and they should not be used for
things which aren't headings.
Heading tags should be used hierarchically. The highest level
heading is <h1> and this should contain a heading
for the totality of the content on the particular page.
<h2> headings then denote the primary sub-sections,
and so on. Don't be tempted to use <h1> for the
site title, or for the heading for a larger body of content, of which
the page in question forms only a part.
Heading elements (possibly hidden from visual users) should also be used to title structural blocks such as "Main Menu". For this I would recommend starting at level 2 for main blocks.
Finally, it's often useful to add id values to heading tags to allow people to link directly to a specific section of your document should they wish to do so. This is especially true for long pages. For more details see: Best Practice: Always ID your Heading Tags.
With traditional media, long documents have to be split over multiple pages; otherwise the font would become too small, or the pages too large. The same restrictions don't apply to web pages. Generally you should avoid splitting a single self-contained document over multiple pages. Why should users have to locate and click on a "next page" link when they could just continue their downward scrolling?
Unless a document is really long, there's no real need to split it across several web pages. If on the other hand, it contains several more-or-less self-contained units (chapters or major sections, say) then it might be preferable to have one unit per page. As well of the obvious 'smaller chunks' benefit, it also allows incoming links to each unit to point to a normal page, rather than an anchor within a page. The former gives users more orientation, as opposed to arriving in the middle of a document. For further details see: Page 1 of N considered harmful by Richard Jones.
Remember that the web is different from traditional media in the way that people read it, so shorter paragraphs and more headings will help make your pages more usable. For further details see Writing Style and Textural Content in the companion essay Good Practice in Web Page Authoring.
For any page that goes on for more than a couple of screens, you'll probably want to include headings and sub-headings to help the user keep track of their place, and find the information they're looking for. Having done so, it may well be useful to provide a "table of contents" style list at the top containing links to at least the major sections of the document.
There is much debate over whether it is preferable to have the main page content or the navigation first in the source code for a web page. Whichever you do, it shouldn't affect the visual layout of the page, since that will be provided via CSS rules. The main things to consider when deciding on the ordering are accessibility issues and search engine performance.
The results of a study, Source Order, Skip links and Structural labels, suggest that there is little difference in terms of usability, but that user expectations (especially amongst screen-reader users) are for the navigation first. The main argument for putting the content first is that it's the bit that users are really interested in and it will help those using assistive technology get to it it more quickly. It also may improve search engine rankings and provide more useful snippets in results pages, but this is far from proven.
However, even putting the content first, one would still need to have a "Skip to Navigation" link before it is reached (see the following section). In terms of screen-reader navigation, the content is then no nearer than if it comes later at the target of an initial "Skip to Content" link. Moreover, if putting the content first, where do you put the remaining structural links to things like a search box, site map and accessibility information? There's no point in putting them before the content, since there's then more links to have to pass over, defeating the object of having the content first. Putting them after the content would make them harder to be found by users.
Therefore my preferred ordering is to start with a block of useful structural links (some or all of which can be hidden from visual users using CSS). First have "Skip to Content", then "Skip to Main Navigation" which are the two things users will want on the page most of the time. Then continue with other links to things like a site search box, accessibility page, and site map. Then present the main site/section navigation, and finally the content. Navigation before content is arguably more logical, and will also provide a more natural tab order (assuming left or top aligned navigation) for users viewing a visual presentation of the page.
It is important that users who are forced to interact with your pages in a linear fashion (mostly those with visual impairments who use speech synthesisers to listen to the page) can still use your pages efficiently. For this reason, a set of links at the top of the page (generally termed 'skip links') are often used to allow such users to jump directly to places within the page that they may be looking for, without having to listen to all the content in between. A second mechanism, know as 'access keys' allows certain key bindings to be associated with links on the page. If these are used consistently throughout a site, then users can quickly jump to the right place without even having to wait for the links to be read out.
It is generally agreed that at least a 'skip to content' link at
the very top of the page is a good thing. I would recommend also
having links there for other key parts of the page, such as the site
navigation, any in-page navigation, and the site search box. This set
of links can be hidden from visual users, by positionning it outside
the viewport. Note that the use of display:none is not
recommended since this may result in the content being hidden by some
assistive technology solutions too. When constructing the text to use
in such links, it is important to be positive and specify where the
link will go, rather than where it will not. In other words,
skip to main content
should be used in preference to
skip navigation
.
The use of access keys is more controversial. The support provided by current user agents isn't great, and the site-defined key combinations can interfer with system and application-level key combinations. (Such considerations have lead to many comentators to recommend the restrictions to numerical accesskeys only.) However, such interference is clearly the fault of the user agent vendors, and I would still encourage the use of access keys: Numerical keys shouldn't cause any conficts, and may be beneficial to some. To be useful, users have to remember which keys do what, and since users spend most of their time browsing other sites, some consistency is desirable. Vairous standardised recommendations for accesskeys have been proposed.