I noticed that if you remove the nav element in HTML5, the list of links remain the same with or with out nav.
So, what is the use of nav in this case? What is it adding to me.
Yes,W3Schools.com mentions the following about nav:
The tag defines a section of navigation links.
But, as I mentioned, what is the use of adding a section that even if removed the impact will be identical?
Thanks.
Remember that HTML was, originally, intended to be a markup language to make digital copies of documents more accessible. Trends moved it away from that to a creative tool, but HTML5 seems to be returning to that original concept.
<nav> adds a specific type of unordered list – a list that indicates it is specifically meant as navigation. What this is 'adding to you' is a more universally identifiable document markup – whether you speak the language of the document or not, you can identify the regions to help you navigate. Yes, the screen readers, search engines, etc. have all been mentioned, but this is a human-friendly component as well. Looking solely at the source, one can identify how the document should be understood or organized. The potential benefit of this in document processing of all sorts (including PDF layout for publishers) is incalculable.
Remember that semantics carry the meaning of the words. You're marking up a portion of text so that text makes sense in context. <div> has no meaning, but <article>, <section> and <nav> all tell you what the text contained within the tags means to the overall document.
While you usually would write a <div id="nav">, you can now use <nav> instead. It's just more semantic and little else.
This will be helpful for mobile browsers and for other challenged environments where the user might want to have an easy jump at the navigation. It'll be easy for the browser to find the navigation that way.
Continue to use W3Schools as a reference source and you will go far ;)
Your question, might be better answered with taking a few examples... and then explaining why it matters...
But the TL;DR version is to do with semantics.
If you have a block of text, why do you wrap it in a <p> tag, when you don't need to. You can just as happily use a <span>, then set display:inline, set the margin-top:10px that a <p> uses and continue.
Also why do you wrap your content blocks in a <div>, it's to demarcate your content into meaningful areas.
Well that is kind of what does. It signifies to screen readers, search engines, and even your CSS selectors if you choose, that everything into of this tag, should semantically be considered as a navigation block.
You don't need it, but it will certainly help assign relevance to your page content.
It adds semantics. A screen reader could be coded to skip over nav elements automatically, or a search engine bot could be coded not to include text in the nav element in the search result snippet.
Right now there aren't any implementations of these use cases that I am aware of, but as you can just use a nav instead of a div, there isn't really any reason not to.
Related
I am using a html5 header element to display a logo inside the body. ANDI accessibiility compatibility is recognizing this as a landmark. I tried going thru the documentations but they only specifiy how to add landmark but do not mention how to ignore or remove an unwanted landmark.
How do I make header/any element in future a non landmark. Any attributes I could set or any directions would be helpful.
Note: I'd still like to be able to use header element.
If useful, its an angular application. Thanks in advance.
Don't use a <header> element.
It isn't about what you want it is about what people need in order to access your site correctly.
Semantics are really important for accessibility, especially for screen reader users and trying to rely on aria to override an elements semantic role is a bad idea.
Screen reader users navigate by landmarks and expect to see them in certain places, this is one of the main reasons it is important.
There is nothing wrong with using <divs> for things that do not form part of the document structure.
If you want to know what to use instead please add a fiddle / link to your question, just in case there is a more appropriate element with the correct semantics.
So if I need to do it for legitimate reasons.
Use role="presentation" as this converts an element to be treated like a <div> (which has no semantic role.). However as stated this should be used sparingly support for aria is not as good as you might think..
What do I do to take advantage of Reader Mode in browsers to present a simplified, cleaner version of a web page?
I've used Google looking for information on how a page is coded or otherwise set up for reader mode and I have not found anything. Is there a document or web page somewhere that explains reader mode and how to set up a page which can take advantage of it?
There are no standards for how reading mode works, and it works quite different from browser to browser. You can help ensure reading mode works well with your sites by sticking to conventions for your document title, and providing certain metadata elements. I’ve documented this in detail here.
In theory: Do nothing.
Site authors generally don't like Reader mode - it hides their adverts, and throws away the design. It is designed to work in spite of sites and not require specific effort on their parts.
That said, it is more likely to work well when given high quality, well-structured markup.
Write valid HTML. Make use of semantic elements such as <main>, <nav>, <header>, <footer>, <h1-6> and so on.
Have you read this? https://mathiasbynens.be/notes/safari-reader
Here are the conclusion notes taken straight from the website
Conclusion
This definitely needs more investigating, but so far, these appear to
be the most important factors for Safari’s Reader functionality to
kick in:
Use the right markup, i.e. make sure the most important content is wrapped inside a container element. Whether you use article, div or even span
doesn’t seem to matter — as long as it’s not p.
The content needs to be long enough. Use enough words, use enough paragraphs, use enough punctuation. Every paragraph should have at least 100 characters.
Reader doesn’t work for local documents.
I think the essential thing is not only to use valid HTML, but to use HTML5 with everything it provides to structure a text semantically: <section> to have clearly seperated parts, <article> if you have thematically independent parts (like different blog posts / articles), <header> to clearly mark the header section, <h1> to <h6> for hierarchically different headers (where you should always be careful to never omit a level, i.e. for example not have an h4 directly in an h2 section, always use nav for navigation menus etc., paragraphs, lists, footers and so on...
BTW: <div>s don't have any semantic meaning, so you can use these (together with class attributes) to do whatever to tweak the result visually for "not-read-mode".
We have inherited a website which we are currently trying to make WCAG2.0 AA compliant
One of the pages is failing the heading-order rule as it has an <h3> and <h4> tags but no prior <h1> or <h2>
We are in the process of adding an <h1> tag (as all pages should have one) but there is no need for an <h2> tag and to amend the <h3> and <h4> would involve a large refactoring of various jQuery code and CSS
Are there any tricks to make the page accessible? I'm loathed to put a hidden <h2> tag in as the screen readers would presumably pick this up. Or do they ignore the hidden tags and the page then becomes compliant?
Are you trying to satisfy WCAG 2.0 AA or are you trying to make the page accessible?
These are usually the same, but sometimes not.
A hidden <h2> would pass WCAG depending on how you hide it. That, however, would not make the page more accessible.
While this may suck, the best, most correct approach is to fix the <h3>s and <h4>s to become correct levels (that is my answer, the rest of this is fluff). Your question might be more appropriate if you instead provide some code samples and ask for tips on how to write a regex or otherwise script these replacements throughout the inherited system.
If you are being told you have no time to do it right, then code examples (or a sample site) might still be helpful to get some guidance.
I really have seen this situation before, and actually have fallen into this trap myself. By applying styles to the h3 and h4, it is possible to make a page look, well, a certain way.
Looking at the point of the header tags however, it is their purpose to add semantics to the document, as we all well know. Is it, therefore, meaningful to have a document outline where there is an h3 but no h2? Screenreaders and other accessibility tools use this header information and some could get confused.
My most influential decision-making point is, "how will the user consume this information?" Will they be able to consume it? Is it meaningful to skip a header level? I initially think not, but please let me know of your differing opinion!
If you really do care about accessibility, giving an empty h2 (even implicitly which is the case when you omit it) might give no clue, in some screen readers, of the announced section to users when they will navigate the outline of the document (1).
That being said, I can't find anywhere (neither WCAG or HTML5 documentation) where it's said that you can't omit one level of headings.
The only official (for HTML5.1) requirement is to use "headings of lower rank" to start new subsections, which should mean that you could use a h3 directly below a h1 but can't use another h1
Even the WCAG is giving an example using omitted ranks saying this example does not intend to prescribe the level for a particular section.
(1) HTML5.1 provides an outline algorithm where we can read about "implied headings" or about the use of the rank when there is an heading content element
I would say the best way to ensure compliance is to refactor the code that is in the javascript/CSS. To hide elements you could use the hidden attribute or aria-hidden.
https://www.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/
I have read a whole bunch of questions regarding where and how nav tags should be used and
I get that we are meant to put "major" navigational elements within it but what is it's purpose?
I can see that w3schools says that
"Browsers, such as screen readers for disabled users, can use this
element to determine whether to omit the initial rendering of this
content."
but does it have any further use, are there any other implications of omitting the <nav> tag?
It's a semantic improvement in HTML. A random section of the page with
<div>
<div>
<div>
<ul>
<li>...</li>
<li>...</li>
<li>...</li>
...
doesn't mean much in and of itself, and is only understood as being a "navigational" component when viewed by a user on the graphical page. Someone who is using a screen reader, or a text browser, or any kind of assistive technology would not know be easily able to understand the meaning behind the tag soup.
On the other hand, by enclosing your markup in meaningful, semantic tags, it would be very easy for a screen reader to understand that a specific part of the document is meant to be used as a nav, and take the necessary action.
In addition, it's also easier for a developer to look at the markup and immediately recognize what it is for.
<nav>
<ul>
<li>...</li>
...
The purpose of tags like <nav> is semantic markup: i.e. understand-ability and sensible descriptions of page elements. The alternative of <div id='nav'> is OK but much more clunky. Web crawlers and the like are much happier to find your content well described and laid out so I would recommend making use of tags like this as much as possible.
Tools/user-agents may (or may not) do anything with it; now or in the future.
You do your job (marking up your content), tools do their job (interpreting your markup). The only "implication of omitting" the nav element is, well, that these tools can’t use this information for their interpretation.
The nav definition gives a non-normative note:
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).
But it’s not hard to imagine other purposes:
text browsers may display the navigation differently
mobile browsers may offer a way to display/hide the navigation
search engines may ignore navigation content for ranking the page
printers may exclude the navigation by default
…
The more about the page structure is known, the more can be done with the page by various tools. It’s the whole point of the so-called semantic markup.
I wonder many websites put tag inside tag, from the specification the nav tag has anchors tags, and here the example in w3schools, why many sites make like this:
<nav>
<ul>
<li>Home</li>
<li>About</li>
</ul>
</nav>
Is that correct or we should only make like this
<nav>
Home
About
</nav>
In general it's not required, however it's very common practice to put your navigation items in list and using CSS displaying them inline (if required). That is not only advice for HTML5 - if you'll disable for an example CSS in the browser, your menu will be displayed as:
start about me contact (can you read this?)
with list it will be:
start
about me
contact
Consider yourself which version would you like to see in case of problems with displaying design.
What is important to note here is what the new tags like nav, section, header, footer, etc were designed for. In and of itself, these tags behave no differently than a div. The reason people are starting to use them on their html5 sites is to provide context to the document. While I roll my eyes when I hear terms like "Web 2.0", these terms do convey a change in thinking about how we use the web. Whenever you hear "Web 3.0"... ugh, all it really means is that people are trying to think about how to make the web more semantic, meaning the user experience is more customized based on user behavior and preferences. Tagging your document with these types of tags helps provide that context. The implementation of how it will present itself, however, is still up to you, and I believe both examples you provided are perfectly valid.
There is a decent article here which discusses this in more detail:
http://html5doctor.com/lets-talk-about-semantics/
I have always taken the view that any tag that exists purely to house another, single tag, is extraneous.
However semantic and sensible mark-up is an inexact science, so people have different views.
As per "nav" element specification, it represents a section of a page that links to other pages or to parts within the page. Specification does not mandate any particular structure whithin "nav" element. "ul" block, on the other hand, groups navigation links together for logical and/or practical purpose. Using lists for blocks of navigation benefits users who are navigating the Web with assistive technology, because screen reader may skip entire blocks of navigation, jumping from one navigation level to another.
References:
http://reference.sitepoint.com/html/ul
http://html5doctor.com/nav-element/
I would say:
Yes, if is multilevel nav (so will have it hierarchical ordered).
No, in all other cases: you save data, you gain speed, and readability.
IMHO UL should be use for showing actual Unordered List, the same is said about tables, that should show tabular data.