In a document, there are multiple <nav> and <aside> elements. Should I add role="navigation" on all <nav>s and role="complementary" on all <aside>s?
In other words, is it more beneficial or more redundant that there are multiple <nav role="navigation">...</nav>s and multiple <aside role="complementary">...</aside>s in a document?
According to the HTML5 spec, role="navigation" is implicit to the <nav> element, and role="complementary" is implicit to the <aside> element. As such, you do not need to add them according to the spec.
The question is how many ATs actually honor the spec, so if you want to play it safe, you can add those roles, it won't hurt.
Also rememebr that some <aside> elements should however be marked as role=note.
Another thing to consider is that the HTML5 spec allows multiple seperate <ul>s to be grouped under a <nav>. I am uncertain if this implies that role="navigation" is enough on just the <nav> or that each <ul> should be marked as such. I am unable to find any information on this.
Related
Has anyone experienced this, and if so, do you have an explanation and/or solution? Basically, if you have the following markup, the "Primary" nav won't be recognized in NVDA unless there's a non-nav element preceding it.
<header role="banner">
<nav role="navigation" aria-label="Primary">...</nav>
</header>
It's perfectly valid HTML to nest a <nav> element within a <heading> element, and there are no sematic issues with doing so.
That said, NVDA doesn't appear to display elements in the "Landmarks List" if they are children of other landmark elements.
NVDA will see and announce your <nav> element within the <header>, but only if you manually step through the page content.
This means that if you nest a <nav> within a <header>, only the top-level element (in this case <header> would be visible in the "Landmarks List", and the child-element would not be accessible by cycling through landmarks with keyboard shortcuts.
If it were me, I would probably move the <nav> element outside the <header>, but neither way is technically wrong.
In Vue.js, if you want to conditionally render multiple elements via a v-if/v-else-if directive you can wrap them inside <template> tags and apply the directive to the <template> tag, as explained here. However, you can also do the same with <div> tags wrapping the multiple elements. Are there any noticeable performance benefits to using <template> over <div> or any other similar native HTML5 tag?
I doubt there is a performance change but a big difference is that the <template> node does not appear in the DOM.
This is an important distinction especially when grouping children that are the only valid node types for their parent such as list items, table rows, etc:
This is valid:
<ul>
<template v-if="something">
<li>Text</li>
<li>Text</li>
</template>
</ul>
This is not:
<ul>
<div v-if="something">
<li>Text</li>
<li>Text</li>
</div>
</ul>
I know that the question is quite old, but I found out one more thing
if you use divs - your div will be in DOM, but empty, if v-if is false and it can make some spaces looks like margins
if you use template - you don't have anything in DOM and it just don't appear
The documentation of the bootstrap 3 container class states that 'due to padding and more, neither container is nestable".
But then, in the official examples, take this, a demo of a simple navbar, we see something like:
<body>
<div class="container">
<nav class="navbar navbar-default">
<div class="container-fluid">
<div class="navbar-header">
where a container-fluid is clearly nested inside a a container.
My understanding of the "neither container is nestable" sentence is that we should have just one container in a page, or on the other hand we can have multiple if they are not nested one within the other.
Seeing the examples it doesn't seem to be the case, then what does it mean that constraint? I've read also this question and some others but they don't talk about the nesting thing.
This has been brought up as in issue on the Bootstrap repo:
https://github.com/twbs/bootstrap/issues/15512
I'm not sure if the doc will be updated accordingly, but as you'll see in the issue it looks like it's ok to put a container-fluid inside a container.
We have several forms in our application which have made extensive use of widgets.
Unfortunately, this causes the form to load in a very "jittery" manner. It still loads pretty quickly, but you can perceptively see each widget 'pop' into view one-by-one.
Is this an expected side affect of the widget infrastructure, or is there a technique whereby we can coerce Durandal into constructing the entire view (widgets and all) before attaching, which seems to be how partial views work? (We were able to convert many of these widgets into partial views to mitigate the phenomenon).
How to easily reproduce the behavior
Using the HTML samples, find app/widgets/index.html and make a small modification to create a view which will have lots of widgets:
<div>
<h1>Widgets Sample</h1>
<!-- ko foreach: new Array(100) -->
<div data-bind="expander:{items:$root.projects}">
<h3 data-part="header">Project: <span data-bind="text: name"></span></h3>
</div>
<!-- /ko -->
<button class="btn" data-bind="click: addNewProject">Add</button>
</div>
When refreshing the page, you will see the scrollbar "shrinking down" visibly. I suspect this is because each individual widget is being added to the DOM one at a time, rather than "all at once with the parent view" which is how partial views work.
Note: The affect is fairly subtle with this very simple markup, but the more complicated the UI elements, the more noticeable and jarring the "studdering" becomes (especially when you have non-widget content nested in between various wisgets).
Looks like there's no obviouse answer at the moment, but there's an issue at https://github.com/BlueSpire/Durandal/issues/434 that is cross linked with this questions.
I've created a RDFa snippet to use on a client's website using the GoodRelations tool. The generated code creates the tags as expected, but there's no text between the divs, for instance:
<div typeof="vcard:Address">
<div property="vcard:locality" content="Yorba Linda"></div>
</div>
I'm assuming that this is OK, and that I am expected to put descriptive text for humans between the 'locality' divs without any adverse effects (in relation to SEO.) Correct?
As William says: In most cases, is is impractical to reuse visible content for publishing meta-data, because they differ in sequence or structure. In that case, it is better to put all meta-data in a single block of <div> elements without visible content. This is called "RDFa in Snippet Style", see
http://www.ebusiness-unibw.org/tools/rdf2rdfa/
Hepp, Martin; García, Roberto; Radinger, Andreas: RDF2RDFa: Turning RDF into Snippets for Copy-and-Paste, Technical Report TR-2009-01, 2009., PDF at http://www.heppnetz.de/files/RDF2RDFa-TR.pdf
Google is consuming such markup, despite a general preference for marking up visible content. Many big shops are using this approach with good results, e.g. http://www.rachaelraystore.com/Product/detail/Rachael-Ray-Stoneware-2-pc-Bubble-Brown-Baker-Set-Eggplant/316398
So if you can integrate the visible content and the RDFa constructs, then use
<div typeof="vcard:Address">
<div property="vcard:locality">Yorba Linda</div>
</div>
If you cannot, then use
<div typeof="vcard:Address">
<div property="vcard:locality" content="Yorba Linda"></div>
</div>
...
<div>
<div>Yorba Linda</div>
</div>
But the divs with invisible content must be close to the visible content and be placed better before than after the visible markup.
From and RDFa point of view, it is fine (I am assuming you are using bracers because you don't know how to escape greater than / less than characters).
The only thing you need to think about is how adding this fragment of HTML to your HTML document, will affect the rendering. Based on the fact that you are using the content attribute, this fragment is destined to remain hidden. So yo should think about this in relation to the CSS architecture. My advice would be to create a specific CSS class that is for annotations.
Having spoken to the author of Good Relations, his advice would be to put this fragment before any other HTML element in the body of your document. Generally, the Rich Snippets team indicate that they ignore hidden RDFa, but it doesn't actually matter and really in the long run it enables the publishing of RDF to anyone (not only Google) who wants to consume it.