Semantic markup of navigation and search area - html

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>

Related

semantic html - autocomplete results in combobox

I have a role="combobox", which opens up a role="listbox" when something is typed. The listbox has a list of items where the <li> are marked as role="presentation" and the children element as role="option". The list items in this case have 2 bits of information, a primary text and a secondary text. should these list items simply be divs, or is there a better semantic element which can be used?
<input role="combobox" aria-haspopup="true" aria-autocomplete="list" ... />
<ul role="listbox">
<li role="presentation">
<div role="option">
<div> primaryText </div>
<div> sencondaryText </div>
</div>
</li>
</ul>
Is there a more semantic way to represent the primary and secondary text?
In a similar scenario, when search results are shown, I have seen each search result is an <article>, the title is either <header> or <h1>, and the secondary text is regular <div>. Does that structure make sense here?
Also, in some cases the results need to have a title, for example: "Results"
In that case I usually change the structure to:
<input role="combobox" aria-haspopup="true" aria-autocomplete="list" ... />
<div class="container">
<div> Results </div>
<ul role="listbox">
<li role="presentation">
<div role="option">
<div> primaryText </div>
<div> sencondaryText </div>
</div>
</li>
</ul>
</div>
In this case would it make sense to use a <section> like this
<input role="combobox" aria-haspopup="true" aria-autocomplete="list" ... />
<section class="container">
<header> Results </header>
<ul role="listbox">
<li role="presentation">
<div role="option">
<div> primaryText </div>
<div> sencondaryText </div>
</div>
</li>
</ul>
</section>
UPDATE:
As mentioned here:
https://www.w3.org/TR/wai-aria-practices-1.1/#presentation_role
Any children of the role="option" would behave as if they have role="presentation" applied to them, so doesn't matter whether they are divs or spans or heading tags, the semantics would be removed.
should these list items simply be divs, or is there a better semantic element which can be used?
<li> is certainly one of the best fit for the items of your list box, except if individual results are quite long (see below) with your third question.
Is there a more semantic way to represent the primary and secondary text?
As far as I know, no. You may use <dl>, <dt>, <dd> instead of <ul>, <li>.
Both are correct solutions, none is better than the other, between the two.
In a similar scenario, when search results are shown, I have seen each search result is an <article>, the title is either <header> or <h1>, and the secondary
text is regular <div>. Does that structure make sense here?
It depends on how the results are going to be navigated.
If you are in the context of a form and if the results are navigated through by using arrow keys, which is the case for a typical combobox, the construction with <article> and headings is much less appropriate.
If you enter something to search, and then go out of the form to read the results, then <article> and headings is the best option, much better than simple <ul> <li>, because screen reader users can use keyboard shortcuts to navigate by heading or by section.
The length of the primary and secondary texts might be a criteria to help you decide which is the best option for your case.
For example, Google search results are used like the later, that's why they use a markup with headings.
Also, in some cases the results need to have a title, for example: "Results" In that case I usually change the structure to:
...
In this case would it make sense to use a like this
Yes, in this case it makes perfect sense.

Should I include the "menu button" inside the nav tags?

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.

Semantic HTML5 for UI elements

