Easy content organisation with HTML5

Typically designers and web developers divide web pages into macro content areas (let’s call them regions). Doing an image search for typical web page returns lots of examples of diagrammatic representations of web pages with similar regions delineated:

  • header
  • navigation
  • main content
  • sidebar
  • footer

All of the page content is organised into a small number of regions which are parents of the rest of the page content. Usually these regions are identifiable visually by design and the type of content they contain, a user can scan the page and quickly get a feel for the page content and find what they are looking for. With HTML5 you can express this visual organisation semantically in your code. By using just 5 elements (aside, footer, header, main and nav)  available in HTML5 you can provide the understanding and navigation benefits of content organisation to users who would otherwise not be able to perceive it from the visual cues alone:

Typical web page diagram.
Page layout with header at top, nav on right side, main in the middle, aside on right side and footer at bottom.

Code example


Region order

The order in which the elements are organised and the region types used is based on your content organisation. Hell, if your content is organised such that you have a fat footer at the top of the page and navigation at the bottom, then so be it.

atypical content organisation.
Page layout with a fat footer at the top, followed by the main content and navigation at the bottom.

Code example


Regions within Regions

If you content organisation is such that a region is nested within another region, go for it.

nested nav within header
Page with navigation within the header region

Code example


That’s it!

When it comes to using HTML5 structural elements to define page regions the semantic magic is done by the browser (mapping the elements to ARIA landmark roles). There are a few general rules that will help users get the most out of your semantic markup:

  • Ensure all page content is within a region.
  • Less is more, regions are macro structures, so use them parsimoniously. As their number increases their utility to users decreases.
  • To mark up more granular content, within regions, use article/section/headings/paragraphs/lists etc.
Categories: Technical

About Steve Faulkner

Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.


ant says:

Hi Steve!

Do you know who is responsible of creating html5 structures and his/their principles to create (design) its set?

IMHO they should follow the MECE principle and generic schema concepts, but it does not seem to be the case.
CSS3 do not seem to follow either this principle. With its new specification drafts they propose bizarre things like more than 10 float values. An object oriented approach would be more intelligent.
I would appreciate to read your thoughts about it.

Steve Faulkner says:

Hi ant, the HTML design principles document may be helpful. As for CSS that is develped by a mostly different set of people (to HTML). You will need to ask the CSS Working Group.

ant says:

Thank you, Steve!! 🙂

Jordan Lev says:

Thanks for the simple, succinct post. I *so* want to structure my markup to a generally-agreed-upon standard, but there doesn’t appear to be any. For a while I was chugging along with the “document outline” concept, but it is terribly confusing and not even used for any purpose by browsers or screen readers.

So I’m totally on board with your suggestion here to just use header/nav/main/aside/footer for the top-level page structure. But a few questions:

1) In your opinion, should I *only* use those elements at the “top level” of the hierarchy? Or is it okay to next them (like the “document outline” definition of header/footer, which can be nested inside sectioning elements)? By “should” I mean “does this help real-world accessibility”, not “according to some spec nobody understands” 🙂

2) Can you share your opinion on the difference between “article” and “section” in terms of real-world usage and being helpful (or not) to screen readers? I gave up on using “article” because the very definition of it in the HTML5 spec says “for content that could be understood outside the context of the page … for example a comment on a blog” — which is TOTALLY contradictory to me (how the heck does 1 comment on a blog make any sense outside the context of the other comments or the original blog post it is referring to?).
So do you think it’s safe to just ignore “article” and only use “section”?

Us web developers who *want* to do the right thing by accessibility but don’t know how could really use some help! Thank you.

Giovanni says:

This ideal HTML organization matches perfectly with the form of the “classless” https://websitesfortrello.github.io/classless standard for CMS themes (see https://workflowy.com/s/Q79FgxLKUT).

In many websites the “main” markup is missing – is there a particular reason for that?

Steve Faulkner says:

In many websites the “main” markup is missing – is there a particular reason for that?

Do you mean use of the element? if so, suggest its due to the element only being around for a short period of time compared to the other structural elements.

Steve Faulkner says:

Hi Jordan, as I mentioned on A11ySlackers:
header is mapped to a banner landmark role and footer is mapped to a contentinfo landmark role, when not a child of article or section.
For example:


Neither header or footer semantics equate to landmarks.

As for article and section use, I came upon this article which may be hepful: Sectioning Content in HTML5 – div or section or article?.

Jordan Lev says:

