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".
Related
I have a sidebar which contains the main navigation for the app. It also contains a button which triggers the open/close of the sidebar. In terms of semantics, how should the markup look like?
Should i wrap the sidebar in aside and then have a nav around only
the main navigation, excluding the open/close trigger.
Or wrap the whole sidebar in a nav including the open/close trigger
Or wrap the sidebar in a section, which contains a nav excluding the
open/close trigger?
Or not have any section or aside, but only have a nav excluding the trigger, in which case am I still following the below best practice. Should the trigger be treated as content? or something that should be part of the outline of the web page?
The [W3][1] suggests:
It is a best practice to include ALL content on the page in landmarks,
so that screen reader users who rely on them to navigate from section
to section do not lose track of content.
The current structure resembles this:
sidebar
main nav
nav item 1
nav item 2
trigger to open/close the sidebar
The <aside> element is used for tangentially related content to main content of the page and are often represented visually as sidebars. Using it for navigation would not be completely confusing to a screen-reader, but you must, in this case, add a role of either complementary or region to it.
I would expect this <aside> to group at least several different <nav> elements, so for your use-case of having a single menu, I would definitely just go with having the sidebar menu area be a <nav>. Remember to give it a nice aria-label by the way. Something like aria-label=“Primary” will suffice for your primary navigation.
Consider hiding the toggle button for screen-readers with aria-hidden=“true”, if toggling does not do them any good. In that case the <nav> must never be hidden with display: none as it would render it invisible and un-toggleable to screen-readers.
<nav aria-label="Primary”>
<button aria-hidden="true">Toggle menu</button>
<ul>
<li>
Link 1
</li>
<li>
Link 2
</li>
</ul>
</nav>
In HTML5, I know that <nav> can be used either inside or outside the page's masthead <header> element. For websites having both secondary and main navigation, it seems common to include the secondary navigation as a <nav> element inside the masthead <header> element with the main navigation as a <nav> element outside the masthead <header> element. However, if the website lacks secondary navigation, it appears common to include the main navigation in a <nav> element within the masthead <header> element.
If I follow these examples, my content structure will be based on the inclusion or exclusion of secondary navigation. This introduces a coupling between the content and the style that feels unnecessary and unnatural.
Is there a better way so that I'm not moving the main navigation from inside to outside the masthead <header> element based on the inclusion or exclusion of secondary navigation?
Main and Secondary Navigation Example
<header>
<nav>
<!-- Secondary Navigation inside <header> -->
<ul>
<li></li>
</ul>
</nav>
<h1>Website Title</h1>
</header>
<nav>
<!-- Main Navigation outside <header> -->
<ul>
<li></li>
</ul>
</nav>
OnlineDegrees.org is an example site that follows the above pattern.
Main Only Navigation Example
<header>
<h1>Website Title</h1>
<nav>
<!-- Main Navigation inside <header> -->
<ul>
<li></li>
</ul>
</nav>
</header>
Keyzo.co.uk is an example site that follows the above pattern.
Excerpts from Introducing HTML5 — Added on 02-Feb-11, 7:38 AM
Introducing HTML5 by Bruce Lawson and Remy Sharp has this to say about the subject:
The header can also contain navigation. This can be very useful for site-wide navigation, especially on template-driven sites where the whole of the <header> element could come from a template file.
Of course, it's not required that the <nav> be in the <header>.
If depends largely on whether you believe the site-wide navigation belongs in the site-wide header and also pragmatic considerations about ease of styling.
Based on that last sentence, it appears that Bruce Lawson—author of the chapter those excerpts are from—admits that "pragmatic considerations about ease of styling" yield a coupling between the content and the style.
It's completely up to you. You can either put them in the header or not, as long as the elements within them are internal navigation elements only (i.e. don't link to external sites such as a twitter or facebook account) then it's fine.
They tend to get placed in a header simply because that's where navigation often goes, but it's not set in stone.
You can read more about it at HTML5 Doctor.
I do not like putting the nav in the header. My reasoning is:
Logic
The header contains introductory information about the document. The nav is a menu that links to other documents. To my mind this means that the content of the nav belongs to the site rather than the document. An exception would be if the NAV held forward links.
Accessibility
I like to put menus at the end of the source code rather than the start. I use CSS to send it to the top of a computer screen or leave it at the end for text-speech browsers and small screens. This avoids the need for skip-links.
It's a little unclear whether you're asking for opinions, eg. "it's common to do xxx" or an actual rule, so I'm going to lean in the direction of rules.
The examples you cite seem based upon the examples in the spec for the nav element. Remember that the spec keeps getting tweaked and the rules are sometimes convoluted, so I'd venture many people might tend to just do what's given rather than interpret. You're showing two separate examples with different behavior, so there's only so much you can read into it. Do either of those sites also have the opposing sub/nav situation, and if so how do they handle it?
Most importantly, though, there's nothing in the spec saying either is the way to do it. One of the goals with HTML5 was to be very clear[this for comparison] about semantics, requirements, etc. so the omission is worth noting. As far as I can see, the examples are independent of each other and equally valid within their own context of layout requirements, etc.
Having the nav's source position be conditional is kind of silly(another red flag). Just pick a method and go with it.
#IanDevlin is correct. MDN's rules say the following:
"The HTML Header Element "" defines a page header — typically containing the logo and name of the site and possibly a horizontal menu..."
The word "possibly" there is key. It goes on to say that the header doesn't necessarily need to be a site header. For instance you could include a "header" on a pop-up modal or on other modular parts of the document where there is a header and it would be helpful for a user on a screen reader to know about it.
It terms of the implicit use of NAV you can use it anywhere there is grouped site navigation, although it's usually omitted from the "footer" section for mini-navs / important site links.
Really it comes down to personal / team choice. Decide what you and your team feel is more semantic and more important and the try to be consistent. For me, if the nav is inline with the logo and the main site's "h1" then it makes sense to put it in the "header" but if you have a different design choice then decide on a case by case basis.
Most importantly check out the docs and be sure if you choose to omit or include you understand why you are making that particular decision.
To expand on what #JoshuaMaddox said, in the MDN Learning Area, under the "Introduction to HTML" section, the Document and website structure sub-section says (bold/emphasis is by me):
Header
Usually a big strip across the top with a big heading and/or logo.
This is where the main common information about a website usually
stays from one webpage to another.
Navigation bar
Links to the site's main sections; usually represented by menu
buttons, links, or tabs. Like the header, this content usually remains
consistent from one webpage to another — having an inconsistent
navigation on your website will just lead to confused, frustrated
users. Many web designers consider the navigation bar to be part of
the header rather than a individual component, but that's not a
requirement; in fact some also argue that having the two separate is
better for accessibility, as screen readers can read the two features
better if they are separate.
I think the simpliest way to answer this is to check the MDN Web Docs and other web standards sites.
TL;DR
there is no right or wrong. It depends on what you build.
This is a question that every web developer asks himself at some point. I had asked myself the question several times. To answer this question, I looked at the source code of Stackoverflow. And SO has the nav tag inside the header tag.
Which is absolutely right here, because if you look at the structure of the view of the top bar, it quickly becomes clear that this is the right way to go. Here you can simply work with the flexbox design. Which in turn would only work with a superordinate tag if both tags were not nested. Which would unnecessarily bleach the DOM. like:
<div class="flex">
<header></header>
<nav></nav>
</div>
On the other hand, there are headers that are simply a large image with a logo inside. Or a whole line with the logo. Here it doesn't matter whether the nav tag is above or below the header tag.
Conclusion: The tags only have a semantic meaning and are not a specification for a template structure. You build the template according to your ideas or the expectations of the users.
Both cases are right!
<!-- case 1 -->
<body>
<header></header>
<nav></nav>
<main></main>
</body>
<!-- case 2 -->
<body>
<header>
<nav></nav>
</header>
<main></main>
</body>
My site's h1 is also the "home" link, so obviously I put it within the nav tag. The other links in the nav were originally put in an unordered list, like this:
<nav>
<h1>Site Name</h1>
<ul>
<li>Nav Item 1
<li>Nav Item 2
<li>Nav Item 3
</ul>
</nav>
Standard, right? As you can imagine, on subpages, the nav stays the same but the "active" class gets applied to the relavent Nav Item.
Here's the problem. At mobile screen widths, the nav compresses into a dropdown menu where the "active" link is the only link shown above the drop. That's fine on the homepage where the h1 is the active link, but it seems like my CSS is going to get super messy on subpages.
I've been noticing that some well respected frontend developers use list items free of ordered/unordered lists. These are folks who hold semantics in high esteem, so it made me wonder they might be thinking...
So I'm stuck. It seems wrong to put my h1 in the ul, but this also seems wrong:
<nav>
<li><h1>Site Name</h1></li>
<li>Nav Item 1</li>
<li>Nav Item 1</li>
</nav>
I know that I can get the LOOK of what I want to achieve almost any way I markup the HTML, but I'd like to do it as semantically as possible while avoiding a CSS/JS nightmare / or any hacks.
The standard is clear :
Permitted parent elements :
ul, ol, menu
Any other use should be avoided as a browser might very well not support it.
The fact the norm prohibits it means there is no accepted semantic, apart the one each developer invents for his own use.
In HTML5, I know that <nav> can be used either inside or outside the page's masthead <header> element. For websites having both secondary and main navigation, it seems common to include the secondary navigation as a <nav> element inside the masthead <header> element with the main navigation as a <nav> element outside the masthead <header> element. However, if the website lacks secondary navigation, it appears common to include the main navigation in a <nav> element within the masthead <header> element.
If I follow these examples, my content structure will be based on the inclusion or exclusion of secondary navigation. This introduces a coupling between the content and the style that feels unnecessary and unnatural.
Is there a better way so that I'm not moving the main navigation from inside to outside the masthead <header> element based on the inclusion or exclusion of secondary navigation?
Main and Secondary Navigation Example
<header>
<nav>
<!-- Secondary Navigation inside <header> -->
<ul>
<li></li>
</ul>
</nav>
<h1>Website Title</h1>
</header>
<nav>
<!-- Main Navigation outside <header> -->
<ul>
<li></li>
</ul>
</nav>
OnlineDegrees.org is an example site that follows the above pattern.
Main Only Navigation Example
<header>
<h1>Website Title</h1>
<nav>
<!-- Main Navigation inside <header> -->
<ul>
<li></li>
</ul>
</nav>
</header>
Keyzo.co.uk is an example site that follows the above pattern.
Excerpts from Introducing HTML5 — Added on 02-Feb-11, 7:38 AM
Introducing HTML5 by Bruce Lawson and Remy Sharp has this to say about the subject:
The header can also contain navigation. This can be very useful for site-wide navigation, especially on template-driven sites where the whole of the <header> element could come from a template file.
Of course, it's not required that the <nav> be in the <header>.
If depends largely on whether you believe the site-wide navigation belongs in the site-wide header and also pragmatic considerations about ease of styling.
Based on that last sentence, it appears that Bruce Lawson—author of the chapter those excerpts are from—admits that "pragmatic considerations about ease of styling" yield a coupling between the content and the style.
It's completely up to you. You can either put them in the header or not, as long as the elements within them are internal navigation elements only (i.e. don't link to external sites such as a twitter or facebook account) then it's fine.
They tend to get placed in a header simply because that's where navigation often goes, but it's not set in stone.
You can read more about it at HTML5 Doctor.
I do not like putting the nav in the header. My reasoning is:
Logic
The header contains introductory information about the document. The nav is a menu that links to other documents. To my mind this means that the content of the nav belongs to the site rather than the document. An exception would be if the NAV held forward links.
Accessibility
I like to put menus at the end of the source code rather than the start. I use CSS to send it to the top of a computer screen or leave it at the end for text-speech browsers and small screens. This avoids the need for skip-links.
It's a little unclear whether you're asking for opinions, eg. "it's common to do xxx" or an actual rule, so I'm going to lean in the direction of rules.
The examples you cite seem based upon the examples in the spec for the nav element. Remember that the spec keeps getting tweaked and the rules are sometimes convoluted, so I'd venture many people might tend to just do what's given rather than interpret. You're showing two separate examples with different behavior, so there's only so much you can read into it. Do either of those sites also have the opposing sub/nav situation, and if so how do they handle it?
Most importantly, though, there's nothing in the spec saying either is the way to do it. One of the goals with HTML5 was to be very clear[this for comparison] about semantics, requirements, etc. so the omission is worth noting. As far as I can see, the examples are independent of each other and equally valid within their own context of layout requirements, etc.
Having the nav's source position be conditional is kind of silly(another red flag). Just pick a method and go with it.
#IanDevlin is correct. MDN's rules say the following:
"The HTML Header Element "" defines a page header — typically containing the logo and name of the site and possibly a horizontal menu..."
The word "possibly" there is key. It goes on to say that the header doesn't necessarily need to be a site header. For instance you could include a "header" on a pop-up modal or on other modular parts of the document where there is a header and it would be helpful for a user on a screen reader to know about it.
It terms of the implicit use of NAV you can use it anywhere there is grouped site navigation, although it's usually omitted from the "footer" section for mini-navs / important site links.
Really it comes down to personal / team choice. Decide what you and your team feel is more semantic and more important and the try to be consistent. For me, if the nav is inline with the logo and the main site's "h1" then it makes sense to put it in the "header" but if you have a different design choice then decide on a case by case basis.
Most importantly check out the docs and be sure if you choose to omit or include you understand why you are making that particular decision.
To expand on what #JoshuaMaddox said, in the MDN Learning Area, under the "Introduction to HTML" section, the Document and website structure sub-section says (bold/emphasis is by me):
Header
Usually a big strip across the top with a big heading and/or logo.
This is where the main common information about a website usually
stays from one webpage to another.
Navigation bar
Links to the site's main sections; usually represented by menu
buttons, links, or tabs. Like the header, this content usually remains
consistent from one webpage to another — having an inconsistent
navigation on your website will just lead to confused, frustrated
users. Many web designers consider the navigation bar to be part of
the header rather than a individual component, but that's not a
requirement; in fact some also argue that having the two separate is
better for accessibility, as screen readers can read the two features
better if they are separate.
I think the simpliest way to answer this is to check the MDN Web Docs and other web standards sites.
TL;DR
there is no right or wrong. It depends on what you build.
This is a question that every web developer asks himself at some point. I had asked myself the question several times. To answer this question, I looked at the source code of Stackoverflow. And SO has the nav tag inside the header tag.
Which is absolutely right here, because if you look at the structure of the view of the top bar, it quickly becomes clear that this is the right way to go. Here you can simply work with the flexbox design. Which in turn would only work with a superordinate tag if both tags were not nested. Which would unnecessarily bleach the DOM. like:
<div class="flex">
<header></header>
<nav></nav>
</div>
On the other hand, there are headers that are simply a large image with a logo inside. Or a whole line with the logo. Here it doesn't matter whether the nav tag is above or below the header tag.
Conclusion: The tags only have a semantic meaning and are not a specification for a template structure. You build the template according to your ideas or the expectations of the users.
Both cases are right!
<!-- case 1 -->
<body>
<header></header>
<nav></nav>
<main></main>
</body>
<!-- case 2 -->
<body>
<header>
<nav></nav>
</header>
<main></main>
</body>
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.