I have this main header element that is a page-specific navigation menu. As you can see the h1 element is a link to (the menu is fixed to the top of the page while the rest scrolls down).
Example:
<header role="menubar">
<a href="#top">
<h1>Main Title</h1>
</a>
<ul role="menu">
<li role="menuitem">
presentation
</li>
<li role="menuitem">
picture
</li>
<li role="menuitem">
downloads
</li>
</ul>
</header>
on w3 validator I get as message:
Error: Bad value menubar for attribute role on element header.
.
referring me to the W3 recommendation page for single pages where the allowed ARIA roles for the header element are:
banner role (default - do not set) or presentation.
.
'default - do not set' isn't really an option as it would not be backwards compatible because of the header element
'banner' and 'presentation' are not the correct roles (see banner and presentation)
So my questions:
What do I have to do? Easiest would be to replace the header element
by a div element. But I think it is semantically less good, is that
right?
Is it possible that this case was not really considered by the W3C
people or is it 100% wrong to do so (I mean on a semantic level
focusing on accessibility).
Are there other options?
thank you :)
What your current code shows is not a menubar but a navigation list. Instead of <header role="menubar"> you need <nav> and you should remove the role attributes from the list elements. If you are implementing a menu bar, your code is very incomplete.
For advice on using HTML5 and WAI-ARIA for menu bars, see Recommended WAI-ARIA implementation for navigation bar/menu.
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 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
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).
Just covered out some strage specs regarding ARIA roles. Why does ul have ARIA role menu but menuitem is forbidden for li?
I would like to describe a navigation bar using ul, li and HTML5's nav element in combination with the ARIA roles navigation, menu and menuitem.
<!DOCTYPE html>
<html>
<head><title>ARIA role bug?</title></head>
<body>
<nav role="navigation">
<ul role="menu">
<li role="menuitem">example.com</li>
</ul>
</nav>
</body>
</html>
W3's HTML5 validator nag me here:
Bad value menuitem for attribute role on element li.
Jukka is incorrect here. The W3C validator does not check against the WHATWG LS, instead it checks against the W3C HTML specification. The W3C HTML spec is the authoritative source for conformance checking requirements for the W3C Validator.
In regards to menuitem not being allowed as per the HTML spec, I believe this is a bug. And as such I have filed a bug. It is now in my bug queue to be resolved.
I have filed a bug against the W3C validator and wai-aria in HTML doc as well.
Until such times the validator is fixed, I suggest you use the roles as per the WAI-ARIA spec and ignore the validator.
addendum:
I looked back at history of ARIA integration into HTML could not find any reason why menuitem was not allowed, so believe it was an oversight. I fixed and resolved the bug I referenced above.
The following HTML markup is in the ARIA spec itself (the one you linked), and clearly shows a LI (nested, even) being used as a menuitem. Im guessing the particular markup you are using is forcing it to non-conform but thats just a hunch.
<ul role="menubar">
<!-- Rule 2A: "File" label via aria-labelledby -->
<li role="menuitem" aria-haspopup="true" aria-labelledby="fileLabel"><span id="fileLabel">File</span>
<ul role="menu">
<!-- Rule 2C: "New" label via Namefrom:contents -->
<li role="menuitem">New</li>
<li role="menuitem">Open…</li>
…
</ul>
</li>
…
</ul>
You shouldn't put role="menuitem" on an li element when it contains an a element since a menuitem widget cannot contain any intereactive elements (e.g links).
Take a look at the aria-practices examples for menu.
<li role="none">
<a role="menuitem">my menuitem here</a>
</li>
or
<li role="menuitem">my menuitem here</li>
The W3C validator, when applying HTML5 rules, actually checks against (some version of) the WHATWG “Living HTML standard”, which currently says, in clause 3.2.7 WAI-ARIA, about “li element whose parent is an ol or ul element” the following: “Role must be either listitem, menuitemcheckbox, menuitemradio, option, tab, or treeitem”.
This corresponds to the rules in the “Using WAI-ARIA in HTML” W3C draft, in 2.9 Recommendations Table.
I was using a similar DOM and changing an li submenu's role to presentation made the the page validate. Although perhaps semantically incorrect, in my situation it is inconsequential.