I'm referring to a main menu and a smaller supermenu (don't know the proper term), as seen here:
For something like this, I was going to put two <nav> elements in the <header>. Is there any reason (SEO or otherwise) that this is a bad idea? If so, what would an alternative be?
(this is different from multiple <nav> tags, which referred to multiple on an entire page, not in a single block element)
Short answer: no there is not (probably)
Longer answer: the HTML5 spec itself is a bit fluffy on the subject:
http://dev.w3.org/html5/spec/Overview.html#the-nav-element
The thing is that they designate the <nav> element to 'major' navigation blocks, but leave it to the imagination (of both developers and parsers) what that means. As you can see they even provided an example where they exclude the "site-wide" from the navigation block.
<body itemscope itemtype="http://schema.org/Blog">
<header>
<h1>Wake up sheeple!</h1>
<p>News -
Blog -
Forums</p>
<p>Last Modified: <span itemprop="dateModified">2009-04-01</span></p>
<nav>
<h1>Navigation</h1>
<ul>
<li>Index of all articles</li>
<li>Things sheeple need to wake up for today</li>
<li>Sheeple we have managed to wake</li>
</ul>
</nav>
</header>
They seem to do that because they consider limiting the number of links in nav elements a plus for readability (think screen readers etc).
It is probably a bit too early to know what the search engines are going to do, but it seems safe to think that they will attach more importance to nav element links to detect the structure of you site and maybe more so if you have less of them...
My impression: Twitter and Facebook links seem certainly out, support and blog are debatable
I think it does not matter. NAV element just marks functional role of some content. So if you have two separate navigation blocks (regardless of where it's placed: in header or in other parts of page), you are free to use separate NAV elements for them. Some "penalties" from search engines in that case would be pointless.
Nav can be used multiple times on a page in HTML5.
CAN…yes
SHOULD…probably not.
I’ve always worked on the basis that the NAV tag is only for the primary page/site navigations.
If my main (header) navigation area is used for the [nav] then any other menus can be in divs with some role for ARIA.
Related
I'm updating a website, doing an iterative improvement on the accessibility.
I'm using multiple tools to get the pages better: FireFox's accessibility tree viewer; Chrome's lighthouse checker; the "wave" accessibility tool, and I'm trying tenon.io
(sadly, I don't have access to a decent screen reader - nvda is too fast for me to hear, orca seems to read the current line, and I don't have access to JAWS)
So here's what I have:
I have a navigation structure like this:
<nav aria-label="Main navigation">
<section class="desktop-navigation" aria-label="Main Menu">
<ul aria-label="Menu items">
<li>About Example</li>
<li>Documentation</li>
<li>Pricing</li>
<li>Status</li>
<li>Contact us</li>
</ul>
</section>
<section class="main-nav-wrapper" aria-label="Header logos">
<a href="/"><img src="/images/logo_example.svg?v=488a8c6971df396baaa401bb073b4a6b"
class="header-logo" alt="The Example logo" aria-label="Example Logo"/></a>
<div class="site-logos-right" aria-label="Corporate Logos">
<a class="external-link" href="https://www.example.com/" rel="external"><img
src="/images/logo_company.svg?v=98693292e027eca1f27cfc89b68a77d2" class="company-logo"
aria-label="The Company logo" alt="Official logo for Company"/></a>
<a class="external-link" href="https://example.com/department"
rel="external"><img src="/images/logo_department.svg?v=ff0114bb2ebf7eff339341f9554220d0"
class="edina-logo" alt="Official Department logo" aria-label="department logo" /></a>
</div>
</section>
</nav>
..... and this is 100% according the lighthouse, but tenon.io is reporting an issue (multiple times) and I don't understand why:
This element uses multiple strategies to create labels
This element has more than one possible label. The manner in which the
accessible name is calculated for controls uses an algorithm in which
only one of these labelling approaches will win. This means one of
these labels will be ignored by assistive technologies. There should
be only one label provided and the others should be removed.
Examples of items identified:
<nav role="navigation" aria-label="Main navigation">
<section class="desktop-navigation" aria-label="Main Menu">
<ul aria-label="Menu items">
<li><a href="/" aria-label="Return to the home page to read about
(I notice that the W3C site does not label the uls - but then they show as un-named elements in firefox)
I definitely want to label landmarks & sections.... so what's it actually complaing about?
<li>Pricing</li>
.... this is an example of where I want to have a more descriptive label for the element - when scanning the accessibility tree, just having the bare link-text doesn't (to me) read as well as having some context: as a sighted user, I know my eyes have flicked over much of the page, and seen additional text, so subconsciously have some context for the menu items.
My question(s)
How is the accessibility label computed?
Why can't I have a more descriptive label on a link? (lighthouse complains if the alt text doesn't contain the link text... but is happy if it's more than the link text) - or is this tenon.io being over-picky?
The accessible name computation is how accessibility labels are computed.
You're using aria-label too much, and the result may be difficult to listen to or outright confusing for human visitors using assistive technologies.
The first rule of ARIA is don't use ARIA unless you really have to.
It is appropriate to use aria-label on the <nav> and <section> elements. Keep that.
I can't think of any good reason to use aria-label on a <ul> element. I'd recommend removing that.
Using aria-label on anchor elements is normally unnecessary and should be approached with caution. Unless you have a really good reason, you probably shouldn't be presenting different content to visitors using assistive technology.
I would also recommend removing aria-label from your images. This is exactly what alt text is for.
If you really want to use aria-label on anchor elements, WCAG has some guidance:
Per the Accessible Name and Description Computation and the HTML to Platform Accessibility APIs Implementation Guide, the aria-label text will override the text supplied within the link. As such the text supplied will be used instead of the link text by AT. Due to this it is recommended to start the text used in aria-label with the text used within the link. This will allow consistent communication between users.
https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA8.html#description
Don't give up on NVDA just yet. I also found the default speech settings too fast and difficult to understand. You just need to adjust the settings. The voice can also be changed out for better ones. It takes a bit of work to configure, but in my opinion NVDA is the best free screen reader available today. VoiceOver is also very nice if you have access to Mac/iOS products.
This is a question regarding Angular 2 selectors, Custom tags vs. Custom attributes, SEO and browser rendering.
When I first started to look over Angular 2, the very first thing I did when following their quickstart, right of the bat, was to change my selector to '[my-component]' (attribute selector) instead of 'my-component' (tag selector), so I could have <div my-component></div> in my html instead of <my-component></my-component>, which isn't valid html. So I would write html according to standards. Well, at least pretty close to standards (because my-component isn't a valid html attribute, but I could live with only that html validation error)
Then, at some point in a video on youtube, someone from the angular team mentioned that we should use the tag selector, performance wise at least.
Alright I said, screw html validation... or shouldn't I?
So:
Say I ignore the W3C screaming about my html being completely invalid because of the <custom-tags>. I actually have another bigger and more real concern: how does this impact SEO?
I mean don't just think client-side app, because in the real world (and for my angular 2 project as well) I also have server-side rendering, for 2 very important reasons: SEO and Fast initial rendering of the site to the user for that initial view, before the app bootstraps. You can not have a very high traffic SPA otherwise.
Sure, google will crawl my site, regardless of the tags I use, but will it rank it the same in both scenarios: one with <custom-make-believe-tags> and the other with only standard html tags?
Let's talk browsers and css:
As I started to build my first SPA site in Angular 2, I was immediately faced with another concern:
Say (in a non SPA site) I have the following html markup:
<header>
<a class="logo">
...
</a>
<div class="widgets">
<form class="frm-quicksearch"> ... </form>
<div class="dropdown">
<!-- a user dropdown menu here -->
</div>
</div>
</header>
<div class="video-listing">
<div class="video-item"> ... </div>
<div class="video-item"> ... </div>
...
</div>
Angular 2 wise I would have the following component tree:
<header-component>
<logo-component></logo-component>
<widgets-component>
<quicksearch-component></quicksearch-component>
<dropdown-component></dropdown-component>
</widgets-component>
</header-component>
<video-listing-component>
<video-item-component></video-item-component>
...
</video-listing-component>
Now, I have 2 options. Let's just take the <video-listing-component> for example, to keep this simple... I either
A) place the entire standard html tags which I already have (<div class="video-item"></div>) within the <video-item-component> tag, and once rendered will result in this:
<video-listing-component>
<div class="video-listing>
<video-item-component>
<div class="video-item>...</div>
</video-item-component>
...
...
</div>
</video-listing-component>
OR:
B) Only put the content of <div class="video-item"> directly into my <video-item-component> component and adding the required class (class="video-item") for styling on the component tag, resulting in something like this:
<video-listing-component class="video-listing">
<video-item-component class="video-item"></video-item-component>
<video-item-component class="video-item"></video-item-component>
...
</video-listing-component>
Either way (A or B), the browser renders everything just fine.
BUT if you take a closer look (after everything is rendered in the dom, of course), by default the custom tags don't occupy any space in the dom. They're 0px by 0px. Only their content occupies space. I don't get it how come the browser still renders everything as you would want to see it, I mean in the first case (A):
While having float: left; width: 25%; on the div class="video-item", but each of these divs being within a <video-item-component> tag, which doesn't have any styling... Isn't it just a fortunate side-effect that the browser renders everything as you'd expect? With all the <div class="video-item"> floating next to eachother, even though each of them are within another tag, the <video-item-component> which does NOT have float: left? I've tested on IE10+, Firefox, Chrome, all fine. Is it just fortunate or is there a solid explanation for this and we can safely rely for this kind of markup to be rendered as we'd expect by all (or at least most) browsers?
Second case (B):
If we use classes and styling directly on the custom tags (<video-item-component>)... again, everything shows up fine. But as far as I know, we shouldn't style custom components, right? Isn't this also just a fortunate expected outcome? Or is this fine also? I don't know, maybe I'm still living in 2009... am I?
Which of these 2 approaches (A or B) would be the recommended one? Or are both just fine?
I have no ideea!!
EDIT:
D'oh, thanks Günter Zöchbauer. Yeah, since my divs have float: left, that's why the (custom or not) tag they're wrapped in doesn't expand it's height. Seems I've forgotten how css works since I started to look over Angular 2:)
But one thing still remains:
If I set a percentage width on a block element (call it E), I would assume it takes x% of it's immediate parent. If I set float: left, I would expect floating within the immediate parent. In my A case, since the immediate parent is a custom tag with no display type and no width, I would expect for things to break somehow, but still... my E elements behave like their parent isn't the custom tag they're each wrapped in, but the next one in the dom (which is <div class="video-listing> in my case). And they occupy x% of that and they float within that. I don't expect this to be normal, I would think this is just a fortunate effect, and I'm afraid that one day, after some browser update... I'll wake up to find all my Angular 2 sites looking completely broken.
So... are both A and B an equally proper approach? Or am I doing it wrong in case A?
EDIT2:
Let's simplify things a bit. As I got part of my question answered, let's take another example of generated html (simplified a bit, with inlined css):
<footer>
<angular-component-left>
<div style="float: left; width: 50%;">
DIV CONTENT
</div>
</angular-component-left>
<angular-component-right>
<div style="float: left; width: 50%;">
DIV CONTENT
</div>
</angular-component-right>
</footer>
In the original, not yet implemented html (whithout <angular-component-...>, those divs should float left and each occupy 50% of the <footer>. Surprisingly, once they're wrapped in the <angular-component-...> custom tags, they do the same: occupy 50% of the footer. But this just seems like good fortune to me, dumb luck... Unintended effect.
So, is it or isn't it "dumb luck"?
Should I leave it like that, or rewrite so instead of the above code, I would have something like this:
<footer>
<angular-component-left style="display: block; float: left; width: 50%;">
DIV CONTENT
</angular-component-left>
<angular-component-right style="display: block; float: left; width: 50%;">
DIV CONTENT
</angular-component-right>
</footer>
Note that the inline styling is introduced here for simplicity, I would actually have a class instead which would be in an external css file included in the <head> of my document, not through style or styleUrls from my angular components.
The issue is your HTML validator. The - in the element name is required for elements to be treated as custom elements and it is valid HTML5. Angular doesn't require - in element names but it's good practice.
Check for example https://www.w3.org/TR/custom-elements/#registering-custom-elements (search for x-foo) or https://w3c.github.io/webcomponents/spec/custom/#custom-elements-custom-tag-example. I'm sure this dash rule is specified somewhere but wasn't able to find the spec. It is for example required in Polymer that depends on elements being proper custom elements while this doesn't matter much in Angular. The only difference as far as I know is that when you query the element, you get a HTMLUnknownElement when the - is missing in the name and a HTMLElement when it contains a -.
See also this question I asked a few years ago Why does Angular not need a dash in component name
BUT if you take a closer look, by default the custom tags don't occupy any space in the dom. They're 0px by 0px. Only their content occupies space. I just don't get it how come the browser still renders everything as you would want to see it
I'm not sure I understand this question. When Angular processes the template it adds the content dynamically. When you see the content in the browser than it's also available in the DOM and has actual dimensions.
Search engine crawlers are able to process pages that are generated by JavaScript. If this isn't enough, server-side rendered pages can provide static HTML to crawlers that contain the whole view.
I’m trying to make a search result list more accessible.
Lets say I have a list of search results that are structured in the following way:
<article>
<h2>Name of the author</h2>
<h1><a>Name of the book</a></h1>
<div class="seperator">
<div class="availability-status status1" title="available"></div>
<div class="icon icon-book" title="Book"></div>
<div class="result-button-group">
Sharing
…
</div>
</div>
<p class="imprint">Publishing house (Year)</p>
<p class="series">Part of: name of the series</p>
</article>
The name of the book is a link to another page, while the other elements around it are additional information for the corresponding item.
Visually it looks like this:
How do I structure the markup semantically correct so that users with screen readers can make sense of the result item?
When they navigate on a link to link basis they land on the name of the book, but might miss the author field that is above the title, right? Can I achieve this with aria-attributes? Or is this structured enough to make sense of regardless?
I played around with VoiceOver myself to try to make sense of it but I’m far from an expert. So any input is appreciated.
Outline
You should not use a h2 for the author name. This heading would become the heading for the article element (as it’s the first one), and the heading for the book title would create another section on the same level.
Instead, use only one heading (the book title would make the most sense) and group it with the author name (for which you could use a cite element) in a header element.
<article>
<header>
<cite>Name of the author</cite>
<h1><cite>Name of the book</cite></h1>
</header>
<!-- … -->
</article>
Link
When they navigate on a link to link basis they land on the name of the book, but might miss the author field that is above the title, right?
Yes. But that’s not a problem, it’s exactly what the screen reader user expects/wants to do (finding links, not anything else).
You could, however, consider adding the author name to the link/heading, too:
<h1><cite>Name of the author</cite>: <cite>Name of the book</cite></h1>
Font icons
Note that this is likely inaccessible (details), because the element has no content (the generated image is useless for user agents without CSS, blind users, etc., and the meaning that it conveys is not represented in an alternative way in addition):
<div class="availability-status status1" title="available"></div>
The title attribute is not sufficient. Either use an img (with alt), or add alternative text (and visually hide it).
And this seems to be pure decoration, so there’s no need for a title attribute (and it would be inaccessible to many users anyway, because the element has no content):
<div class="icon icon-book" title="Book"></div>
(But if the information that it’s a book is important, e.g. because there are magazine etc. too, then you should provide an alternative, just like in the case above.)
I have a web page like the following one:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Title</title>
</head>
<body>
<header>
<span>Logo</span>
<nav>Navigation</nav>
</header>
<main>
<h1>Page heading</h1>
<div>
Page content
</div>
</main>
<footer>
Content information
</footer>
</body>
</html>
The page structure is similar to one example in the current HTML5 draft: http://www.w3.org/html/wg/drafts/html/master/grouping-content.html#the-main-element and I think it is semantically correct.
Now I would like to style this document using CSS. I would like to be the header at the top and footer at the bottom, which is, of course, easily doable. Inside the header I would like to put the logo to the right and the navigation in the center, which is also okay (e.g by using the flexible box layout model, which is in one or the other way supported by modern browsers, or by using floats).
My problems begin when I want to put the main's content heading (the h1 element) visually in the left of the header. I could do with position: absolute but such a layout is not very flexible and would break as soon as the header's or the heading's sizes change. The proposed CSS grid layout http://www.w3.org/TR/css3-grid-layout/ may be able to do exactly what I want but it is, as far as I know, only supported (somehow) in IE 10.
One simple and working solution would be to simply restructure my page:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Title</title>
</head>
<body>
<div>
<h1 id="heading">Page heading</h1>
<header>
<span>Logo</span>
<nav>Navigation</nav>
</header>
</div>
<main aria-labelledby="heading">
<div>
Page content
</div>
</main>
<footer>
Content information
</footer>
</body>
</html>
This solution, while easily layoutable, however, has its full semantics only expressed via aria-* attributes and seems to go against the spirit of the HTML5 semantics (especially the main element).
While my example page may be simple, you can easily imagine a more complicated one where the visual position of many more elements are not in the same order as the flow order of the HTML5 markup (and nested so that the flexible box layout order property won't suffice). How would you solve the problem? Rewrite the HTML5 markup with non-semantic elements (e.g. divs) so that it corresponds more to the visual layout and then exchange the non-semantic elements by semantic ones (e.g. footer or main) wherever possible with the new structure?
I am running into the same conundrum as you, and I appreciate the frustration. I will attempt a negative answer, because I feel both of these positive ones (which say you can achieve both your ends) are missing the point.
Firstly, the way I see it, your principle difficulty is that CSS cannot move an element to a new container. The two answers fall into two categories:
Some are ultra-specific hacks (subjectively speaking) involving floats, negative margins, and/or absolute positioning which can move an item presentationally out of its container. These can be effective, but only in very specific cases. As your needs grow, it becomes difficult to maintain and it requires putting a rather large thinking cap on to address each new need or edge case that you had missed earlier. The answer by #jennifit attempts to move you in this direction. It is, I believe, the normal route taken by those trying hard to follow the spirit of semantic HTML5, which is admirable. But it can be a quagmire that makes you begin to ask exactly who you're maintaining your semantic purity for? Is it for the search engines, the screen readers, or ease of maintenance? I'll get back to this after the next classification.
Some are pragmatic rationalizations that claim to be equivalent semantically but are, in truth, a different semantic meaning. These are really semantic hacking in my opinion. #volker-e 's answer is an instance of this. He's right, this is an alternative markup that could work -- but, it doesn't equal the same semantic meaning. The h2 belongs in main as an h1 -- it makes no sense to move it within the page's header. In fact, you're saying that your heading is unrelated to your main content. This, in some ways, is worse than using that div you wanted to use, because you're making a false semantic relationship by grouping the page-header and site-header into the same semantically-significant header. A semantically meaningless container, such as div, for both header and main, is actually less perverse in my opinion.
So, getting back to what I said about who you're maintaining semantic purity for, this is the real philosophical question at play. There is often an obvious, effective, and maintainable solution without rationalized mis-uses of existing semantic elements or css 'tricks'. In your case, of having an item which is semantically a child but presentionally not a child, the answer is the one you've already put forth as a question:
Rewrite the HTML5 markup with non-semantic elements (e.g. divs) so
that it corresponds more to the visual layout and then exchange the
non-semantic elements by[sic] semantic ones (e.g. footer or main) wherever
possible with the new structure.
This is the right thing to do whether you're semantic-purity was intended for
accessibility: in this case you can achieve that in a non-hierarchical way with ARIA roles.
search engines: search engines still understand the old way to do things, so you're not going to get into SEO trouble if you follow older approaches to semantics.
maintenance: this is the reason most people are lured in by -- but the problem is, what's the point of maintainable HTML but unmaintainable CSS, or the other way around? you have no choice but to see your maintenance as a combination of both CSS and HTML, and you have to find the middle ground where they are both deranged equally when you run into a difficult presentational problem.
The only other possible answer, if you feel that HTML semantics are all that matter, is to accept the limitations that hierarchical HTML semantics places on your layout. The problem is, there is no way in CSS to re-create the layout hierarchy. Until that happens, you'll have to accept that HTML is both a presentational and a semantic language, and, therefore, semantics will always be a matter of "better" and "worse". Truly beautiful or rich or perfect semantics will be unachievable in many, if not most, layouts.
My approach would be the following:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Title</title>
</head>
<body>
<a class="aural" href="#content">Jump to content</a>
<header role="banner">
<h1 class="site-logo">Logo</h1>
<nav role="navigation" aria-labelledby="nav-heading">
<h6 id="nav-heading">Navigation</h6>
<ul>…</ul>
</nav>
<h2 id="heading">Page heading</h2>
</header>
<main id="content" role="main" aria-labelledby="heading">
Page content
</main>
<footer role="contentinfo">
Content information
</footer>
</body>
</html>
and then go for a CSS ruleset like:
header h1,
header h2,
header nav {
float: right;
}
Diff:
You have appropriate accessible headings for page's content
You save otherwise seemingly useless div in header & main
You've got a nice HTML5 structure outline, which helps SEO.
I've included (was not part of the question) the navigational landmark roles as of WAI-ARIA 1.0 draft specification
I've included a skip link, which is still recommended best practice
Minor change: I know, charset value case is insensitive, but as you also write DOCTYPE uppercase, UTF-8 is the more correct value, see http://en.wikipedia.org/wiki/UTF-8#Official_name_and_variants
The first structure may still work if there is position:relative in < main > and using position:absolute on h1 with a z-index and a -ve margin. That way, the heading will always float on top in the same position in relation to the main content. While it may not be the best solution, I think it will not break the layout (?)
<ol style="padding-top:0;">
<li>24 Hour Fitness</li>
<!-- open nested list -->
<ul>
<li>This website would be ideal to use as a reference. The information provided lists references and is also very detailed. You feel confident in what you read in this website as being factual and helpful.</li>
<li>source code – body section</li>
<!-- open nested list -->
<ol type="a">
<li>Don't display unfriendly errors directly to the user.</li>
<li>Used SSL/HTTPS for login and any pages where sensitive data is entered (like credit card info).</li>
<li>Written XHTML/HTML and CSS according to the W3C specifications and make sure they validate. The goal here is to avoid browser quirks modes and as a bonus make it much easier to work with non-standard browsers like screen readers and mobile devices.</li>
<li>Have some system for people to contact you with suggestions and criticism.</li>
</ol>
<!-- closed nested list -->
<li>The website’s goal is to encourage membership at 24 Hour Fitness gyms. This is very easy to determine by both the 24 Hour Fitness banner and the “Membership” banner. The website than provides a number of membership options.
You can locate your local gyms without any problems at all.</li>
<li>The website is quite easy to navigate around. The main reason is because of the six drop down menus at the bottom of the 24 Hour Fitness banner.
These drop down menus remain visible and constant for the majority of the web pages in the site.
For instance, when you click on “Shop” you are sent to a related website so the banner and the drop down menus change.</li>
</ul>
<!-- closed nested list -->
</ol>
The <ul> inside needs to be inside an li, so either make a new li or un-close the first one.
The validator is correct: the only legal elements within a <ul> or <ol> element are <li> elements. If you want to nest lists, put them inside <li> elements.