Make Navigation accessible for text readers - html

(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.

Related

Accessibility: wrapping list items in buttons for better keyboard navigation/accessibility

I frequently have use cases in my application where i need a list of items which need to be interactive, like clicking on an item should perform some action.
I usually wrap up the list item (li) content in a button, which kinda makes sense as the list item is interactive. This also helps with making the list items keyboard accessible with TAB. But, as much as i understand, this also poses a problem that a keyboard user would have to TAB through the whole list to get out off it. Would it be better instead to manage focus in the list using something like roving tabindex and allow ARROW keys for navigation within the list and TAB to focus in and out of the list ?
I am seeking validation for whether or not this is a good way to implement this kind of functionality, and pointers to any real world implementations
My real world experience is that you shouldn't put anything inside a button which is not related to a button semantic role. And strictly speaking, you shouldn't put list items inside anything that isn't a list.
Putting the buttons inside the list items would be better, but read on.
A list of items that 'perform some action' is (semantically) a menu, (or perhaps a toolbar which is much like a menu, but doesn't have the open/close feature expected of menus).
So you should get good results if you put role="menu" on the element containing the buttons, and role="menuitem" on the buttons.
Don't put the button that opens the menu (the "menu button") inside the menu. (I've wasted a lot of time on this).
There is no "menubutton" role. Just use an html <button> or something else with role="button". Then associate the menu button with the menu using aria-controls="yourMenuID". There are some other aria attributes you should use too, such as aria-expanded="true"/"false" (on both menu and menu button - and kept in sync with javaScript) and aria-haspopup="true" on the menu button.
If you take a little care, you can use CSS attribute selectors to style the menu according to the aria attributes. For example:
*[role='menu'][aria-expanded='false'] {
display:none;
}
*[role='menu'][aria-expanded='true'] {
display:block;
}
And yes, you should manage focus. Either with the roving tabindex technique or aria-activedescendant. I prefer the latter because it makes things more explicit but roving tabindex seems slightly more common. Both techniques are well-supported across a range of browser/AT combinations.
There are clear recommendations for how accessible menus should behave (with links to example code) here. Menu button and toolbar behavior is described further down in the same document. It's an excellent resource.
Good luck.

No-JS mobile navigation with good accessibility

Right now I am working on the website of a project working with handicapped people and looking for a mobile navigation with great accessibility and a no-js fallback. First i was thinking about using the :target-pseudoclass to open and close the navigation, but I cant open a sub-navigation this way since the main-nav closes if it looses the target. Then I was looking at the checkbox hack but there I get a roblem with the accessibility since Checkboxes or Radio-Buttons have another use case, a different way of control and also they are form elements, you should not use outside a form. Is there any clean and accessible way to get such a navigation working?
I hve a navigation like thw following:
<nav>
<ul>
<li>
Link
<ul class="sub-menu">
<li>
</li>
</ul>
</li>
</ul>
</nav>
The navigation can be quite big so I dont want the sub menus to be visible the whole time (if possible), so that you dont need to scroll such along time.
This is not a question to give me the exact code, I just need some hints to find a way for an easy accessible no-js mobile navigation with sub-menus (maybe with an example)

Should navigation bars always be implemented as lists?

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

Are login/signup links a semantic use-case of HTML5 <menu>

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.

Hidden table of contents for screen readers

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.