Recently I've been implementing ARIA into a web application and I found this question to be quite helpful in the improving the navigation parts.
After implementing this in all modules, I discovered this HTML validation error:
Attribute aria-selected not allowed on element a at this point.
Looking at the ARIA specification, I see that aria-selected is only used in roles gridcell, option, row, and tab. In my case, the role of the link is menuitem.
This is a representative sample of the HTML code:
<nav role=navigation>
<ul role=menubar>
<li role=presentation><a href='page1.php' role=menuitem>Page 1</a></li>
<li role=presentation><a href='page2.php' role=menuitem>Page 2</a></li>
<li role=presentation><a href='page3.php' role=menuitem aria-selected=true>Page 3</a></li>
<li role=presentation><a href='page4.php' role=menuitem>Page 4</a></li>
</ul>
</nav>
As you can see, this is taken on "page 3".
What is the correct ARIA role to use here?
you may also use aria-current="page" for describing current displayed page among navigation items.
I believe that aria-selected is for 'widgets' that are one-tab stop, like a set of tabs that you then arrow around to select. The selected aspect is about which one is in focus, not which page you are on.
I would check out this as a well tested example:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Menus/Horizontal%20(Internal%20Content)/demo.htm
From: http://whatsock.com/tsg/
For showing the current page I would probably use a more traditional method: Make it not a link. E.g:
<li><a href='page2.php'>Page 2</a></li>
<li><strong>Page 3</strong></li>
This also prevents people from clicking on the same-page link by accident (which I see quite often in usability testing). You can apply the same CSS to nav ul a and nav ul strong and then override the styling for the strong.
Short answer: you can use aria-current="page" or aria-current="location" to indicate the current link in a list of links.
Your pagination component could be improved in terms of accessibility (you can see this as a variation of the similar breadcrumbs pattern):
<nav aria-label="pagination">
<ol>
<li>
Page 1
</li>
<li>
Page 2
</li>
<li>
Page 3
</li>
<li>
Page 4
</li>
</ol>
</nav>
A few notes:
Use <nav> to automatically use the navigation landmark (<nav> is equivalent to <div role="navigation"> but shorter and more elegant)
Use aria-label to provide a meaningful name to the <nav> (most likely, you have more <nav> elements on the page and you should label each one accordingly).
Use to make the set of links structured. This can also help screen reader users as it will be announced as "pagination, navigation (next) list, 4 items, helping users understand how many pages there are.
Use aria-current="location"oraria-current="page"` current page of the list (this is most likely shown in a different style as the other pages, but we need to mark it for screen reader users).
Related
I have a simple question. Should the button, that I use to open/close my navigation menu be included in the nav tags?
The button itself is not helping in navigating but without him, there is no access to navigation.
<nav>
<ul class="nav">
<li class="nav__el nav__el-active">Home</li>
<li class="nav__el">Generic</li>
<li class="nav__el">Services</li>
<li class="nav__el">Blog</li>
<li class="nav__el">Contact</li>
</ul>
<i class="fas fa-bars"></i> //menu btn
</nav>
that's the example. Now the btn is in the nav, but it also can be like that:
<div class="topbar">
<nav>
<ul class="nav">
<li class="nav__el nav__el-active">Home</li>
<li class="nav__el">Generic</li>
<li class="nav__el">Services</li>
<li class="nav__el">Blog</li>
<li class="nav__el">Contact</li>
</ul>
</nav>
<i class="fas fa-bars"></i> //menu btn
</div>
At first glance, when reading this at WHATWG:
The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.
It seems to me that the button should not be included, as that's clearly not a navigation link.
Anyway, if you continue reading:
User agents (such as screen readers) that are targeted at users who can benefit from navigation information being omitted in the initial rendering, or who can benefit from navigation information being immediately available, can use this element as a way to determine what content on the page to initially skip or provide on request (or both).
With that in mind, it makes sense to include that button and any other non-link control you might have (usually in the header area) because if a screen reader user wants to...:
...skip the whole navigation, they also want to skip the other controls that are not links.
...jump straight to the navigation, they might also want to use some navigation elements that are not links.
If you check some of the examples at WHATWG, it looks like they are applying these criteria. The first example is:
<body>
<h1>The Wiki Center Of Exampland</h1>
<nav>...</nav>
<article>...</article>
...
</body>
Here, it makes sense not to skip the title on the page (to know where you are) but then skip all the navigation elements and jump straight to the content.
However, on the last one:
<nav>
<h1>Folders</h1>
<ul>
<li><a ...>... </a></li>
...
</ul>
</nav>
It would make sense to skip the Folders heading element if you are not interested in the navigation because it's actually part of it, the same way you put the heading of a section inside a section and not before it. The same applies to your menu button.
Some other examples of elements that might be part of the main navigation of the site, and thus go into <nav> are logos that link to the root of the site or search forms.
For example, LinkedIn is doing that:
Also, Bruce Lawson, who is part of the Accessibility Task Force, has the search inside the <nav> element on his personal website:
However, you can also find examples of the opposite. For example, AirBnB only includes some links in the <nav> element:
While in this case, I would have also included the search, that for me clearly represents the main way to navigate on their site.
Anyway, you could and should also use ARIA for accessibility and structured data / Schema.org markup for search engine support.
What is best practice to enhance the semantic accessibility of a website <nav> landmark with a nested <ul> list for screen reader users? (aria-label and list level are currently not pronounced by all screen readers)
I tested with Voiceover on iOS 9, Talkback on Android 5 and NVDA 2016-1 on Win10 (in Firefox). I used (mostly) default settings in the screen reader applications.
I thought the following list should be optimal prepared for screen reader users:
Demo code 1
<nav>
<ul aria-label="product navigation">
<li>Product A
<ul aria-label="sub menu Product A">
<li>Specifications</li>
<li>Accessories</li>
</ul>
</li>
<li>Product B
<ul aria-label="sub menu Product B">
<li>Specifications</li>
<li>Accessories</li>
</ul>
</li>
</ul>
</nav>
Expected result: Screen reader say something like this:
Beginning of navigation landmark
Beginning list level 1 "product navigation" with two elements
"Product A" link
Beginning list level 2 "sub menu Product A" with two elements
"Specifications" link
"Accessories" link
End of list level 2 "sub menu Product A"
"Product B" link
Beginning list level 2 "sub menu Product B" with two elements
"Specifications" link
"Accessories" link
End of list level 2 "sub menu Product B"
End of list level 1 "product navigation"
End navigation landmark
I also expected detailed info when touching sub menu items on table/phone, e.g.
"Specifications" link level 2 list "sub menu Product B"
But unfortunately this is not working in Voiceover, Talkback or NVDA.
The list labels and the list level are both not spoken.
When using a screen reader and jumping from list to list (like using l key or the list rotator/navigation) you have no idea, what list you're in. In case the elements of the children lists have similar links (like in the demo code) this problem seems for me to be even worse.
I also think it is very confusing (at least for me) to hear "beginning of list" and "end of list" multiple times with no hint, what kind of list is beginning or ending - especially when you are on a mobile or tablet and discovering the display content randomly with your finger.
I made a test series and tried different variations, e.g. I added explicit role="list" and "listitem". I also added aria-level="1" and "2" to the listitems as shown in this example - without success. Are list levels supported by any screen reader software?
One of my findings: At least Voiceover (on iOS) is telling the aria-label of the <ul> elements, but only when defining explicit role="list" like in the following code. But this also only works when the <nav> container is not used - Voiceover (on iOS) is ignoring the fact that there is a list completely when using <ul> within <nav>. So when using a <nav> landmark the list is gone in Voiceover and also not accessible via the rotator/list navigator.
Demo code 2
<ul role="list" aria-label="product navigation">
<li role="listitem">Product A
<ul role="list" aria-label="sub menu Product A">
<li role="listitem">Specifications</li>
<li role="listitem">Accessories</li>
</ul>
</li>
<li role="listitem">Product B
<ul role="list" aria-label="sub menu Product B">
<li role="listitem">Specifications</li>
<li role="listitem">Accessories</li>
</ul>
</li>
</ul>
I think when using a nested list it is important to tell the blind user the nesting level and the list label (at least for the sub level lists, so you know that it is a sub level list) - is there currently a way to solve this?
In case it is not possible, I'd say that it is not a good advice to use nested lists in <nav> for navigation... or nested lists at all?
Edit 1: Updated demo code
Edit 2: More findings
In this answer to another question is made clear, that there are no fixed rules about how screen reader should handle/read aria-label.
<nav> and <ul> are grouping elements - according to the answer the labels are more likely to be read - unfortunately not in my tests when there are nested lists in a navigation landmark.
I also found a page listing some screen reader test results for unordered nested lists - at the beginning they state what "should be announced", so it's optional. :/ The Voiceover results of this page are not valid for Voiceover on iOS 9, the nesting level is not announced in my test.
On the NVDA GitHub issue tracker there are also multiple discussions about the way to implement support for aria-label. And I also found this long but really interessting article about the ridiculous complicated world of aria-label.
Anyway, so now I know I can't expect that nesting levels or aria-labels are announced by default. I'm still wondering if there is a way to enhance accessibility for blind users when the screen reader software doesn't support this functionality...
I know there are some people on Stack Overflow who use screenreader software everyday by necessity, while I only use it for testing. So if any of them contradict my answer, go with their suggestions.
But to me, all the additional ARIA you want to add would just make the menu longer to listen to. The content itself is what makes it clear these are submenus (when there is real content and not example content), so there is no need for aria-label attributes. It's confusing for you, but remember that you only use a screenreader on the sites you build, not every site. Being consistent with the rest of the web's navigation helps people understand your site more quickly.
Also, ARIA roles as in your second example are intended to change the way HTML elements are reported to screenreaders (e.g. A div which behaves like a button). Since you are adding matching roles, you are increasing your workload without adding usability for anyone.
So using semantically correct HTML is all you need to do in this case to make a perfectly accessibile menu. There is no need to add ARIA until you are building unusual widgets, not standard links and text.
You won't help users by giving them the nesting level number, or ask them to remember the menu section they are into.
If you really want to help the users, tell them where they are everywhere.
See https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-link.html
<nav>
<h2>Product navigation</h2>
<ul>
<li>Product A
<ul>
<li>Specifications</li>
<li>Accessories</li>
</ul>
</li>
<li>Product B
<ul>
<li>Specifications</li>
<li>Accessories</li>
</ul>
</li>
</ul>
</nav>
You can use the title attribute conjointly with the aria-label attribute in order to be compatible with the majority of screenreaders and be accessible for non-screenreaders users.
The reason you're not getting the labels read out is because you have them as arial-label instead of aria-label in your code. If you change this to aria-label they will be read as the screenreader is going through the document. If you are tabbing through the links, however, the aria label of the list element will not be read as it's not a focusable element. The screenreader should handle the nesting properly without the need for additional labelling - I've tested this in NVDA and it works as expected - it will announce 'list with two items' when I tab from 'Product A' into "specifications'. Hope this helps.
I am modifying a site that has a menu with the following code:
<h3>Menu</h3>
<ul class="nav">
<li><a data-scroll href="#home">Home</a></li>
<li><a data-scroll href="#services">Service</a></li>
<li><a data-scroll href="#contact">Contact</a></li>
</ul>
As a user clicks on those links the user will be taken to the corresponding section on that page.
I need to modify this to allow for links that do not point to the same page.
I tried the obvious:
<h3>Menu</h3>
<ul class="nav">
<li>Google</li>
</ul>
but it won't work.
The status bar shows the correct link but when I click the page won't change.
Is there any special code I need to add (links on other places of the page work fine).
As we discussed, Javascript (specifically jQuery preventDefault) can override the default behavior of an anchor (that is to say, follow it). Therefore, check all Javascript for this situation.
Also, a link MUST have an http:// in front of it, to define the resource type. Links only work on the same page or domain if there isn't one.
It is clear to me that
Google
Will not work because you should write it like so:
Google
Give that a try, if the answer is not this, then you should share with us what else you are doing on your site that we cannot simply imagine by the snippet you have shared with us.
What can be done to improve the accessibility of a breadcrumb menu similar to:
<ul class="breadcrumbs" aria-label="breadcrumb navigation" role="navigation">
<li>Home</li>
<li>News</li>
<li class="unavailable">#Model.Title</li>
</ul>
Given in this example Home is the site root, News is the first child, and the unavailable class is the current item the /news/article item.
Is there anything that could be done to improve this such as using rel attributes or aria-level attributes?
I would avoid the use of aria-level and use a <ol> element instead. It is best to avoid using aria attributes wherever a native alternative exists. Using aria adds an extra layer of complexity. Simple HTML is far better and already has semantics that are surfaced to AT. This is the first rule of ARIA.
Borrowing from the WAI-ARIA-Practices document, breadcrumbs would look like something like this:
<nav aria-label="Breadcrumb" class="breadcrumb">
<ol>
<li>
<a href="../../">
WAI-ARIA Authoring Practices 1.1
</a>
</li>
<li>
<a href="../../#aria_ex">
Design Patterns
</a>
</li>
<li>
<a href="../../#breadcrumb">
Breadcrumb Pattern
</a>
</li>
<li>
<a href="./index.html" aria-current="page">
Breadcrumb Example
</a>
</li>
</ol>
</nav>
Some notes:
Wrapping the breadcrumbs in a <nav> element lets screen reader users quickly find and jump to the breadcrumbs.
Using <ol> element surfaces an order to screen reader users.
The <ol> should be a child of the <nav>. Some implementations apply role="nav" to the <ol> itself. This is wrong and will override the default <ol> semantics.
aria-current informs screen reader users that this is the current page. If the last breadcrumb for the current page is not a link, the aria-current attribute is optional.
Going from using a screen reader and reading this blog post, the rel attributes won't make a difference to A.T. As for using aria-level, it works if you put it on the anchor tags. I'd also advise wrapping the list in a nav element, for semantic purposes and to save the need of putting a navigation role on the list when you don't need to.
I wound up with this markup for what I think is a not-too-bad breadcrumb. Hide the bullets using CSS (I didn't stop to do that I'm afraid) and I'd say its good.
<nav aria-label="breadcrumb" role="navigation">
<ul>
<li>Home</li>
<li>News</li>
</ul>
</nav>
Hope this helps!
You can use like below
<nav role="navigation" aria-label="breadcrumbs">
<p id="breadcrumblabel">You are here:</p>
<ol id="breadcrumb" aria-labelledby="breadcrumblabel">
<li>Home</li>
<li>Menu1</li>
<li>Menu2</li>
</ol>
</nav>
When searching the Web for a thorough solution on accessible breadcrumbs, #Craig Brett's solution seemed good at first sight. But after reading several sources, aria-level seems to be misused there (besides a W3C Validation problem, see my comment above).
Therefor I like to propose this approach:
<nav aria-labelledby="bc-title" role="navigation">
<h6 id="bc-title" class="vis-off">You are here:</h6>
<a href="~/" aria-labelledby="bc-level-1">
<span id="bc-level-1" class="vis-off">Homepage Website-Title </span>Home
</a>
<a href="~/news" aria-labelledby="bc-level-2">
<span id="bc-level-2" class="vis-off">Level 2: News </span>News
</a>
#Model.Title
</nav>
In this solution we have an HTML5 sectioning element (nav), which should have a heading, and *tada* there it is. Class vis-off signifies an element that is just available to screen readers. With aria-labelledby I'm telling the screen reader to read that headline.
In contrast to Chris' solution, either the <ul> or aria-level is gone.
I'd so or so go for an <ol> if necessary, because the items are in order. Better leaving it out, otherwise it gets very verbose in many screen readers on every page ("List item 1…").
aria-level seems to be misused in the solution above in my understanding. It must be child of a role attribute like f.e. role="list" and that role just signifies not structurally marked-up non-interactive lists.
Maybe a role treeitem might be more appropriate. IMHO it's overkill.
PS: I'm not using BEM notation here to shorten the ids and classes for readability.
I'm always trying to use the new html5 elements, but find myself doing stuff like this:
<nav class="some-menu">
<ul class="menu">
<li>
<a title="link to somewhere" href="the-link.php">link to somewhere</a>
</li>
</ul>
</nav>
When I could have achieved the same (visually) with:
<ul class="menu">
<li>
<a title="link to somewhere" href="the-link.php">link to somewhere</a>
</li>
</ul>
More symantic markup vs bloated DOM, should I include the <nav> tag in that situation?
EDIT
I've found the <menu> item can actually be used in this situation along with <li> e.g:
<menu class="side-menu">
<li><a title="a menu item" href="touch-my-nipples.thanks">Inappropriate Href</a>
</menu>
Which achieves more semantic markup without verbosity
Well you could argue that not including html5 tags increases the readability of your html file.
However, for SEO purposes, using html5 tags may assist in your page rank, so that might be a consideration if you are developing for a commercial web page.
In this one particular case, if the purpose of the <li> is not for navigation, then it I doubt you would get any criticism for it.
This is a good question. More DOM == more time to load the page, which is not good. However, you could try to use a combination of both. How about simply doing something like this:
<nav class="menu">
<a class="menu-item" href="...">Link 1</a>
<a class="menu-item" href="...">Link 2</a>
</nav>
I don't think there is a huge benefit to one over the other, though you should test to see how this appears to different screen reader users (as accessibility may be benefit of semantic markup).
It's not just about code bloat, don't forget about accessibility. By having a <nav> element, you can tell user's screen readers where the menu is. It would be difficult to detect if it was just ul.menu.
As Denis mentions, there are also advantages for SEO rankings.
"the element which allows you to group together links, resulting in more semantic markup and extra structure which may help screenreaders."
By: http://html5doctor.com/nav-element/
Example:
<nav>
<ul>
<li>Home</li>
<li>About</li>
</ul>
</nav>
Good idea use because: internal links for site navigation
<menu> tag
The HTML element represents an unordered list of ""menu"" choices, or commands.
By: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/menu