My site's h1 is also the "home" link, so obviously I put it within the nav tag. The other links in the nav were originally put in an unordered list, like this:
<nav>
<h1>Site Name</h1>
<ul>
<li>Nav Item 1
<li>Nav Item 2
<li>Nav Item 3
</ul>
</nav>
Standard, right? As you can imagine, on subpages, the nav stays the same but the "active" class gets applied to the relavent Nav Item.
Here's the problem. At mobile screen widths, the nav compresses into a dropdown menu where the "active" link is the only link shown above the drop. That's fine on the homepage where the h1 is the active link, but it seems like my CSS is going to get super messy on subpages.
I've been noticing that some well respected frontend developers use list items free of ordered/unordered lists. These are folks who hold semantics in high esteem, so it made me wonder they might be thinking...
So I'm stuck. It seems wrong to put my h1 in the ul, but this also seems wrong:
<nav>
<li><h1>Site Name</h1></li>
<li>Nav Item 1</li>
<li>Nav Item 1</li>
</nav>
I know that I can get the LOOK of what I want to achieve almost any way I markup the HTML, but I'd like to do it as semantically as possible while avoiding a CSS/JS nightmare / or any hacks.
The standard is clear :
Permitted parent elements :
ul, ol, menu
Any other use should be avoided as a browser might very well not support it.
The fact the norm prohibits it means there is no accepted semantic, apart the one each developer invents for his own use.
Related
I am trying to write a theme with multi menu at the header, should i use multi nav tag for each of them? Or wrap them all inside a nav tag?
Here is the example codepen.
header-a wrap everything inside nav tag.
header-b wrap menu and the element that between menu inside nav.
header-c wrap menu inside nav by each.
header-d add nav tag inside each bar to wrap everything inside bar.
Which method will be good in this case?
Thank you so much.
I think this is about semantics.
A nav element should wrap items that are part of the same navigation structure.
For example:
<nav id="topNav">
<ul>
<li><a>Home</a>
</li>
<li><a>About</a>
</li>
<li><a>Contact</a>
</li>
</ul>
</nav>
<nav id="sideNav">
<ul>
<li>Products</li>
<ul>
<li><a>Oranges</a>
</li>
<li><a>Apples</a>
</li>
<li><a>Pears</a>
</li>
</ul>
</ul>
</nav>
<nav id="socialNav">
<ul>
<li><a>Facebook</a>
</li>
<li><a>Twitter</a>
</li>
<li><a>LinkedIn</a>
</li>
</ul>
</nav>
See this article
The <nav> tag defines a set of navigation links.
Notice that NOT all links of a document should be inside a <nav> element. The <nav> element is intended only for major block of navigation links.
Browsers, such as screen readers for disabled users, can use this element to determine whether to omit the initial rendering of this content.
It does not seem there is an exact answer to this. Rather, the correct answer depends on how you want the semantics of the website to be read.
Try looking at the following sources:
http://html5doctor.com/nav-element/
https://stackoverflow.com/questions/14100279/html5-semantics-for-multiple-nav-
elements
http://w3bits.com/css-responsive-nav-menu/
There is information that states that all 4 of your options would be semantically correct. What you need to think about is how you want the navigation to be interpreted: 1) Should it be seen as one main menu? Then you would want header-a; 2) Should the menus be seen as groups of related menus? Then any of header-a, header-b or header-c would work.
I know I have not exactly given you an answer to your question but from what I can work out there is no straight forward answer.
Hope this helps in some way.
I have tried without success to make a dropdown list without the content are getting pushed down under the dropdown, i can't get it to work, i have tried with float and display wont work :s
Anyone have any suggestions?
It really doesn't seem like you have come a long way at all, so I'd be hesitant to just write a long answer to explain how dropdowns work, and instead suggest that you look up tutorials. You are probably going to need to use javascript to make the dropdown "clickable" to open and close it.
But I'll try to start you off in the right direction!
To avoid making the dropdown move other elements, it needs to have the css attribute "position:absolute;" and the parent element (the element the menu is inside) has to have the attribute "position:relative;"
<style>
.menuButton{
position:relative;
}
.dropDown{
position:absolute;
bottom:0;
}
</style>
<div class="menuButton">
<p>Click me!</p>
<div class="dropDown">
<ul>
<li>Option 1</li>
<li>Option 2</li>
</ul>
</div>
</div>
Though further, I'd suggest you use javascript to toggle the ".dropDown" class' attribute "display:none" on and off. You will most likely learn better by googling, because I dont think I have teach you, and people are probably not going to give you a lot of help here on such a basic question
(navigation layout picture)
I have the navigation-layout of tabs and sub-tabs, which i want to make accessible via text-reader/lynx. It consists of the main pages "Startseite", "Über", "Interessant", "Orte", as well as the sub-pages "Linköping", "München" and "Baustelle". The logical structure would thus be:
Startseite
Über
Interessant
Linköping
München
Baustelle
Orte
But since I use a layout of several div-tags, it only yields this in lynx:
Startseite
Über
Interessant
Linköping
München
Baustelle
Orte
The questions (or solutions I don't know how to implement yet) now are:
(1) how do I improve my layout to make it accessible via text-reader/lynx
... or
(2) how do I adjust a layout of unorderd lists and sub-lists (see code) too look like my current tabbed navigation-layout?
<nav>
<ul id="mainpages">
<li>Startseite</li>
<li>Über</li>
<li>Interessant
<ul id="sub1">
<li>Linköping</li>
<li>München</li>
<li>Baustelle</li>
</ul>
</li>
<li>Orte</li>
</ul>
</nav>
keep in mind that my main tasks is making it text-reader/lynx accessible. I though of using a layout like this, since it is easily styled with #some_ul_id {display: inline-block}:
<nav>
<ul id="mainpages">
<li>Startseite</li>
<li>Über</li>
<li>Interessant</li>
<li>Orte</li>
</ul>
<ul id="sub1">
<li>Linköping</li>
<li>München</li>
<li>Baustelle</li>
</ul>
</nav>
My third question is:
(3) Is this good practice? Should I do it?
It is the easiest way, though solution (2) would be nicer, since it is more logical.
From an accessibility perspective, the way to markup the solution so that it semantically represents what you are trying to achieve is to use the WAI-ARIA menubar, menu and the various menuitem roles. You should also use the aria-haspopup="true" attribute to show sub-menus and the aria-expanded attribute to track when the menu is expanded. In order to achieve the semantic markup of the hierarchy, you will want to have hierarchical lists as this is the easiest way to represent the hierarchy in an understandable way.
Here is a link to a full dynamic ARIA menu example http://dylanb.github.io/bower_components/a11yfy/examples/menu.html
You will need to ensure that each menu item is keyboard focusable using an href attribute on an anchor tag will do this for you as long as you look for the 'click' event and don't do anything funky with mousedown/mouseup etc.
One way to achieve this could be to absolutely position the sub-menu – of course that requires that you know beforehand that there’ll be enough space, so that items don’t go over multiple lines (resp. you have an alternative at hand for smaller screens via media queries).
So you would position the outer ul (or the nav itself) relative, and then on :hover over a main menu item you make the sub-ul visible, that is positioned absolutely in such a way that it comes to lay underneath the line of main menu items – like this: http://jsfiddle.net/0rpyLqtn/
Other slight variations are easily imaginable; if you don’t want “blank space” underneath the single line of main menu items, you could f.e. give that ul a border-bottom instead of a margin-bottom, and have the border color of it visible at all times, like this: http://jsfiddle.net/0rpyLqtn/1/
Since you have accessibility in mind, you might also want to pay attention to how this kind of menu behaves on devices that do not have a “mouse” as input device. Getting such a menu to be accessible via keyboard can be tricky, and on touchscreens a menu based on :hover might not work that well either. Anyhow, such issues have been discussed on the net already, so with a little research you should be able to find solutions/workarounds for these issues as well.
I'm completely new to ARIA, so please be gentle if this is a stupid question. Is it proper to give a container div the role of "main" if it contains a sidebar? If I have a nav element floated inside my container div, will adding an ARIA role of "main" to the container div confuse screen readers or is this ok?
Here is an example of the HTML to explain further.
<div id="container" role ="main">
<h1>Content Here</h1>
<nav id="sidebar">
<ul>
<li>Foo Item 1</li>
<li>Foo Item 2</li>
<li>Foo Item 3</li>
</ul>
</nav>
<p>More content</p>
</div>
I provided a link to a question that was just asked, my answer covers most of it.
Since you are using HTML5, you automatically use HTML 5.1, which has the <main> tag. Which can replace <div role="main"> due to the fact that some HTML5 tags have certain WAI-ARIA attributes by default.
Proper HTML tagging of
<div id="container" role ="main">
<h1>Content Here</h1>
<nav id="sidebar">
<ul>
<li>Foo Item 1</li>
<li>Foo Item 2</li>
<li>Foo Item 3</li>
</ul>
</nav>
<p>More content</p>
</div>
would be
<main>
<nav role="navigation">
<ul>
<li>Foo Item 1</li
<li>Foo Item 2</li>
<li>Foo Item 3</li>
</ul>
</nav>
<section>
<h1>Content</h1>
<p>....</p>
</section>
</main>
Or pop the navigation outside, wrap it in a <div role=complementary>. Take a look at this WAI-ARIA landmark example
Chris said
Navigation skip links(the alternative) are usually clunky, and either wreck the visual of the page, or create weird keyboard navigation with links that are hidden unless they have focus. If your sidebar is short, and/or contributes to the content of the page, sy by providing an outline of other in page content, I would suggest that it is acceptable.
Skip links and navigation "menus" are two different things. Yes if you have only a short navigation or things that get focus (links, form controls, stuff with tabindex='1') before getting to the main content, you could probably get away with no skip links. While WAI-ARIA is supported by a good portion of assistive technology, it is not exposed to every user. So people getting to your main content with a screen reader can use either the Landmark navigation or another method to get there, people who don't use the mouse (physical disabilities) still have to press Tab numerous times. Skip links should either be visible always or become visible as they gain focus.
Reply to OP's comment
Technically at this point we are talking semantics, and that convo could go no where. The true difference is small, and won't break anything unless you are super hardcore about stuff. Having element 4 (which should be an <aside>) inside the <main> means this content is specifically for the main topic of the page. Outside, means the element is for the site as a whole.
Could somebody mis-interpret it? Maybe, but if you are using good language, this shouldn't be a big issue.
If I put it outside, could people miss it copletely? Sure, but this is possible in any design though. You could pop on a WAI-ARIA role navigation/complementary to catch people browsing that way. Using headings is another.
It depends on how "inconvenient" your nav bar is, and what the contents of your navigation bar are. The intent behind the "main" role is to circumvent the need for navigation skip links by providing ATs a landmark for the start of the "content" of a given page. Navigation skip links(the alternative) are usually clunky, and either wreck the visual of the page, or create weird keyboard navigation with links that are hidden unless they have focus. If your sidebar is short, and/or contributes to the content of the page, sy by providing an outline of other in page content, I would suggest that it is acceptable. However, if there are a lot of links in the sidebar, and they aren't links you would deem as being part of the "content" of the page, you should place the main role closer to the content segment of the page. In general, consider accessibility an extension of usability, and use your best judgment as to where the most appropriate place for your "main" role to be. As long as you are using a given role for the correct purpose, there is no factually correct answer to your question. There are definitely inappropriate uses of Aria roles, but both of the uses you have outlined are perfectly acceptable for "main".
I've seen on a couple of sites that they will include a navigation section at the top of their page, with internal links to other parts of the page, so that users with screen readers can quickly jump to the content, menu, footer, etc. This "nav" element is moved off-screen with CSS so regular users don't see it.
What's the best way to implement this? That is, what's the most accessible and least-intrusive for screen-readers? Here is what I've been playing with:
<div id="nav">
Jump to section one
Jump to section two
Jump to section three
</div>
<!-- versus -->
<ul id="nav">
<li>Jump to section one</li>
<li>Jump to section two</li>
<li>Jump to section three</li>
</ul>
The first has the benefit of being much cleaner in its markup, but isn't exactly semantic. Also, it appears like "Jump to section one Jump to section two Jump to section three". I know that the visual appearance isn't important, since it's hidden, but does that affect how it is read out? Are there appropriate pauses between each one?
The second is a bit more verbose in its syntax, but hopefully more descriptive.
Which out of these is better, and is there an even better way?
You can download a plugin for Firefox called Fangs (in reference to the real screen reader Jaws). It will produce text of which Jaws would read. It's very handy. I'd go with a good semantic layout over just the links one after the other. I'd also hide it with... something like
#nav {
position: absolute;
left: 0;
top: -9999px
}
Using display: none may not be read out in some screen readers.
In my own sites, I've generally done this:
<div id="section-nav">
<p>Jump to</p>
<ul>
<li>Section1</li>
</ul>
</div>
Keep in mind that screen readers usually announce hyperlinks as such. Which means that your first example won't be read out as "Jump to section one jump to section two jump to section three" but rather as "Link: Jump to section one, link: Jump to section two, link: Jump to section three" or some such.
(Personally, I would still go with the second, semantic option, but that's just my personal preference.)
You should place the links in an with an id (or class) of #nav. This gives those using screen readers a heads up that the content is a list of links: "This is a list with three items: A link, 'jump to section one, a link 'jump to section two'..."
Placing the "ul" in a "div" with an id of "#nav" is functional, but the div is not doing anything other than wrapping the "ul" for identification. It is cleaner to just id the "ul" and leave the "div" out. The following code is the best (I think). Clean and to the point.
<ul id="nav">
<li>Jump to section one</li>
<li>Jump to section two</li>
<li>Jump to section three</li>
</ul>
To remove the text from the page with css, you use:
ul#nav {
position: absolute;
left: -9999px
}
With a good semantic layout, you don't need it. You can make the navigation elements you're already using compatible with the screen reader. The 2nd option is normally how you make that happen. You can style the list items to match what you're currently doing.
The best way to do what you have requested is to use the <ul> with the anchors inside them.
However there are some bugs in WebKit that will cause the focus to not actually shift to the targeted element, so you will also need to attach an event handler to the links so that the focus shifts. This will also require the target to be tab focus sable (tabindex="-1" will work for this).
However, if you have good heading structure on the page, then the screen reader user can navigate the page without needing this navigational menu you are creating. In fact this menu might be more useful for keyboard only users who do not have a screen reader. In that case, you will want to make it appear on focus so the keyboard-ony user can see it.