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..
Related
Say I'm building a typical document editor:
Where the preview (in red) is an up-to-date, formatted vue of the form's data.
The preview element contains semantic elements (e.g. h1, h2, main, header, etc.). It's kind of a document in itself, which does make sense, conceptually. But this makes the structure of the real document quite confusing for crawlers and screen readers. There might be, for instance, two h1 or main elements. I'm looking for a way to avoid that.
Plus, there's the problem of repetitive content (see image).
For the accessibility part of the problem, I could just add an aria-hidden="true" attribute to the preview element. In fact, visually-impaired people don't need the preview, it's just redundancy to them, they just need the form.
But for crawlers, here are my options:
Don't use semantic elements inside the preview element, use divs instead (😥).
Host the preview at an other URL and insert it via an iframe (that's what I'm doing right now, but it seems hacky to me).
Leave it like that, crawlers don't care.
Any idea/resource/suggestion?
As long as your preview area is clearly indicated for assistive technology, it's perfectly fine to have redundant information. If you have an <iframe>, make sure there's a title attribute on it.
<iframe title="preview area"...>
However, you might have validator issues with multiple structure elements.
For example, HTML only allows one <main> element:
A document must not have more than one main element that does not have the hidden attribute specified.
You can have multiple <header> elements but a <header> has a default role of banner and the banner role says:
Within any document or application, the author SHOULD mark no more than one element with the banner role.
The key here is "should", meaning it's a strong recommendation but not required. You can also get away with multiple banner roles if your preview section has role="document".
I would recommend not using non-semantic elements (div) because an assistive technology user might want to check the actual semantic structure of what's generated, although I suppose you could also have a "show in new tab" option for the preview that uses all full semantics, kind of like your second bullet but not using an iframe.
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/
<nav> typically has <a> elements inside it, but is it required? I have a radio button form whose purpose is akin to navigation. It doesn't navigate to other pages on the Internet, but instead changes the visibility of elements within the body of the HTML document (like a carousel).
Thanks! I've been wrestling with semantic markup tonight!
tl;dr: No, the nav element requires links (but not necessarily a elements).
W3C’s HTML5 defines the nav element like this:
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.
By default, a radio button doesn’t link to a part within the page. In your case, it changes the visibility of an element on the page. So it’s not appropriate to use the nav element for this purpose (unless, maybe, changing the radio button focuses the changed element; but that behaviour might be bad for usability).
The whole point of semantics, is that when viewed in an entirely different light, it's still readily clear in how to derive meaning and relational context from the content.
A web browser will parse your HTML out of the Dom after every load or change, and construct an opinion based on that about the content. The browser will keep this handy to itself internally in case it needs it later to assist it with difficult judgement calls should it be asked to perform a seemingly complex operation.
For example, someone who has really poor eyesight might enable an accessibility feature on their mobile device that tacks on a variety of different visual styles adding a great deal of visual emphasis to interactible elements they can touch, depending on the type of interaction. This could be something like a bright color coated and outlined overlay on top of elements, perhaps something like cyan for multimedia controls, yellow for form elements, and magenta for navigation points. This feature would have to work on any and all possible content which the browser will ever render, and so what you've got is a hidden under the hood runtime script that the browser is using to dynamically parse what ever it's loaded in order to construct some sort of opinion which it can lean on exorcise what will hopefully be good judgement. So no matter how clear your navigation might seem visually to someone with great eyesight, this is why semantics are such a big deal and why it's so important we continue to make efforts to use them correctly, as here you have a machine alternatively parsing your source code because it has zero comprehension of it's otherwise visual context.
When it comes to accessibility, browsers are much more complex in forming their opinions than just simply parsing the Dom. In a scenario such as this example, and the code you're wanting to write, wrapping your navigation elements in a nav tag should properly assist the browser into making the right call. Even if they're not link tags, the browser is going to take note of any elements inside of a nav tag witch active event listener handles items like click and similar.
As another user mentioned, semantics is all about judgement. There are countless other ways which good semantics play a role into good development, dry code and easier maintainability being my two favorites. There are no hard lines for "can do" and "can't do", but practicing good semantics is still pretty easy to do regardless. Just continually ask yourself these couple of questions about your core content-
• If someone or something tried to use this in ways which I'm not explicitly building in targeted functionality for, do I think it will be able to understand what content is what and the associated intents well enough to be successful at what ever is being attempted?
• If I was to refactor or repurpose any of this later, is there a clear separation of content, logic, and style? Is my content clean, and meaningfully distinguished? Is it so clean and ready, that I can just rip it out and drop it into something new with little or no change? Essentially, how portable is this content? Is it plug and play level portable? And if not, could it be made more portable with better semantics?
Practice developing with proper semantics using those couple of core guidelines, and you'll almost always be perfectly fine.
Just to make sure I've directly addressed your question- Yes. What you've done is "okay", and "semantically legal" 🙂
A website I am working on uses Adobe Search&Promote (SP) as it's internal website indexing and searching tool.
I need to exclude common parts of each web page from being indexed by SP (such as the header, nav, footer) because they are the same on every single page.
SP's documentation states the following:
"To prevent parts of individual web pages from being searched, you can exclude portions of a page from indexing. Surround the text with <noindex> and </noindex> tags. This method is useful if you want to exclude navigation text from searches."
Of course, <noindex>, is not a standard HTML tag/element.
Is there javascript or something I should be doing to register/create this fake tag in browsers so I don't have to worry about any strange behavior as a result of having a non-standard HTML tag just hanging out in my code? Or should I just not care because browsers will ignore this non-existent element?
Note: There is absolutely no styling that needs to be done on this <noindex> element. It simply needs to wrap around content in the HTML.
There is nothing you need to do. Browsers are expected to ignore unknown tags, and they do, so they see <noindex>foo</noindex> just as foo. Well, not quite. Technically, modern browsers construct an element node (of type HTMLUnknownElement) in the DOM. But the element has no associated default styling and no associated action, so it’s really a dummy element and represents its content only.
It would be possible to remove such elements nodes using client-side JavaScript, but that would be quite unnecessary.
The only real risk is that some day some specification or some browser or some web-wide indexing robot might start treating noindex as a real element with some defined meaning, possibly with default rendering and default functionality. Then you would be in trouble if these differ from what you expected. But it’s a rather small risk, and it seems that you don’t have a choice.
Although it's not in the documentation, our team consulted an Adobe consultant regarding this. He told us that we can use a 'noindex' class instead of the <noindex> element. He was even recommending us to use the class instead of the tag.
A warning though, the 'noindex' class is only working with <div> elements but not on other elements such as <ul>, <header>, or <footer>.
So a usage will be something like this:
<div class="noindex">
<p>This should not be indexed.</p>
</div>
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.