According to WHATWG spec:
The nav element represents a section of a page that links to other
pages or to parts within the page: a section with navigation links
As a second example for nav element, there is a page with more places with links, "but only one of those places is considered a navigation section". This is referring to some of p elements, inside header and footer, and is quite confusing. Clearly for me those places - according to definition - should be considered nav elements as well.
Cant understand it.
<body itemscope itemtype="http://schema.org/Blog">
<header>
<h1>Wake up sheeple!</h1>
<p>News -
Blog -
Forums</p>
<p>Last Modified: <span itemprop="dateModified">2009-04-01</span></p>
<nav>
<h1>Navigation</h1>
<ul>
<li>Index of all articles</li>
<li>Things sheeple need to wake up for today</li>
<li>Sheeple we have managed to wake</li>
</ul>
</nav>
</header>
<main>
<article itemprop="blogPosts" itemscope itemtype="http://schema.org/BlogPosting">
<header>
<h2 itemprop="headline">My Day at the Beach</h2>
</header>
<div itemprop="articleBody">
<p>Today I went to the beach and had a lot of fun.</p>
...more content...
</div>
<footer>
<p>Posted <time itemprop="datePublished" datetime="2009-10-10">Thursday</time>.</p>
</footer>
</article>
...more blog posts...
</main>
<footer>
<p>Copyright ©
<span itemprop="copyrightYear">2010</span>
<span itemprop="copyrightHolder">The Example Company</span>
</p>
<p>About -
Privacy Policy -
Contact Us</p>
</footer>
</body>
From my personal reading, what the specs say here when they say
In the following example, the page has several places where links are present, but only one of those places is considered a navigation section.
refers to the note above, which states
User agents (such as screen readers) that are targeted at users who can benefit from navigation information being omitted in the initial rendering, or who can benefit from navigation information being immediately available, can use this element as a way to determine what content on the page to initially skip or provide on request (or both).
In other words, they're not advocating for not using a <nav> instead of the <p> in that example, they're stating that only the <nav> will be understood as being a navigation section, the <p>, even though it also contains links will not be recognized as a navigation section, e.g by screen readers.
Clearly for me those places - according to definition - should be considered nav elements as well.
What part of a page should go in a <nav> is up to the page's author. The specs aren't requiring that every group of links shall be part of a <nav> (they even say it's sometimes useless for instance in a <footer>). So, sure, if you as the page author want to make this <p> section be treated as a navigation section, then make it a <nav>, that'd make perfect sense.
The difference is slight and can be confusing. The first nav element is used for providing navigation throughout the web site. The links in the footer are links to a single point of information. The barely noticeable difference is the first is a navigation through the sea of pages while the second is just a pointer to information.
It's like the difference between showing you the road on a map to get to a city versus the signposts at the beginning.
Related
In many designs, a number of headings may appear in the header, footer, or other global elements of a website. One example would be denoting "Contact Us," "Our Address," and similar sections in the page footer, or a tagline in the page header.
In these cases, I've historically tended to use <h6> elements, as they're the lowest priority heading, and therefore I assumed that the would be best suited to this use case.
However, I recently started trying to improve accessibility on my projects, and I've found that essentially every automated a11y testing tool says that this isn't the correct way to do this. I constantly get errors stating "the heading structure is not logically nested" because <h6> either appears before any other heading (in the case of a tagline in the page header), or jumps from an earlier heading to <h6> (in the case of footer titles, when the rest of the content stops after anything less than <h5>).
I would just change the <h6> in the header and footer to <p> styled to match their original designs, but that seems incorrect to me – shouldn't each section with a heading in the footer be denoted with an actual heading?
What is the appropriate way to denote headings in global elements of a page to ensure accessibility?
The typical site can have a logical heading outline by using the site name as top-level heading. Everything on the page belongs to the site, the page’s main content as well as the site navigation as well as the footer etc.
<h1>Site name</h1>
<h2>Site navigation</h2>
<h2>Page main content</h2>
<h2>Contact us</h2>
<h2>Our address</h2>
(Note that a tagline should not be a heading.)
With HTML5, you can make the sections explicit (article, aside, nav, section), and convey what each section is part of (header, main, footer):
<body>
<header>
<h1>Site name</h1>
<p>Site tagline</p>
<nav>
<h2>Site navigation</h2>
<!-- heading not necessarily needed -->
</nav>
</header>
<main>
<article>
<h2>Page main content</h2>
</article>
</main>
<footer>
<section>
<h2>Contact us</h2>
</section>
<section>
<h2>Our address</h2>
</section>
</footer>
</body>
(If the footer consists of many sections, it can make sense to introduce grouping headings/sections where possible, e.g., 'Contact' in this example. That said, not every footer needs sections/headings to begin with, especially not if the content is rather thin or not that important.)
Tools that flag the heading levels should only be doing so as a "warning" or "needs review". You can't make a blanket statement that an <h6> must follow an <h5>. I think what you're doing is correct. Make all the footer headings an <h6> so that it's consistent across the entire site. You might have pages that have enough information to warrant headings up to an <h5> but something like a "contact us" page probably has just an <h1>. Having an <h1> and then <h6> is not an automatic WCAG failure.
1.3.1 Info and Relationships is typically the guideline used to flag headings in error but all that requirement says is
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
It says nothing about skipping heading levels (except in some of the recommended techniques to achieve 1.3.1, but those are non-normative). For example, H42: Using h1-h6 to identify headings talks about using proper headings but one of the examples shows it's ok to have an <h2> before an <h1>.
I have a global navigation for my site which is in the header of all pages. I have marked it up using the <nav> tag.
I also have a navigation present on many individual pages that only apply to that page. So if its a long article, the page navigation lets you paginate sections. This too has been marked up using the <nav> tag.
All pages also have a footer which is almost identical to one at the bottom of StackOverflow's page. There are headings to group navigation links together, some copyright information, and anything else that's interesting.
I don't think its appropriate to also markup the footer's navigation within a <nav> tag because its not intended to be the main navigation for the page or any page. SO have used a table with <th> tags to wrap the headings (and the links are rows underneath) e.g:
<tr>
<th> TECHNOLOGY </th>
</tr>
<tr>
<td>
<ol>
<li>Stack Overflow</li>
<li>Server Fault</li>
<li>Super User</li>
</ol>
</td>
</tr>
With HTML5, I understand that description lists <dl> can be used for name-value pairs. So would the following be allowed/appropriate:
<dl>
<dt> TECHNOLOGY </dt>
<dd> Stack Overflow </dd>
<dd> Server Fault </dd>
<dd> Super User </dd>
</dl>
I can't think of a better way of doing it personally (without using nav + lists), but I also don't want to markup stuff incorrectly (i.e. causing poor semantic value).
If a HTML5 expert could shed some light that would be great.
UPDATE: I've had to make a judgement call and decided that a definition list is still the most semantically appropriate thing to use. Its just my personal judgement because just using a list is meaningless.
According to the official HTML 5 Spec on the <nav> element (emphasis by me):
Not all groups of links on a page need to be in a nav element — the
element is primarily intended for sections that consist of major
navigation blocks. In particular, it is common for footers to have a
short list of links to various pages of a site, such as the terms of
service, the home page, and a copyright page. The footer element alone
is sufficient for such cases; while a nav element can be used in such
cases, it is usually unnecessary.
I think using a <dl> in your case would not be semantically correct, since that element is reserved for association lists, pairing a name/term and a value.
You said it yourself that the footer menu you have is almost identical to Stack Overflow, so if you inspect the code of their menu it is constructed with an ordered list (<ol>).
Personally, I like to use unordered lists for navigation in most cases, and to get a header in your nav, I would suggest a construct like this:
<ul id="footer-menu">
<li>
<strong>TECHNOLOGY</strong>
<ul>
<li>Stack Overflow</li>
<li>Server Fault</li>
</ul>
</li>
</ul>
In this way, each list-item of the "footer-menu" list can be a menu with a heading. Semantically, it is a list of link lists. I made a super-basic fiddle for you to illustrate how it would work: http://jsfiddle.net/psnb6tb9/
I think you have to decide if you want to use heading elements (and sectioning content elements), or not. Both ways are possible. It mostly depends on whether you want the footer content to become part of the document outline.
If yes, your footer would contain a section (possibly multiple, depending on your footer content), with several section as children, e.g.:
<footer>
<section>
<!-- you may use a heading element here, e.g.,
<h1>Sister sites</h1>
-->
<section>
<h1>Technology</h1>
<ul>
<li>Stack Overflow</li>
<li>Server Fault</li>
</ul>
</section>
<section>
<h1>Life / Arts</h1>
<ul>
<li>Photography</li>
<li>Science Fiction & Fantasy</li>
</ul>
</section>
</section>
</footer>
This might especially make sense if the list of sister sites is complex/long, and relevant for your users.
If not, your footer would not contain any heading or sectioning content elements. The dl element seems to be appropriate in this case, e.g.:
<footer>
<dl>
<dt>Technology</dt>
<dd>Stack Overflow</dd>
<dd>Server Fault</dd>
<dt>Life / Arts</dt>
<dd>Photography</dd>
<dd>Science Fiction & Fantasy</dd>
</dl>
</footer>
This might especially make sense if the list of sister sites is not really relevant or important for most of your users (I’d guess Stack Exchange’s footer falls into this category).
However, this is not really suitable if your footer would contain additional "sections" (in which case you probably should use sectioning content elements, i.e., section).
A middle ground would be to use a section/heading only for the whole list of sister sites, not for its sub-sections, e.g.:
<footer>
<section>
<h1>Sister sites</h1>
<dl>
<dt>Technology</dt>
<dd>Stack Overflow</dd>
<dd>Server Fault</dd>
<dt>Life / Arts</dt>
<dd>Photography</dd>
<dd>Science Fiction & Fantasy</dd>
</dl>
</section>
</footer>
This might especially make sense if the sister site list is relevant, but the categorization of these sister sites is not that important.
Plot: When building a coupons website I realize that their can be content that is not unique to the page but should be used inside the <main><article> ..here..</article></main>.
Problem: Just because w3schools state :
The content inside the element should be unique to the
document. It should not contain any content that is repeated across
documents.
But i have content which will be inside article. Like every time for example A coupon can be used by entering its code but a deal can only be activated by going to landing page.
This will be repeated in every 'coupon' post I will publish.
So now what I tried to use was.
<main><article><main>Unique content</main>
<aside>A coupon can be used by entering its code but a deal can only be activated by going to landing page</aside></article></main>
But again :
Note: There must not be more than one <main> element in a document.
The <main> element must NOT be a descendent of an <article>, <aside>,
<footer>, <header>, or <nav> element.
So what is the best way to format the UN-UNIQUE content inside <main> and/or <article>.
The main tag should be used to group those article and aside elements.
<main>
<article>
The unique document content.
</article>
<aside>
Related content for that document.
</aside>
</main>
tl;dr - use your common sense :)
This article on the actual w3 site has a good overview of what should go where. The overall structure is:
<body>
<header>
<!-- header content goes in here -->
</header>
<nav>
<!-- navigation menu goes in here -->
</nav>
<section id="sidebar1">
<!-- sidebar content goes in here -->
</section>
<main>
<!-- main page content goes in here -->
</main>
<aside>
<!-- aside content goes in here -->
</aside>
<footer>
<!-- footer content goes in here -->
</footer>
</body>
Option 1 - <section>s
They go on to say that <section>s, fairly obviously, can contain multiple <articles>, but that it is also possible to put <section>s inside an <article>, for example to define the introduction or summary:
<article>
<section id="introduction">
</section>
<section id="content">
</section>
<section id="summary">
</section>
</article>
So one option is to put a <section id="content"> and <section id="terms"> inside your article.
Option 2 - <footer>s
It does appear valid to use a <footer> for this sort of content. You said it is just for author, date, category, but w3 states in its spec for <footer>:
A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.
Your text is terms and conditions of a coupon, which could be considered as semantically similar to copyright data. It's a judgement call I think.
Option 3 - <div>s et al...
As a get-out, in the first link they do also say about <div>s:
You should use [a div] when there is no other more suitable element available for grouping an area of content...
So if it really isn't clear what to use, another possibility could be:
<article>
Blah blah
<div class="terms"></div>
</article>
Summary
To be honest, after all this, it seems there is no definitive answer and sites are unlikely to become super-strict in how they semantically parse documents for a while yet, because they know there are legions of people out there who will do it completely wrong. If you just stick a <p> with the same terms in at the end of each article, it probably won't make any real difference because the main text is unique.
I personally think as long as you use your common sense and choose something which doesn't completely go against the recommendations, you can't go too wrong.
According to the WHATWG (the informal group behind the HTML Living Document Standard), there is no problem in using a main element inside an article. The HTML Living Document says:
There is no restriction as to the number of main elements in a document. Indeed, there are many cases where it would make sense to have multiple main elements. For example, a page with multiple article elements might need to indicate the dominant contents of each such element.
Consequently, you can write
<body>
<header>My Page Header</header>
<main>
<article><h1>My First Article</h1>
<main>My first article's content...</main>
<aside>A sidebar</aside>
</article>
<article><h1>My Second Article</h1>
<main>My second article's content...</main>
<aside>Another sidebar</aside>
</article>
</main>
</body>
However, the W3C HTML 5.3 Draft disallows this and states that "There must not be more than one visible main element in a document."
This is an interesting case of a disagreement about a central element of HTML. Amazing! It seems that there is again a schism between W3C authors and the web/browser developer professionals behind the WHATWG. In such a case, I would go with the WHATWG.
I would go with something like this :
<main>
<div class='article'>
<article>Unique content</article>
<footer>This coupon can be used only once..</footer>
</div>
<div class='article'>
<article>Unique content</article>
<footer>This coupon can be used only once..</footer>
</div>
</main>
Anyway I think having multiple <main> tags is worse than having non-unique content in an <article> tag.
You can also take into consideration Schema.org for proper mapping your content with additional attributes ( itemprop ... )
I'm setting up my WordPress sidebars for an HTML5 theme and really wanting to use before_widget and after_widget right.
So my question is this: which of the two markup patterns is more appropriate? The following code is all completely outside the <article> element.
Option 1: Aside with sections
<aside id="sidebar">
<section id="widget_1"></section>
<section id="widget_2"></section>
<section id="widget_3"></section>
</aside>
Option 2: Div with Asides
<div id="sidebar">
<aside id="widget_1"></aside>
<aside id="widget_1"></aside >
<aside id="widget_1"></aside >
</div>
I suppose the auxiliary question is then what heading to use for each widget title. If I wrap each widget in a <section> then <h1> seems most appropriate. If I use <aside>, I'm not sure.
All opinions welcome. Devil's advocates encouraged.
First of all ASIDE is to be used only to denote related content to main content, not for a generic sidebar. Second, one aside for each sidebar only
You will have only one aside for each sidebar. Elements of a sidebar are divs or sections inside a aside.
I would go with Option 1: Aside with sections
<aside id="sidebar">
<section id="widget_1"></section>
<section id="widget_2"></section>
<section id="widget_3"></section>
</aside>
Here is the spec https://developer.mozilla.org/en-US/docs/Web/HTML/Element/aside
Again use section only if they have a header or footer in them, otherwise use a plain div.
Update 17/07/27: As this is the most-voted answer, I should update this to include current information locally (with links to the references).
From the spec [1]:
The aside element represents a section of a page that consists of
content that is tangentially related to the content of the parenting
sectioning content, and which could be considered separate from that
content. Such sections are often represented as sidebars in printed
typography.
Great! Exactly what we're looking for. In addition, it is best to check on <section> as well.
The section element represents a generic section of a document or
application. A section, in this context, is a thematic grouping of
content. Each section should be identified, typically by including a
heading (h1-h6 element) as a child of the section element.
...
A general rule is that the section element is appropriate only if the element’s contents would be listed explicitly in the document’s outline.
Excellent. Just what we're looking for. As opposed to <article> [2] which is for "self-contained" content, <section> allows for related content that isn't stand-alone, or generic enough for a <div> element.
As such, the spec seems to suggest that using Option 1, <aside> with <section> children is best practice.
References
https://www.w3.org/TR/html51/sections.html#the-aside-element
https://www.w3.org/TR/html51/sections.html#elementdef-article
http://html5doctor.com/aside-revisited/
Look at the following example, from the HTML5 specification about aside.
It makes clear that what currently is recommended (October 2012) it is to group widgets inside aside elements. Then, each widget is whatever best represents it, a nav, a serie of blockquotes, etc
The following extract shows how aside can be used for blogrolls and
other side content on a blog:
<body>
<header>
<h1>My wonderful blog</h1>
<p>My tagline</p>
</header>
<aside>
<!-- this aside contains two sections that are tangentially related
to the page, namely, links to other blogs, and links to blog posts
from this blog -->
<nav>
<h1>My blogroll</h1>
<ul>
<li>Example Blog
</ul>
</nav>
<nav>
<h1>Archives</h1>
<ol reversed>
<li>My last post
<li>My first post
</ol>
</nav>
</aside>
<aside>
<!-- this aside is tangentially related to the page also, it
contains twitter messages from the blog author -->
<h1>Twitter Feed</h1>
<blockquote cite="http://twitter.example.net/t31351234">
I'm on vacation, writing my blog.
</blockquote>
<blockquote cite="http://twitter.example.net/t31219752">
I'm going to go on vacation soon.
</blockquote>
</aside>
<article>
<!-- this is a blog post -->
<h1>My last post</h1>
<p>This is my last post.</p>
<footer>
<p><a href="/last-post" rel=bookmark>Permalink</a>
</footer>
</article>
<article>
<!-- this is also a blog post -->
<h1>My first post</h1>
<p>This is my first post.</p>
<aside>
<!-- this aside is about the blog post, since it's inside the
<article> element; it would be wrong, for instance, to put the
blogroll here, since the blogroll isn't really related to this post
specifically, only to the page as a whole -->
<h1>Posting</h1>
<p>While I'm thinking about it, I wanted to say something about
posting. Posting is fun!</p>
</aside>
<footer>
<p><a href="/first-post" rel=bookmark>Permalink</a>
</footer>
</article>
<footer>
<nav>
Archives —
About me —
Copyright
</nav>
</footer>
</body>
Based on this HTML5 Doctor diagram, I'm thinking this may be the best markup:
<aside class="sidebar">
<article id="widget_1" class="widget">...</article>
<article id="widget_2" class="widget">...</article>
<article id="widget_3" class="widget">...</article>
</aside> <!-- end .sidebar -->
I think it's clear that <aside> is the appropriate element as long as it's outside the main <article> element.
Now, I'm thinking that <article> is also appropriate for each widget in the aside. In the words of the W3C:
The article element represents a self-contained composition in a
document, page, application, or site and that is, in principle,
independently distributable or reusable, e.g. in syndication. This
could be a forum post, a magazine or newspaper article, a blog entry,
a user-submitted comment, an interactive widget or gadget, or any
other independent item of content.
The book HTML5 Guidelines for Web Developers: Structure and Semantics for Documents suggested this way (option 1):
<aside id="sidebar">
<section id="widget_1"></section>
<section id="widget_2"></section>
<section id="widget_3"></section>
</aside>
It also points out that you can use sections in the footer. So section can be used outside of the actual page content.
I'm surprised that none of the responses above consider responsive design.
I may have valid aside elements such as a tag cloud, links for further reading and so on together, one after the other, in my sidebar when my page is viewed on a desktop device.
However, when my page is reduced on a mobile device to a single column then I will be separating those elements. My navigation element will go between my header and main content elements, and links for further reading will go below the main content element, above the footer.
As the semantic content of these elements is not changing with the width of the display window, then they need to be individually marked up as aside elements.
It follows then, that the sidebar itself should not be marked up as an aside element, even when it only contains content of one type.
In turn, this means that Option 1 in the original question must be undesirable (wrong?) and that the better answer should be Option 2.
The ASIDE has since been modified to include secondary content as well.
HTML5 Doctor has a great writeup on it here:
http://html5doctor.com/aside-revisited/
Excerpt:
With the new definition of aside, it’s crucial to remain aware of its context. >When used within an article element, the contents should be specifically related >to that article (e.g., a glossary). When used outside of an article element, the >contents should be related to the site (e.g., a blogroll, groups of additional >navigation, and even advertising if that content is related to the page).
I have a sidebar with latest news and random blog posts etc
<nav id="sidebar">
<section id="latest_news">
<h1>
Latest News
</h1>
<h2>
News Item 1
</h2>
<p>
Truncated text from the news item in question
</p>
View all news items
</section>
<section id="random_blog_post">
<h1>
Random Blog Post
</h1>
<h2>
Blog Post 1
</h2>
<p>
Truncated text from the random blog post in question
</p>
View all blog posts
</section>
</nav>
As you can see, I've got sections, h1's and paragraphs inside my nav.
I'm just wondering if this allowed or considered good practice. Is there a better more semantic (or less) approach to marking-up and structuring such sidebar content?
Yes, this appears to be pretty valid html5. w3org have an example of navigation with h1 tags in it.
Yes, you can do that, as also denoted in the spec
Quotes specifically relevant to your question:
The nav element represents a section
of a page that links to other pages or
to parts within the page: a section
with navigation links.
and
A nav element doesn't have to contain a list, it can contain other kinds of content as well. In this navigation block, links are provided in prose:
<nav>
<h1>Navigation</h1>
<p>You are on my home page. To the north lies <a href="/blog">my
blog</a>, from whence the sounds of battle can be heard. To the east
you can see a large mountain, upon which many school papers are littered. Far up thus mountain
you can spy a little figure who appears to be me, desperately
scribbling a thesis.</p>
<p>To the west are several exits. One fun-looking exit is labeled "games". Another more
boring-looking exit is labeled ISP™.</p>
<p>To the south lies a dark and dank <a href="/about">contacts
page</a>. Cobwebs cover its disused entrance, and at one point you
see a rat run quickly out of the page.</p>
</nav>
Actually, you could even write an h1 element as a direct child of the nav element so that the nav element would be named in the document's outline.
I suggest this reading about the importance of headings and document's outline:
http://dev.w3.org/html5/spec-author-view/headings-and-sections.html#outline
You can check your document's outline with this on-line tool:
http://gsnedders.html5.org/outliner/
Regards.