Both bar338 and Crusty left in the Advanced Search in the HTML.
<ul id="search-nav"> <!-- Did not use <nav>
because this navigation is secondary, it is not of "Primary Importance" -->
The authors and the doctors seem to continually wish-wash about what a <nav> really means and when to use it.
Reading Bruce and Remy's (now too old) HTML5 book, they were slapping navs on everything and anything that even remotely looked like some kind of navigation (except loose anchors in the body text)... even suggesting maybe a search form should have nav.
Luckily it seems the froth has faded and more sanity has prevailed, but I've been considering "nav" for all navigation lists, but only adding the ARIA landmark of "navigation" to the primary navigation lists.
Well, if I used <nav> and HTML5 which I don't primarily because these new semantics are not in the browsers today nor in the AT and the bugs are plenty and while future-proofing a site sounds nice, they also need to work today, and today mixing ARIA and HMTL5 (as opposed to ARIA and HTML4) does not work.
So I suppose for this example, saving <nav> elements for primary navigation might be the best thing.
HTML5 lets you stuff inlines directly into a form... you know, kinda like it lets you stuff inlines directly into a blockquote and lets you wrap anchors around blocks. It's gettin' crazy, man!
As a side note, for anyone who has discovered the "search" ARIA role... do not put it on inputs, since this appears to override the input's role of... "input". And don't bother putting it on search forms either, since it might hide the form in some screen readers and isn't a navigable landmark anyway (plus the moment a form is announced, if you go to it you'll hear right away that it's search).
<input type="search" id="search-text" name="search-text" autocomplete="off" list="search_list" autofocus required aria-required="true">
You gotta ask yourself what you did wrong if it's not obvious to the user that typing a search term is required. We don't have "You must type stuff into this form in order for it to work" above all our other forms, do we? "Required" is valuable when users aren't sure what is required and what isn't, because the form mixes required and optional fields. (though if there are multiple inputs and they all happen to be required, it's good to state "all fields are required" beforehand... but who has a form made entirely out of optional fields???)
I find myself raising hairs at the thought that if I am using assistive technology or a linear browser, that the page may force me to miss whatever comes before the search input... even on a page whose whole purpose might be search, like Google.
The OP can't do anything about this, but I would rather that autofocus is something the user can set in their browsers rather than the author. The first time I come to your site I may want to read/explore everything like I normally do. After the second, third, whatever time I visit I may indeed want the benefit of just jumping directly to search (which I cannot do in Google since I have to tab through all the site-garbage first... but I use DuckDuckGo anyway). Would be nice if it was a setting I control rather than one the author controls.
Okay autofocus rant over : )
<!-- Should I use <h2>
in place of <header> for each of the linked results? -->
<!-- Chose not to use <section>
for preview because it will be so short (1-2 sentences) -->
I'd use heading tags instead of headers since the document outline of HTML5 ranks heading tags based on nesting... if you're not presenting <article> or <section> tags, then use an appropriately-leveled heading tag instead.
Also agree with Crusty about not using an ol for the results. The user tends to assume the first result is the most relevant according to the search engine, and the user often disagrees with the search engine by clicking on something that's NOT the first result
Tho DuckDuckGo uses the zero-click boxes as a way of stating "I think this was your preferred result" which is separate from the results list.
And I do consider it a results list, so I would use a list. I'd be cool with them having bullets next to them, which would fit Tommy Olsson's "bullet test" to determine if they belong in a list.
Though just a linear row of headingtag-paragraph groups would also be fine.
<div class="preview"></div> <!-- Small sample of pages content -->
Ah, have you met the <details> element? I just saw a working implementation in Chrome. Browsers who don't support simply show everything, while <details> is meant as an HTML version of "show a little bit... show more if user requests".
<ul class="pagination"> <!-- Not sure if I should use the <nav>
element here -->
I wouldn't if you are operating on the idea that <nav> is reserved for primary navigation. Having a single "next page" link before the pagination list allows anyone who got to the bottom easy access to the next page.
Though I guess the question is, what's Primary Navigation? Is it navigation of the site itself, or navigation of some main application on the site, without which there would be no site and no point? I dunno.
Since my sites aren't applications, my <nav>s would be site navigation, and I usually have two of those (main navigation and small-print navigation).
I would consider a list of checkboxes instead. Suppose I want results that are both images (png/jpg/gif/svg) and media (videos etc)?