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)
Related
I have a primary navigation where some items can contain a secondary nav. I would like to make my webiste as accessible as possible so I'm looking for the best solution to show/hide the secondary nav.
What I've come up with is:
the user gets to the <a> tag with a secondary nav with TAB & hits enter
the secondary nav opens up
if they hit enter on the primary <a> tag again, they get redirected to that page
if they hit TAB, they go to the first item in the secondary nav
I've already accomplished this using javascript. What I would like to know is whether there is a better approach to this & also:
I've added aria-controls and aria-expanded attributes to the primary navigation <a> tags. Is that semantically correct?
This is what the simplified markup looks like:
<nav>
<ul>
<li>
Home
</li>
<li>
Other page
<nav>
<ul id="secondary-nav">
<li>
<a></a>
</li>
<li>
<a></a>
</li>
<li>
<a></a>
</li>
</ul>
</nav>
</li>
</ul>
</nav>
Interestingly, the ARIA standard supports aria-expanded (and consequently aria-controls) on the link role. But it does have this to say as well:
If pressing the link triggers an action but does not change browser focus or page location, authors are advised to consider using the button role instead of the link role.
Since at first press the <a> will neither change focus, nor page location, it should be a button at the start. You could achieve that by adding role="button".
It might become a link when pressed, but changing role and behaviour of an element is disorienting for a lot of people and I’d expect especially for users with cognitive disabilities.
Disclosure Navigation Menu Pattern
So I would recommend sticking to established patterns, like the Disclosure Navigation Menu
It clearly separates the disclosure button from the links, which is way easier to understand.
What to do with index pages
I am assuming that your solution comes from a menu design that originally did not take into account keyboard and touch interactions, but only mouse, where hovering opens the submenu, and clicking the link.
The pattern that I used most of the time to solve that issue is adding a link to the index page in the submenu, and name it the same as the button, or “Overview”, as they did in the example posted above.
For you, that would result in
Other page
Overview
…
(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.
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.
I am trying to edit the SharePoint 2010 ribbon to add links along side the tabs. So I would want to just have elements exactly to the right of the 'Browse' and 'Page' tabs. It should look like they are other tabs, but they will function like links.
I have searched the web extensively to try and accommodate this, and I'm not sure if the answer is editing a custom master page or deploying something through Visual Studio. Either way, I am unable to get something to appear up in that area.
Below is a screen shot of what this might look like.
Also, any help with moving the user and their menu to the left would also be much appreciated.
SharePoint won't allow you to modify the ribbon in this way. You will have to use jQuery or similar to add a new list item (li) to the tabs unordered list (ul). You can find the list with firebug:
<ul class="ms-cui-tts" unselectable="on" role="tablist">
<li class="ms-cui-tt" id="Ribbon.Read-title" unselectable="on" role="tab">
<li class="ms-cui-tt" id="Ribbon.WebPartPage-title" unselectable="on" role="tab">
</ul>
Please note that this kind of solutions are not recommendable (Hard to maintain, unsupported, and this probably won't work in the next version of SharePoint).
To move the user and the menu to the left, just rearrange the controls in a copy of the v4 master page through SharePoint designer.
#alfonso is right. Just to add more for others who might want to add the tabs using jQuery
$('<li class="ms-cui-tt ms-browseTab" style="line-height" unselectable="on" role="tab"><a class="ms-cui-tt-a"><span class="ms-cui-tt-span">You custom link here</span></a></li>').appendTo('ul[role="tablist"]');
That will add an item to the right of the "page" tab