The "h1 tag with an image" debate seems as old as time itself, but with HTML5 explicitly allowing multiple H1 tags as part of its spec, all the previous questions on this subject seem out of date.
As I understand it, the following works perfectly with the HTML OA:
<body>
<header>
<h1>
<a href="http://www.example.com">
<img src="logo.png" alt="Ernie's Restaurant - Great Italian food">
</a>
</h1>
</header>
<nav><!-- the site-wide navigation --></nav>
<article>
<h1>About us</h1>
<p>…</p>
</article>
</body>
But I'm working with an SEO company on a website and they've told me:
"The logo link CAN’T be H1. It doesn’t make sense."
Are they right? Is there something bad about the above document outline? If you can't put the logo in a H1 tag, why do the W3C do it themselves on their website?
These people are supposedly SEO experts, but I just don't understand their complaint. What am I missing?
Most of the time, you'd want to wrap the image in an anchor, which also has a title... See This answer and This answer.
Maybe they were just nervous about the lack of a proper anchor? The img tag is entirely legitimate.
Yes, you can have an img element as content of an h1 element.
Yes, it makes sense to have the img-logo as h1 (in case it belongs to the body sectioning root, like it does in your example).
If your site doesn’t show a separate textual name, you definitely should do this. Otherwise, the document outline could be wrong (if you don’t use sectioning elements wherever needed) or at least the outline would have an unlabeled top-level entry, which is not very user friendly/accessible.
If you have a site logo and a textual site name, it’s discussible: either include the img together with the text in the same h1, or have only one of these elements in h1 (either one is possible) and have the other one as "alternative title", e.g., together in a header element.
For examples, see some of my related answers on SO (1, 2, 3) and Code Review (1, 2, 3).
(Your "SEO expert" is not the only one having a problem with this, as you can see in some of the comments to my linked answers. I have yet to see an argument against it ….)
Related
The HTML <main> element represents the dominant content of the <body> of a document, portion of a document or application. The main content area consists of content that is directly related to or expands upon the central topic of a document, or the central functionality of an application. Quote Mozilla Dev.
Questions in my mind
#1
Do we support the same feature if we add a "role" to the "div" tag later? And the same special cases apply?
<div role="main"> == <main> ?
#2
The content of a <main> element should be unique to the document. Content that is repeated across a set of documents or document sections such as sidebars, navigation links, copyright information, site logos, and search forms should not be included unless the search form is the main function of the page.. Quote Mozilla Dev.
It really is a special situation or too much of a relative exceptional situation. A relative explanation.
The only concrete thing I understand (Tree Structure)
eg. wrong usage
<header>..</header>
<article>
<main></main>
</article>
<aside>..</aside>
<footer></footer>
eg. correct use
<header>..</header>
<main>
<article>..</article>
</main>
<aside>..</aside>
<footer></footer>
So actually the question in my mind is starting right here.
<header>..</header>
<main>
<article>
<form>
<input type="text" name="user_name" />
....
....
</form>
</article>
</main>
<aside>..</aside>
<footer></footer>
Now that I use the form element after the main tag, is this an incorrect use?
Screenshot of my project page tree
This a landing page, and the form a register action "Special for this document". So now googlebot read it for collective website form "Like a search form", finally created a negative scenario?
I mean is that the content of the main tag should only be composed of pure text? Sources are a complete mystery!
If we give a much more specific example
Youtube
Youtube using role="main"
My review: Tag including, the search form and navigation menu. Because search form main characteristic for youtube...
As a result of this:
For example, If I have a search engine page and I am including the search form after the main tag;
Scenario 1:
I made a violation of the rules in a strict manner and the undesired motion was negatively affected by the seo, the tree making is wrong.
Scenario 2:
It is not an obvious violation of the rules, but an undesirable aspect of the advice. Googlebot etc. it will not be a negative situation for seo because it can not detect whether the violation is valid (because it is affecting the main content, perhaps using it).
Is there any good idea or technical support?
Like most HTML semantics, a good dose of pragmatism is helpful. Fragmentation of the main role in WAI-ARIA is possible, but strongly disliked and therefore not valid for the <main> element. What that means is that the main element should be the minimal container to hold everything that is the principal content of the page. If that incidentally contains things that would be placed outside the main element if the tree structure permitted it, that should just be accepted as a necessary deviation from the ideal.
I'm in the process of marking up a site and I've been really trying to hone my accessibility skills. I'm wondering what the most semantic mark-up is for tabbed content. This is what I have now:
<section>
<nav>
Stuff
Stuff
Stuff
</nav>
<section id="content" aria-live="polite" role="region">
<article>...</article>
<article>...</article>
<article>...</article>
</section>
</section>
I have a few specific questions about this.
Am I on the right track? If not can someone recommend some changes?
Will I need to make changes if I were to load in the articles via AJAX?
Do I need the nav tag?
Are WAI-ARIA roles enough here?
Are these the correct WAI-ARIA roles to use?
1.Am I on the right track? If not can someone recommend some changes?
Yes, you've absolutely started in a good way. Some of the tab stuff could be given some tab-related roles if you want to improve it, but it's functional as is.
2.Will I need to make changes if I were to load in the articles via AJAX?
No. It should be fine. The fact that it is a live region should (tested with NVDA only) mean that new content is announced. Is this the behaviour you're after?
3.Do I need the nav tag?
No, but I think it helps make it crystal clear what that bit of the document is for. A note though, that if you do what I've done below and mark it as a tablist, the fact that it's a navigation element doesn't get announced anymore.
4.Are WAI-ARIA roles enough here?
If by ARIA roles you're also including states and properties, yes essentially you should be covered for loading dynamic content (if that's what you're after). There's no case for moving the user's keyboard focus or anything with things as they are. IMO, you'd only really want to do that if there's a lot of navigational stuff between what the user clicked and what content you're giving them.
5.Are these the correct WAI-ARIA roles to use?
You're not far off. If you really want a tab-style experience, then you need the tablist, tab and tabpanel roles. I'll give an example.
I've taken your code and made a contrived but working example to test it. It's not loading anything in AJAX, just showing and hiding stuff. I wanted to be sure before I gave this answer, but I'll put the code here too in case it helps.
<html>
<head>
<title>Aria test</title>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<script type="text/javascript">
$(document).ready(function() {
$('nav a').on('click', function () {
hideArticles();
deslectAllTabs();
$(this).attr('aria-selected', true);
var tab = '#' + $(this).attr('aria-controls');
$(tab).show();
});
});
function hideArticles() {
$('article').hide();
}
function deslectAllTabs() {
$('nav a').attr('aria-selected', false);
}
</script>
<style type="text/css">
article { display: none; }
</style>
</head>
<body>
<section>
<nav role="tablist">
Stuff1
Stuff2
Stuff3
</nav>
<section id="content" aria-live="polite" role="region">
<article id="content1" role="tabpanel">The lazy dog jumped over the quick fox</article>
<article id="content2" role="tabpanel">If you click this tab then your life will be better</article>
<article id="content3" role="tabpanel">Know your roles</article>
</section>
</section>
</body>
</html>
I hope this helps.
Semantics tend to get vague at this level, but yeah I think you're on the right track as long as each of the tabs would really count as a separate article.
The article element represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.
Source
I don't think the <nav> is misplaced here, although it depends on how important the different tabs are in regards to the whole of your website:
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. Not all groups of links on a page need to be in a nav element only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a list of links to various key parts of a site, but the footer element is more appropriate in such cases, and no nav element is necessary for those links.
Source
I wouldn't use sections to wrap the stuff in it though.
The section element is not a generic container element. When an element is needed only for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element's contents would be listed explicitly in the document's outline.
Source
An additional rule of fist for the <section> element is that they should have a title. If not, it's probably not really a "section" but just a group of elements that you needed to wrap in something, so just use a <div>.
The first Google search result for "html links" says (paraphrased) that to create a bookmark / section inside a webpage, we've to do this:
<a id='section-2'>Section 2</a>
so that we can link to it like this:
<a href='page.php#section-2' >Click</a>
But why the site is recommending using anchor tag around "Section 2"? -When it can be done using span:
<span id='section-2'>Section 2</span>
Are there compatibility issues? Because the first search result for "creating bookmarks within a webpage" also says to surround the heading with anchor tag:
<p><a name="title">Title</p>
Though this particular example is incorrect for various other reasons.
I've a supplementary question:
Why to surround the heading with the container when it can be done simply like this:
<span id='section-2'></span>Section 2
Does it matter?
<span id='section-2'>Sec</span>tion 2
<a href='page.php#section-2' >Click</a>
There is no point. W3schools is unreliable, just don’t use it, and you will avoid confusion and wrong information; see http://w3fools.com
In the old days, the only way to set a destination anchor within a page was to use <a name=...>...</a> element (at the text level). Later, the id attribute was added and is now supported by all browsers in use, so you can make any element a destination anchor simply by attaching an id attribute to it. E.g., to make it possible to link to a heading like <h2>Section 2</h3>, you could make it just <h2 id=section-2>Section 2</h2>. No need for an artificial extra element.
Using <span id='section-2'></span>Section 2, though formally correct, is not a good idea. You win nothing by using it, as opposite to the more logical markup. And if you e.g. later want to style (highlight) the element to which the user has “jumped” into with a link, using the :target pseudo-class, you will find yourself in an awkward position: the pseudo-class would let you style just the empty content of the span.
Regarding the question in the title, there is no reason to make the top of a page an destination anchror, with <a id='top'>Top of page</a> or otherwise. First, you can refer to the start of the page using just href=# since by URL specifications, # denotes the start of the current resource. Second, “Back to top” links are basically useless or worse: every browser has a simple command for going to the start of the page, and an explicit “Back to top” link can be confusing: back to top of what?
In the early days of html an anchor element was the only way to do this, but just because you can now do it with other element types doesn't mean you should: using an anchor for this purpose is semantically correct because it makes it clear to anybody reading or maintaining your markup that the element is intended as a navigation target. (Noting that there will often be many elements on the page that have an id but are not navigation targets.)
"Why to surround the heading with the container when it can be done simply like this:
<span id='section-2'></span>Section 2
Because if you put the text of your heading inside an element you can style it and/or easily mess with it from JavaScript. Indeed, if it is a heading you may want to put it in an <h1>, <h2>, etc. tag rather than a <span>.
I am using a Chrome outliner extension to check the semantics of my page. It seems to be a problem to have any structural element before the h1 in the document main header tag. I was thinking the order does not matter, but apparently it does:
+Document Body
+Header
+nav
+h1 Main Navigation
+h1 MyPage
-Section
-Footer
Does outline like this:
Untitled Body
Main Navigation
MyPage
etc...
But when the h1 is the first element in my header:
+Document Body
+Header
+h1 MyPage
+nav
+h1 Main Navigation
-Section
-Footer
it does outline like this:
MyPage
Main Navigation
etc...
Why is that? Is the outliner buggy, or did I understand something wrong in HTML5 semantics? The W3C Specification does not seem to mention it: http://dev.w3.org/html5/spec/Overview.html#the-header-element
After revisiting the specs, I agree that the h1 does not have to be the first element. I suspect the issue is with the chrome extension you are using.
I ran the following two scenarios through this HTML outlining tool and received the same results (My Navigation appears under My Header):
With h1 second element under header:
<body>
<header>
<h1>My Header</h1>
<nav><h1>My Navigation</h1></nav>
</header>
<section><h1>My Section</h1></section>
<footer></footer>
</body>
With H1 first element under header:
<body>
<header>
<nav><h1>My Navigation</h1></nav>
<h1>My Header</h1>
</header>
<section><h1>My Section</h1></section>
<footer></footer>
</body>
Why are you defining another <h1> tag outside of your title of your page? The outliner is picking up two contending titles for your page and is probably why is being thrown off. Semantically speaking, the main title of a page can exist anywhere inside your <header> section of your page as long as its unique and defines your main title, though that is not an exclusive property of the <header> section or the <h1> tag (and opinions vary to that description but it is more sound). Proper outline is defined here http://www.w3.org/TR/html5/sections.html#outline.
You can write your main heading section using any combination you want, as long as it is properly understood. So;
<header>
<nav>
<h1>Title of Page</h1>
<h2>Subtitle</h2>
</header>
Is fine, because it is properly understood what the sections of your header and title of your page are.
Here is an online outliner that you can use to test your design. Your title section should be first above everything else.
According to the specs a <header> doesn't need to start with an <h1>.
A header element is intended to usually contain the section's heading
(an h1–h6 element or an hgroup element), but this is not required. The
header element can also be used to wrap a section's table of contents,
a search form, or any relevant logos.
I'm trying to use the <a> tag in HTML5 more as a container as this tag can now have block elements as children, example:
before (valid XHTML 1.1)
<div>
<h3>
article title
</h3>
<p>
text
</p>
<a href="page.html" title="article title" >
<img alt="image">
</a>
<a href="page.html" title="article title" >
read more
</a>
</div>
after (valid HTML5)
<a href="page.html" title="article title" >
<h3>
article title
</h3>
<p>
text
</p>
<img alt="image">
<div>
read more
</div>
</a>
Does this new way of markup have any effects for SEO?
OK, removing pure semantics from your question (which, in my mind, does have a material impact on deciding on implementing your chosen method) and concentrating on pure "SEO" value and impact:
The first example needs to be qualified more, as if we take your example as literal, then you are linking to the same page.html 3 times. Google (specifically) only takes the link anchor value from the 1st link to any page that it comes across, so - the value for the first example is only extracted from that first link. The 2nd link (using an IMG tag with an ALT attribute as the anchor value), and the 3rd link using read more as the anchor value are effectively "ignored". It's important that other signals are used to supplement the first link's true intended value, such as surrounding text, images etc.
The 2nd example (HTML5), wraps all of that semantic/surrounding content up to make the effective 'anchor' value from which search engines will derive the link's intended meaning, and then as a consequence, the meaning of the destination page of the link.
Using an anchor tag as a containing wrapper for content that contains additional emphasis (the H tag), an image and an additional div only increases the difficulty that a search engine has to decipher the intended meaning of the link so it can associate it with the destination page.
Search engines (and Google predominantly) are constantly improving their crawling ability to enable better algorithmic parsing and processing of the HTML. Apart from emphasis signals (which are very low), Google mostly ignores the mark-up. The exception is of course links - so making an effort to simplify the parsing/processing by providing clear signals as to a link's anchor text is the safest way forward. Expecting them to understand all of the differences of HTML3, vs HTML4, vs HTML5 and all of the transitional, strict and other variations of each, is probably expecting too much.
TL;DR
Possibly, but only in terms of true link value.
As far as i know in the second way is not bad in anyway in term of seo But first may be slightly better as the titles,images are more closely linked to link.
Q. But better by how much?
A. May be not too much