Hi Steven,
Thanks for the response. About the article-vs-section issue: the thing that still baffles me is figuring out what the definition of “self-contained” content is. Super obvious if we’re talking about a newspaper article or an individual blog post. But the HTML5 spec ( https://www.w3.org/TR/html5/sections.html#the-article-element ) lists “user-submitted comment” as an example of self-contained content — and this just baffles me completely because I don’t understand how a blog comment could ever be considered self-contained (since it exists in the context of the blog post it’s responding to, as well as the “conversation” created by all the other comments for that post).

Perhaps this is just 1 bad example, but if I take it at face value then it makes me think “hmm… well maybe an article is really just any string of sentences that makes a coherent whole”, in which case, why isn’t every individual paragraph an “article”?

On the flip side, thinking about what a “section” is, the spec says this:
“Examples of sections would be chapters, the various tabbed pages in a tabbed dialog box, or the numbered sections of a thesis. A Web site’s home page could be split into sections for an introduction, news items, and contact information.”
Now I’m really confused, because how are those things not considered “self-contained content”? A chapter in a book? Totally “syndicatable” (I see it all the time in magazines, where they excerpt a chapter from an author’s upcoming book). What about the portions of a home page… why would the contact information (for example) not be considered “self-contained” content? I could very easily see that block of info being “syndicated” in some other context and it making complete sense. In fact, that’s the very definition of “self-contained content” to me (it’s a bunch of information all relating to the company or organization).

As with all the confusing aspects of HTML5, I’m left with a desire to not worry about the theory and instead do what’s helpful to people using assistive technology. And based on other things I’ve seen, screen readers currently don’t treat “section” or “article” tags as having any semantic value because they have been so over-used by authors (like, people just replaced all the divs in their markup with articles and sections, even if it didn’t make semantic sense to do so). But perhaps I’m wrong about this — I’d love to know what I can do with my markup to make it the most usable for all my visitors.

Sorry for the ramble, and thanks for all the great information you provide!


Stomme poes says:

Hm, I suppose some comments often get linked as standalone content, not that the site author would know this beforehand. Example:

Janghou says:

I like to add that in practice for styling purposes the horizontally stacked regions should be wrapped in a div.

For much used patterns like `holy grail` of `sticky footer`, a wrapping div is needed in responsive sites.
Example: https://philipwalton.github.io/solved-by-flexbox/demos/holy-grail/

To speak in tradition, may I introduce another `Rule of 5`: a modern responsive HTML family should consist of 5 members. A head, a body, and three children in the body.

Easy to remember and allows for most design patterns

Steve Faulkner says:

I like to add that in practice for styling purposes the horizontally stacked regions should be wrapped in a div.

You can add div elements wherever and whenever you like based upon your design needs. div elements are semantically neutral and as a general rule are not exposed in the browser accessibility tree, or exposed in a way that does not have an effect on the aural UI of HTML.

Cases of div use to watch out for:

Hi Steve, thank you for your post, I do have a question regarding the

tag. It sort of looks like you wrap everything in this tag (say 5 different ‘widgets’ or ‘blocks’, while it’s not true, as far as I understand.

Steve Faulkner says:

Hi Alex, there is nothing in the HTML spec that precludes the use of the aside element as a macro content container and given its mapping to the complementary role in Accessibility APIs and consequent expression in the aural UI of HTML it makes sense to use it for this purpose.

Hi Steve. Thank you for your answer, I find it both informative and to some extent a bit surprising.

If you could possibly look through the following bits of code and say whether they all are perfectly valid and interchangeable, what-you-like-best ways of marking up sidebars, it would be super great. Sorry they are a bit long, but it’s better like this than my poor explanation of what I mean 🙂

I have recently participated in another discussion on one of the Russian blogs that deal with just the same thing, I’m afraid I may have transeferred wrong understanding of the spec. I will deliver your answer to the Russian community as well.

The example HTML bits are taken from the spec, but they were changed so that we could see several combinations.

aside with sections
It mainly represents your previous comment that an aside element can be used as a macro content container and have several ‘blocks’ in it:

a block with asides

This is directly from the spec, but wrapped in a div for styling purposes:

Nested asides

There’s nothing in the spec that prevents nesting asides. What’s your opinion on this variant?

If they are equally good and can be used interchangeably, it will definitely throw much light on the usage of this tag. Thanks.

Sorry for the bad formatting of the previous, looks like the pre tag is banned, please feel free to edit my samples so that they looked better 🙂