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.
My goal is to use the correct H* tag (H1 to H6) in my html5 code.
I read here I shouldn't use <section> at all: "Why you should choose article over section : Browsers’ visual display of headings nested inside elements makes it look as if they are assigning a logical hierarchy to those headings. However, this is purely visual and is not communicated to assistive technologies"
but I feel that isn't true because of the answers to this popular question:
that says "sections in an article are like chapters in a book, articles in a section are like poems in a volume" and I want to use sections for their intended purpose.
The problem is this mdn page says "Important: There are no implementations of the proposed outline algorithm in web browsers nor assistive technology; it was never part of a final W3C specification. Therefore the outline algorithm should not be used to convey document structure to users. Authors are advised to use heading rank (h1-h6) to convey document structure."
The guy from the first link I posted does make a good point about halfway down that page where he says "browsers display different sizes of font depending on how deeply the is nested in <section>s”.
So am I correct in saying I have to correctly match H* tags to depth/nesting to achieve a good outline AND visual styling or is there a different way. eg this would be incorrect:
<body>
<h1> something </h1>
<section>
<h1> section heading for outline </h1>
<article>
<h1>my first news article</h1>
<p>stuff</p>
</article>
</section>
</body>
because screen readers can't properly process <section> for outlining.
and because browsers display different fonts according to level of nesting.
so then would this would be correct?
<body>
<h1> something </h1>
<section>
<h2> section heading for outline </h2>
<article>
<h3>my first news article</h3>
<p>stuff</p>
</article>
</section>
</body>
note: This is my first question I'm posting so please go easy on me if I've made a faux-pas, I'm new here :)
The document outline algorithm based on <h1> has been removed from the spec and actually never worked. In terms of heading levels, your last code example is the correct one.
Why the HTML Outlining Algorithm was removed from the spec – the truth will shock you!
There Is No Document Outline Algorithm
So you should not use it, and your quote holds true.
Authors are advised to use heading rank (h1-h6) to convey document structure.
Correctly using <section>
As to the question of using <section> vs <article>.
You shouldn’t avoid the latter due to styling issues. You already did your research and should stick to your outcome. You’d need to apply some styling yourself, though.
I’d also like to add the ARIA perspective on a page summary:
<article> has role article
An article is not a navigational landmark
and
<section> has role region, which is …
[…] sufficiently important that users will likely want to be able to navigate to the section easily and to have it listed in a summary of the page.
To do so, it is also noted
Authors MUST give each element with role region a brief label
So, let’s put it together
<body>
<h1> something </h1>
<section aria-labelledby="s1-heading">
<h2 id="s1-heading"> section heading for outline </h2>
<article>
<h3>my first news article</h3>
<p>stuff</p>
</article>
</section>
</body>
I'm trying to write a site using the most semantically correct HTML I can manage, and my client wants a navigation bar where each link has a title and a description/subtitle inside the clickable area. What's the best way to achieve this?
Here's what my code looks like right now:
<nav role="navigation">
<a href="dashboard.html">
<!-- There's an icon here but don't worry about that -->
<h4>My Dashboard</h4>
<p>Get an overview of your cases.</p>
</a>
<a href="new.html">
<h4>Submit Case</h4>
<p>Get help from the Service Center.</p>
</a>
</nav>
And for reference, here's what it looks like styled:
The accessibility guidelines I'm following specify that heading tags should be used in descending order (as in, <h3> may only appear after an <h2> tag, etc). The answers to this question seem to indicate that it's not a good idea to use headings in the navigation regardless.
I could use <p> tags for both the title and description, but I'd prefer for screen-readers to be able to tell that the title is more important.
I'm inclined to use a description list, but I can't find examples where they're used this way.
I ended up using styled <p> tags, but with a hidden colon between the title and the subtitle to still convey the hierarchy between them to screen-readers. Headings were the wrong way to go from the start, since the nav links aren't part of the page's content.
I'm trying to find the best way to code a search result page in HTML5.
Here's how I've done it.
<section>
<header>
<h2>Results for <kbd>this terms</kbd></h2>
</header>
<!-- list of results -->
<ol>
<!-- First result -->
<li>
<article>
<header>
<h3>
<cite>
This is a result
</cite>
</h3>
</header>
<blockquote cite="http://addressofthepage.ch/">
<p>So, setting about it as methodically as men might smoke out a wasps' nest, the Martians spread this strange stifling vapour over the Londonward country. The horns of the crescent slowly moved apart, until at last they formed a line from Hanwell to Coombe and Malden. All night through their destructive tubes advanced.</p>
<footer>
<p>Published <time datetime="2010-07-15T13:15:05-02:00">MMMM DDth, YYYY</time> at the <abbr title="Uniform Resource Locator">URL</abbr> http://addressofthepage.ch/</p>
</footer>
</blockquote>
</article>
</li>
<!-- Second result ... and so on -->
<li>...</li>
</ol>
</section>
The main questions are
<header> mentions the search terms. What is the best tag to use? <kbd>?
Is the <cite> tag related to the <blockquote> if it is positioned in the <header>?
Is not better to put the <cite> in blockquote > footer like <p>[...] at the URL <cite>http://addressofthepage.ch/</cite></p>
All this is also available on a Gist
is meant as a way to show keys. That's why many sites style that tag as a keyboard key. You're not showing keys, you're showing a search term. A <span> should be fine. Maybe add a class like <span class="search-term">.
Semantically speaking, no, it wouldn't be related as it's not a child.
The "correct" HTML for using cite and blockquote would be:
A quote here...
— Foo Bar
gist here of the HTML: https://gist.github.com/OscarGodson/5a3e87ce895b3af952de (stackoverflow appears to have issues rendering HTML when in code tags?!)
Notice the cite and footer tags. As per spec:
The blockquote element represents content that is quoted from another
source, optionally with a citation which must be within a footer or
cite element, and optionally with in-line changes such as annotations
and abbreviations. Content inside a blockquote other than citations
and in-line changes must be quoted from another source, whose address,
if it has one, may be cited in the cite attribute.
Source: http://www.w3.org/html/wg/drafts/html/master/grouping-content.html#the-blockquote-element
The main thing to remember, and coming from someone who's been doing this for a long, long time, semantics matter, but don't overthink it. Sure, the blockquote has some strict rules about how to properly use it, but browsers will handle whatever you give it fine. Do what makes sense for your app and that should be semantic enough 90% of the time as long as everything isn't a span and div. If you over analyze this stuff you'll spend more time deciding which tag to use instead of just getting stuff done ;)
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).