With HTML5, there were many additional elements added for structuring documents like blog posts or long texts. But what I have problems coming up with is a semantic way of structuring UI components.
On a typical webapp, you have many different components such as modals, button elements, interacitve forms, containers, and so on. Often, I see those things being constructed using div and span only or by misusing header, footerand nav elements and I get the feeling I missed something out.
Is it really semantic to create all structural, not content-related elements using the div element only? Will there be a more diverse element choice in the future?
EDIT: Here's a short example of what I mean:
<div class="modal foo">
<div class="inner wrapper">
<div class="upper bar">
<div class="inner">
<div class="window-name">
<span class="upper heading">
<h1>Foo</h1>
</span>
<span class="lower heading">
<h3>Extra Baz</h3>
</span>
</div>
<div class="buttons">
<div class="button close"><span class="icon"><i>×<i></span></div>
<div class="button maximize"><span class="icon"><i class="fa fa-maximize"><i></span></div>
</div>
</div>
</div>
<div class="content well">
<!--
Whatever happens inside the modal window named foo.
Pretty sure it needs many divs as well, though.
-->
</div>
<div class="lower bar">
<div class="buttons">
<div class="button help"><span class="icon"><i>?<i></span></div>
</div>
<span class="info">
<p>Enter your barbaz.</p>
</span>
</div>
</div>
</div>
The last W3C working draft for HTML 5.1 was released two days ago, on April, 13, and it is "semantic-centered": see
http://www.w3.org/TR/html51/Overview.html
It is an interesting reading, while waiting to have all those fancy things implemented by the most common browsers.
Is it really semantic to create all structural, not content-related elements using the div element only?
Not in my opinion. Even without to cite "the media is the message", everything has something to do with the content, even "open" and "close" buttons allowing users to see the content.
Will there be a more diverse element choice in the future?
Of course! And with a lot of proprietary prefixes, as usual, just to keep our life busier.
Ignoring div and span elements (which are meaningless, except for the case of specifying some meaningful attributes), your snippet consists of this:
<h1>Foo</h1>
<h3>Extra Baz</h3>
<i>×</i>
<i></i>
<!-- content -->
<i>?</i>
<p>Enter your barbaz.</p>
This is what your content looks like from the semantic perspective. Not very clear what gets represented here.
Using a heading element for a subtitle (h3 in your case) is not appropriate. (Or, if it’s not a subheading but really a new/own section, don’t skip a heading level; but I’m assuming the former.) Use one heading element, and use p for the subheading, and group them in header.
Using i elements for adding icons via CSS is not appropriate. Either use CSS only (with the help of existing elements), or, if you have to add an empty element, use span.
Using span/div elements for buttons is not appropriate. Use button instead.
As you are already using a heading element, it’s recommended to explicitly specify a sectioning content element. Depending on the context of this content, it may be article or aside (or nav if it’s for navigation), but in all other cases section.
Following this, you’d get:
<section>
<header>
<h1>Foo</h1>
<p>Extra Baz</p>
</header>
<button>Close</button>
<button>Maximize</button>
<!-- content -->
<button>Help</button>
<p>Enter your barbaz.</p>
</section>
Now you may add header/footer elements for those parts that are not part of this section’s (not this document’s, it’s only about this section!) main content.
You may, for example, enclose the maximize/close buttons in a header (however, opinions if this would be appropriate differ).
HTML 5.1 will probably have a menu element and a dialog element, which might be useful in this case.

Controlling elements with the same ID differently on different pages

It's my understanding that classes should be used for elements that will appear throughout a website, whereas IDs should be for truly unique elements.
I have a website built on a mapping platform. There is a div on the home page #map which is really front n centre of the whole website. So I played around with and edited the CSS till I was happy with how it looked on the home page.
But, when someone adds content (called a report), the report view also uses this same div with id map.
Is it possible to manipulate divs of the same ID differently? The map on the home page is 700px whereas the one on the report pages should be about 300px.
The map html on the home page is:
<div class="map " id="map"></div>
<div id="mapStatus">
<div id="mapScale"></div>
<div id="mapMousePosition"></div>
<div id="mapProjection"></div>
<div id="mapOutput"></div>
</div>
<!-- / map --><div class="slider-holder">
<form action="https://example.com/main" method="get">
<input type="hidden" value="0" name="currentCat" id="currentCat"/>
<fieldset>
<label for="startDate">From:</label>
<select name="startDate" id="startDate"><optgroup label="2013"><option value="1375329600" selected="selected" >Aug 2013</option><option value="1378008000">Sep 2013</option><option value="1380600000">Oct 2013</option></optgroup></select>
<label for="endDate">to:</label>
<select name="endDate" id="endDate"><optgroup label="2013"><option value="1378007999">Aug 2013</option><option value="1380599999">Sep 2013</option><option value="1383278399" selected="selected" >Oct 2013</option></optgroup></select>
</fieldset>
</form>
</div>
And the html surrounding the map on the report pages is:
<div id="report-map" class="report-map">
<div class="map-holder" id="map"></div>
<ul class="map-toggles">
<li>Smaller map</li>
<li style="display:block;">Wider map</li>
<li>Taller map</li>
<li>Shorter Map</li>
</ul>
<div style="clear:both"></div>
</div>
</div>
I tried using the selector
#report-map, .report-map {width: 300px;} to override but with no success.
Can anyone see how I could do this? I need the main map on the home page to remain 700px and the map on the report pages to be 300px.
The site is here if anyone wants a peek: http://tinyurl.com/c8djrvr
An element ID only needs to be unique within one page. If you have the same ID on different pages, you're not doing anything wrong as long as each page has exactly one element with that ID, no matter which element that may be.
To select #map only when it occurs within #report-map, simply use:
#report-map #map { width: 300px; }

Semantic use of <nav> in HTML5 with search form element

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.