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/
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..
I'm following the CodeSchool foundation course now with HTML. Its saying its 'not OK' to not have a <h2> heading as the top one:
we removed the h1 tag and replaced it with an img tag. That's fine, but it also means that our highest level heading right now is an h2 tag, which isn't OK.
Is this going to affect the final product or is it just a design thing?
Nothing will break if there is a h2 and no h1. However, the way computers read websites, is by parsing the HTML. The only way the computer knows that something is a top-level header (h1) is by finding the h1 tag.
The most common reason I can think of at the moment, as to why you want h1 insted of h2, is how search engines index your website. Using a h1, means that the text within the tag is highly relevant to your website, while h2 is not as important (but still more important than h3 for example).
So it's not about what works and don't works, but it's about what things should be. Writing a website, following all the "rules" of HTML, will make it easily parsable by crawlers (programs that parse websites and gather information).
Another, important, reason why your html should be well-structured is for blind people. They use programs that read out text from websites to "read" the website. Having bad semantic/bad structured html might make these programs useless.
Edit:
Sorry, as mentioned, document outline would break, but the website would still be rendered, which is what I was referring to.
The heading elements are used to provide semantic meaning to your content (as most HTML elements do). In addition, people who use assistive technologies, such as screen readers, rely on certain HTML elements to provide information as to how to navigate a page. The heading elements (h1...h6) help to create the page's Document Outline, for which there is a defined specification.
If you were to start with an h2, the outline would be broken.
Just as it makes no sense to stat a report on section 2, you should not start a web page there for the same reason.
SEO
Search Engine Optimalization! If a person searches for, say, "Rubik's Cubes", a search engine will look through their data to see which sites have the string "Rubik's Cubes" (or some substring or related words) on their site.
Now, if your site has the string "Rubik's Cubes" in an <h1> tag, the search engine will understand that this is the entire point of your page, and rank it higher, because it's the title of the entire page!
Meanwhile, if you have it in an <h2> it's probably just some part of the page, and that's fine too, but not AS good.
So while structurally, it makes no difference, think of SEO when you choose which header you use. If you're picking them just based on size, that's a bad idea. Just style them bigger/smaller instead!
<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" 🙂
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.
When it comes to writing blog markup, I absolutely understand the use of article and section tags. But my masthead sections have two widgets. One has a search engine embedded and the other is marketing copy leading to an FAQ page.
What would be the correct HTML5 markup in this case? How do I mark up widget functionality?
my masthead sections have two widgets. One has a search engine embedded...
A search engine embedded? Do you mean a search field, i.e. a text field into which you can type search terms? For that, you want <input type="search">.
...and the other is marketing copy leading to an FAQ page.
Does this really qualify as a “widget”? If it’s marketing copy “leading” to an FAQ page, that just sounds like a link to me, which has been semantically represented in HTML since version 1 with the <a> element.
HTML is pretty simple, you really don’t want to over-think it. You don’t need specific tags for everything people could possibly give a name to. (What exactly is a “widget”? Isn’t it just a section of the page?) For most things, <section> is fine.
While HTML5 is a big improvement, there's one thing it doesn't fix: The subjectivity of what is considered proper semantics for every situation.
And, I doubt HTML will ever fix that.
If you're already using HTML5 containers for other more obvious parts of the page, I wouldn't sweat these too elements much. You could put the marketing stuff in an aside. Search could be considered a form of nav. But...I don't think bad karma will come your way if you just stick them in a couple of divs, either. ;)