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.
Related
I'm modifying a navigation menu, just thinking about best practices, can I have div tags under nav tag directly?
<nav>
<ul>
<li> Home </li>
<li> About </li>
</ul>
<div></div>
<div></div>
</nav>
Short Answer
Nothing wrong with adding <div>s to a <nav> element. As long as their content is accessible you will be fine. Obviously from a semantics / logical flow perspective anything within the <nav> element should be related to navigation.
Knowing your exact use case would be useful to offer exact advice, so the below is just general advice and best practices.
Long Answer
From a technical perspective the <nav> element is just a sectional element, similar to a <region> and accepts flow content, which is pretty much everything other than sectional content.
Best practices
From an accessibility perspective a <nav> element is expected to contain links and buttons (links for going to new pages, buttons for actions on the same page) and not much else except for supporting elements.
It is a good practice to add items in an unordered list just because it then announces how many items there are to a screen reader user, but the accessibility of the site won't suffer massively if it just contains links.
With that being said if you decide to add some <div>s to the <nav> element the worst case scenario is that screen reader users skip over them as they aren't expecting them to be there, they won't negatively affect accessibility (unless their content has accessibility issues of course!)
Finally make sure that the content of those <div>s is related to navigation in some way, otherwise they do not belong in the <nav>. If you are using them for some decorative element then ensure they have role="presentation" and aria-hidden="true".
For additional information here are some best practices with navigation:
Screen reader users will often navigate a page in different ways.
Knowing how screen reader users orientate and navigate through your site is the easiest way to know what you should implement.
By section
Some will iterate through sectional elements. For this reason it is probably advisable to have a hidden heading and label the section with that heading (the same as you would do with <section> elements).
This is less important if your site only has one <nav> element, but very important if you have multiple <nav> sections.
.visually-hidden {
border: 0;
padding: 0;
margin: 0;
position: absolute !important;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 - a 0 height clip, off to the bottom right of the visible 1px box */
clip: rect(1px, 1px, 1px, 1px); /*maybe deprecated but we need to support legacy browsers */
clip-path: inset(50%); /*modern browsers, clip-path works inwards from each corner*/
white-space: nowrap; /* added line to stop words getting smushed together (as they go onto seperate lines and some screen readers do not understand line feeds as a space */
}
<nav aria-labelledby="mainMenuHeading">
<h2 id="mainMenuHeading" class="visually-hidden">Main Menu</h2>
<ul>
<li> Home </li>
<li> About </li>
</ul>
<div></div>
<div></div>
</nav>
Navigating by links
Screen reader users will often iterate through all the links on a page to get a feel for what information there is on a page.
This is why we add the links to an <ul> and within a <nav> element so they know how many navigational items there are.
This is one case where having a <div> in your <nav> element might be a bad idea, a screen reader user may check the links in a <nav> element and then always skip the navigation (assuming you have skip navigation links - which you do I hope! hehe.)
If the information is important then sitting it outside the <nav> may be a good idea as there is a higher chance of it being discovered by screen reader users.
Navigation by headings
Some screen reader users (majority) use headings to navigate the page, <h1> to <h6>.
That is why we named the <nav> section using a heading earlier (in the "By section" heading), it benefits those users.
This is not an exhaustive list of ways screen reader users navigate and it isn't just screen reader users we need to think about but hopefully it should give you some ideas of best practices.
Conclusion
That was a very long way to say, sure you can add nearly anything to a <nav> section. I just hope the above both illustrates that you can (and should) add additional items to a <nav> element for accessibility such as headings, but at the same time do not put any "mission critical" information within a <nav> element as it may not get discovered by screen reader users due to expected behaviour.
I think it's fine as long as you pay attention to the accessibility.
The HTML Living Standard has an example of a nav containing other elements (p,a,h1) and vaguely says that it "can hold other elements" so I don't think there's any specification issues here.
Additionally, Bootstrap does it in their own Nav example so I think we can also safely say that it's common practice.
I think the main consideration here is from an accessibility perspective. Screen readers will often look for a list of links within the nav section, so as long as you still have that ul element holding the links, I think it's relatively safe.
(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".
Firstly, very sorry if this is not a "true" stackoverflow question. But it's something I've always wondered about...
When you code a navigation bar for a site (html) I've read that it is very good practice, if not the ONLY practice to implement it using the list tag. e.g.
<ul>
<li> Home </li>
<li>About Us</li>
<li>Blog</li>
<li>Contact Us</li>
</ul>
And then apply the necessary styling that displays the list horizontally and so on and so forth.
But is this standard set in stone or does one only do it this way if it's the best option to do so... Because currently I have a navigation bar to do that is not your 'standard' nv bar so to speak, and it's a little bit of a mission to implement it as a list. A few link tags placed in some divs will work nicely. But of course I do not want to do this that method if it's going to make people point and laugh at me...
Thanks in advance!
Why use lists for site navigation?
Part of designing a site using web standards involves the use of semantically correct code. To quote "Brainstorms and Raves":
Good HTML structure is based on logic, order, and using semantically correct markup. If you have a heading use the heading element, beginning with the H1 element. If you have a paragraph, use a paragraph element. If you have a list, use a list item element.
At a structural level, site navigation is simply a list of links to other areas of the site. Therefore, the best method for marking up site navigation is (arguably) to use a list element.
If you use good HTML structure, then text-based browsers, screen readers, non-CSS supporting browser, browsers with CSS turned off and search bots will be able to access your content more easily.
A nice article on this is here
Live Example
HTML5 <menu> element
HTML5:
<menu type="list">
<li> Sign Up </li>
<li> Log In </li>
</menu>
I want to add a signup / login menu to my website.
Would using <menu> be semantic?
Should I use <ul> instead?
Edit: I'm using semantic HTML5. Browser support is irrelevant.
As I'm sure you're aware:
The menu element represents a list of commands.
It really just depends on how you define "list" and "commands." Are "Login" and "Sign up" commands? Or are they list items? Personally I think they're commands. A list (ul or ol) is more akin to something longer, two items just don't seem to make a list, to me. Login and Sign up seem like commands because they're what Stephen Krug, in Don't Make Me Think calls "Utilities":
Utilities are links to important elements of the site that aren't really part of the content hierarchy.
These are contrasted with what he calls "Sections":
links to the main sections of the site: the top level of the site's hierarchy [navigation]
This makes sense semantically: You use <nav> for Krug's "sections" (navigation) and <menu> for utilities or commands (Log in, Sign Up, Search, etc.)
I don't think it's going to matter too much. There are a lot of options you can choose, even the new <nav> tag. But an unordered list certainly isn't going to wreak havoc on your code or not pass HTML5 validation.
I still use unordered lists for my navigations. This includes websites with a top heading nav, sidebar, and footer links. But speaking in semantics, I would recommend the nav element over menu.