The W3C definition seems a bit vague when it comes to the <nav> tag:
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.
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.
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 and/or provide on request.
Based on a very strict interpretation of their definition and what I've encountered through validation, it appears as though <nav> should only contain list elements. However, shouldn't search be considered a form of navigation within a series of pages?
While I understand that its primary use is for user agents, it still seems rather redundant to have a <nav> preceding a <ul> tag if the former acts only as a container for the latter. It would make more sense if <nav> could contain other elements related to navigation, not limited to a list of links.
For example:
<nav role="navigation">
<form action="http://google.com/search" method="get">
<fieldset role="search">
<input type="hidden" name="q" value="site:mysite.com" />
<input class="search" type="text" name="q" results="0" placeholder="Search"/>
</fieldset>
</form>
<ul class="top-navigation">
<li>Home</li>
<li>About Me</li>
<li>Archives</li>
</ul>
</nav>
Aside from validation, is this not an acceptable use of <nav>? What would the repercussions be for one less concerned with validation, than to ensure screen readers and other accessibility tools can render the page properly?
The nav element should be used for main navigation items of the site, not just all navigation items. It also doesn't have to contain a ul but since most of the time it does contain a list, it often makes sense, but isn't essential.
If your search is the main navigtion method of your site, then by all means place it within a nav, although from the example you give above, the list appears to be the main navigation and not your search.
I've written a bit about using the nav tag at to nav or not to nav?, although it doesn't mention a search, which is an interesting observation.
Related
I have a simple question. Should the button, that I use to open/close my navigation menu be included in the nav tags?
The button itself is not helping in navigating but without him, there is no access to navigation.
<nav>
<ul class="nav">
<li class="nav__el nav__el-active">Home</li>
<li class="nav__el">Generic</li>
<li class="nav__el">Services</li>
<li class="nav__el">Blog</li>
<li class="nav__el">Contact</li>
</ul>
<i class="fas fa-bars"></i> //menu btn
</nav>
that's the example. Now the btn is in the nav, but it also can be like that:
<div class="topbar">
<nav>
<ul class="nav">
<li class="nav__el nav__el-active">Home</li>
<li class="nav__el">Generic</li>
<li class="nav__el">Services</li>
<li class="nav__el">Blog</li>
<li class="nav__el">Contact</li>
</ul>
</nav>
<i class="fas fa-bars"></i> //menu btn
</div>
At first glance, when reading this at WHATWG:
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.
It seems to me that the button should not be included, as that's clearly not a navigation link.
Anyway, if you continue reading:
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).
With that in mind, it makes sense to include that button and any other non-link control you might have (usually in the header area) because if a screen reader user wants to...:
...skip the whole navigation, they also want to skip the other controls that are not links.
...jump straight to the navigation, they might also want to use some navigation elements that are not links.
If you check some of the examples at WHATWG, it looks like they are applying these criteria. The first example is:
<body>
<h1>The Wiki Center Of Exampland</h1>
<nav>...</nav>
<article>...</article>
...
</body>
Here, it makes sense not to skip the title on the page (to know where you are) but then skip all the navigation elements and jump straight to the content.
However, on the last one:
<nav>
<h1>Folders</h1>
<ul>
<li><a ...>... </a></li>
...
</ul>
</nav>
It would make sense to skip the Folders heading element if you are not interested in the navigation because it's actually part of it, the same way you put the heading of a section inside a section and not before it. The same applies to your menu button.
Some other examples of elements that might be part of the main navigation of the site, and thus go into <nav> are logos that link to the root of the site or search forms.
For example, LinkedIn is doing that:
Also, Bruce Lawson, who is part of the Accessibility Task Force, has the search inside the <nav> element on his personal website:
However, you can also find examples of the opposite. For example, AirBnB only includes some links in the <nav> element:
While in this case, I would have also included the search, that for me clearly represents the main way to navigate on their site.
Anyway, you could and should also use ARIA for accessibility and structured data / Schema.org markup for search engine support.
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.
I'm trying to learn semantic HTML5 markup by converting a simple site I once made for an old magazine. Now I've come to the navigation and search area. You should be able to select a specific article to read or search within the database. There are two tabs and when the first one is active you see the contents of the selected issue like this:
When clicking on the search tab you come to a search field, like so:
And when you've made a search the results are presented in a similar fashion to the contents above:
The present markup looks something like this:
<div id="nav">
<div id="tabs">
<div class="tab">Browse</div>
<div class="tab">Search</div>
</div>
<div id="browse">
<form>
<div>
<label>Year:</label>
<select>
<option>1985</option>
</select>
</div>
<div>
<label>Issue:</label>
<select>
<option>1</option>
</select>
</div>
</form>
<div id="contents">
<h1>Contents</h1>
<ul>
<li><a>Lorem ipsum</a></li>
</ul>
</div>
</div>
<div id="search">
<form>
<label>Search for anything:</label>
<input type="text">
<input type="submit" value="Ok">
</form>
<div id="results">
<!--
<h1>Sorry, we couldn't find anything.</h1>
<ul>
<li><a>Various stuff</a></li>
</ul>
-->
</div>
</div>
</div>
As for semantic elements, I have considered various options, none of which seems like the solution.
My first problem is whether I should wrap the whole thing inside nav tags or just the browse part, or even just the contents part of the browse part. I'm somewhat inclined to consider the whole thing a single main navigational area.
As for the inner parts, I assume they could be divided into section elements, primarily a browse section and a search section. If so, it would have been nice to get the tab text into those sections as headings, but that will complicate things presentational-wise too much (I know I shouldn't worry about CSS and JS at this stage, but I do). And sections without headings seem like a bad idea.
Another option would be to regard the div#contents and the div#results as subsections. One problem with that is that the results area doesn't have any content until a search has been made.
I can think of some other options as well, but I don't see any point in mentioning them all just to show research effort. I would still need just as much help. And I'd appreciate it too.
My first problem is whether I should wrap the whole thing inside nav
tags or just the browse part...
Looking at the definition of the nav element in the HTML5 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.
...tells us that it should be used for the id="browse" element.
I think it should also wrap the form because it contains controls to filter these navigation items.
The id="search" element should, according to the aria role search
A landmark region that contains a collection of items and objects
that, as a whole, combine to create a search facility.
Get a role="search".
The tab list on the top should get the proper aria treatment for tabs with role="tablist" and role="tab". As shown in this snippet:
<div id="tabs" role="tablist">
<div class="tab" role="tab" aria-controls="browse">Browse</div>
<div class="tab" role="tab" aria-controls="search">Search</div>
</div>
I'm currently trying to come up with a good and accessible way to format a status indicator which should be rendered within a set of wizard-like pages on a website. The website should provide a multipage form with a status indicator on top of it as demonstrated in the wireframe below:
Given the new progress-tag in HTML my first thought was to do something like this:
<progress value="2" max="3">
<ul>
<li>Beginning</li>
<li class="now">Right now</li>
<li>End</li>
</ul>
</progress>
... but since <progress> only accepts phrasing content using a list is not really an option. So right now I would probably go with something like this, integratinng the ARIA progressbar-role:
<ul aria-role="progressbar" aria-valuenow="2" aria-valuemin="1" aria-valuemax="3" aria-describedby="state2" aria-valuetext="Right now">
<li id="state1">Beginning</li>
<li id="state2" class="now">Right now</li>
<li id="state3">End</li>
</ul>
But again, I'm not really sure if the progressbar role can be applied in such a way to a list.
Another problem is, that <progress> is rendered as progress bar in Opera, for instance, so >progress> itself is probably not really a viable solution altogether :-(
Can anyone perhaps recommend an accessible status bar that does not only rely on using a single image?
Current solution
For now I will go with following markup:
<section class="progress">
<h1 class="supportive">Your current progress</h1>
<ol>
<li><span class="supportive">Completed step:</span> Login</li>
<li class="now"><span class="supportive">Current step:</span> Right now</li>
<li><span class="supportive">Future step:</span> End</li>
</ol>
</section>
All elements of the class "supportive" will be positioned off-screen. IMO this way we should have a nice compromise of semantic markup (the state succession is in my opinion really an ordered list ;-)) and accessibility thanks to the additional header and status text for each step.
According to whatwg, you're not supposed to assign progressbar role to <ul> elements.
I'd just ditch <ul> and describe progress using (surprise) phrasing content:
<section role="status">
<h2>Task Progress</h2>
<p>You're now at <progress value=2 max=3>"Right now" step</progress>.
</section>
Update: You're right, progress doesn't suit here, it's more like an interactive form widget. I should've checked first, before taking it from your first example. But anyway, the point is there's no need to use a list (even more so, unordered list), when you can just describe what's going on in plain text. In the case that the list of past and future steps is necessary, I'd just add two more paragraphs, one before the status (‘You've completed the "Beginning" step’), and one after (‘Next step will be the "End" step’).
However, I admit that this isn't a complete answer to your question.
Also, I'd say some aria attributes look redundant to me. For example, aria-valuetext perhaps would make more sense in the context of interactive widget, when there's no other human-friendly description of its state. Though I may be wrong here.
Making a search result list (like in Google) is not very hard, if you just need something that works. Now, however, I want to do it with perfection, using the benefits of HTML5 semantics. The goal is to define the defacto way of marking up a search result list that potentially could be used by any future search engine.
For each hit, I want to
order them by increasing number
display a clickable title
show a short summary
display additional data like categories, publishing date and file size
My first idea is something like this:
<ol>
<li>
<article>
<header>
<h1>
<a href="url-to-the-page.html">
The Title of the Page
</a>
</h1>
</header>
<p>A short summary of the page</p>
<footer>
<dl>
<dt>Categories</dt>
<dd>
<nav>
<ul>
<li>First category</li>
<li>Second category</li>
</ul>
</nav>
</dd>
<dt>File size</dt>
<dd>2 kB</dd>
<dt>Published</dt>
<dd>
<time datetime="2010-07-15T13:15:05-02:00" pubdate>Today</time>
</dd>
</dl>
</footer>
</article>
</li>
<li>
...
</li>
...
</ol>
I am not really happy about the <article/> within the <li/>. First, the search result hit is not an article by itself, but just a very short summary of one. Second, I am not even sure you are allowed to put an article within a list.
Maybe the <details/> and <summary/> tags are more suitable than <article/>, but I don't know if I can add a <footer/> inside that?
All suggestions and opinions are welcome! I really want every single detail to be perfect.
1) I think you should stick with the article element, as
[t]he article element represents a
self-contained composition in a
document, page, application, or site
and that is intended to be
independently distributable or
reusable [source]
You merely have a list of separate documents, so I think this is fully appropriate. The same is true for the front page of a blog, containing several posts with titles and outlines, each in a separate article element. Besides, if you intend to quote a few sentences of the articles (instead of providing summaries), you could even use blockquote elements, like in the example of a forum post showing the original posts a user is replying to.
2) If you're wondering if it's allowed to include article elements inside a li element, just feed it to the validator. As you can see, it is permitted to do so. Moreover, as the Working Draft says:
Contexts in which this element may be
used:
Where flow content is expected.
3) I wouldn't use nav elements for those categories, as those links are not part of the main navigation of the page:
only sections that consist of major navigation blocks are appropriate for the nav element. 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, without a nav element. [source]
4) Do not use the details and/or summary elements, as those are used as part of interactive elements and are not intended for plain documents.
UPDATE: Regarding if it's a good idea to use an (un)ordered list to present search results:
The ul element represents a list of
items, where the order of the items is
not important — that is, where
changing the order would not
materially change the meaning of the
document. [source]
As a list of search results actually is a list, I think this is the appropriate element to use; however, as it seems to me that the order is important (I expect the best matching result to be on top of the list), I think that you should use an ordered list (ol) instead:
The ol element represents a list of
items, where the items have been
intentionally ordered, such that
changing the order would change the
meaning of the document. [source]
Using CSS you can simply hide the numbers.
EDIT: Whoops, I just realized you already use an ol (due to my fatique, I thought you used an ul). I'll leave my ‘update’ as is; after all, it might be useful to someone.
I'd markup it up this way (without using any RDFa/microdata vocabularies or microformats; so only using what the plain HTML5 spec gives):
<ol start="1">
<li id="1">
<article>
<h1>The Title of the Page</h1>
<p>A short summary of the page</p>
<footer>
<dl>
<dt>Categories</dt>
<dd>First category</dd>
<dd>Second category</dd>
<dt>File size</dt>
<dd>2 <abbr title="kilobyte">kB</code></dd>
<dt>Published</dt>
<dd><time datetime="2010-07-15T13:15:05-02:00">Today</time></dd>
</dl>
</footer>
</article>
</li>
<li id="2">
<article>
…
</article>
</li>
</ol>
start attribute for ol
If the search engine uses pagination, you should give the start attribute to the ol, so that each li reflects the correct ranking position.
id for each li
Each li should get id atribute, so that you can link to it. The value should be the rank/position.
One could think that the id should be given to the article instead, but I think this would be wrong: the rank/order could change by time. You are not referring to a specific result but to a result position.
Remove the header
It is not needed if it contains only the heading (h1).
Add rel="external" to the link
The link to each search result is an external link (leading to a different website), so it should get the rel value external.
Remove nav
The category links are not navigation in scope of the article. So remove the nav.
Each category in a dd
You used:
<dt>Categories</dt>
<dd>
<ul>
<li>First category</li>
<li>Second category</li>
</ul>
</dd>
Instead, you should list each category in its own dd and remove the ul:
<dt>Categories</dt>
<dd>First category</dd>
<dd>Second category</dd>
abbr for file size
The unit in "2 kB" should be marked-up with abbr:
2 <abbr title="kilobyte">kB</code>
Remove pubdate attribute
It's not in the spec anymore.
Other things that could be done
give hreflang attribute to the link if the linked result has a different language than the search engine
give lang attribute to the link description and the summary if it is in a different language than the search engine
summary: use blockquote (with cite attribute) instead of p, if the search engine does not create a summary itself but uses the meta-description or a snippet from the page.
title/link description: use q (with cite attribute) if the link description is exactly the title from the linked webpage
Aiming for a 'perfect' HTML5 template is futile because the spec itself is far from perfect, with most of the prescribed use-cases for the new 'semantic' elements obscure at best. As long as your document is structured in a logical fashion, you won't have any problems with search engines (most of the new tags don't have the slightest impact). Indeed, following the HTML5 spec to the letter - for example, using <h1> tags within each new sectioning element - may make your site less accessible (to screen readers, for example). Don't strive for 'perfect' or close-to, because it doesn't exist - HTML5 is not thought-out well enough for that. Just concentrate on keeping your markup logical and uncluttered.
I found a good resource for HTML5 is HTML5Doctor. Check the article archive for practical implementations of the new tags. Not a complete reference mind you, but nice enough to ease into it :)
As shown by the Footer element page, sections can contain footers :)