Comments on: HTML 5 to the H1 debate rescue? http://www.iheni.com/html-5-to-the-h1-debate-rescue/ Sat, 13 Mar 2010 14:52:21 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: grabur http://www.iheni.com/html-5-to-the-h1-debate-rescue/comment-page-1/#comment-19164 grabur Mon, 09 Nov 2009 04:46:35 +0000 http://www.iheni.com/?p=816#comment-19164 Does the problem arise from not being able to state where the end of a section occurs? It starts with a h1, but where does it end? Another h1, a hr, the end of the document? A few suggestions: frames, attributes or a meta element. I'd argue that there is no real point in defining a header and footer, as suggested in html5, when a normal html layout, clearly seperates the meta information from a document anyway. Then you can use a h1 for each frame. Just glue the frames together. Surely current usability issues could be fixed? How about using an attribute for a div, let's call it importance. So your content div would have an importance of 1, your div id=footer an importance of 8. Think z-index, but with meaning. Or a way to define page heirarchy in the head. A simple meta element, , this could use element ids. Or dream up some other use for meta elements. Perhaps: strong - sitename h2 - nav blah h2- subnav blah h1 - main heading blah With the above, just place less importance for the elements before the h1. Multiple h1s? Use the first or the last, and use the next h1 as a boundary. Don't want it to print? Hide elements in the style sheet. Otherwise, just take some of the ideas of HTML5 and use them as atributes that won't break existing html (nav, aside or perhaps m-index..). Like with microformats. Or maybe allow for a new meta element within the page itself. But that's probably not backwards compatible. I feel the classic frames, solution is the simplest. Does the problem arise from not being able to state where the end of a section occurs? It starts with a h1, but where does it end? Another h1, a hr, the end of the document?

A few suggestions: frames, attributes or a meta element.

I’d argue that there is no real point in defining a header and footer, as suggested in html5, when a normal html layout, clearly seperates the meta information from a document anyway. Then you can use a h1 for each frame. Just glue the frames together. Surely current usability issues could be fixed?

How about using an attribute for a div, let’s call it importance. So your content div would have an importance of 1, your div id=footer an importance of 8. Think z-index, but with meaning.

Or a way to define page heirarchy in the head. A simple meta element, , this could use element ids. Or dream up some other use for meta elements.

Perhaps:

strong – sitename
h2 – nav
blah
h2- subnav
blah
h1 – main heading
blah

With the above, just place less importance for the elements before the h1. Multiple h1s? Use the first or the last, and use the next h1 as a boundary. Don’t want it to print? Hide elements in the style sheet.

Otherwise, just take some of the ideas of HTML5 and use them as atributes that won’t break existing html (nav, aside or perhaps m-index..). Like with microformats.

Or maybe allow for a new meta element within the page itself. But that’s probably not backwards compatible.

I feel the classic frames, solution is the simplest.

]]> By: Dan http://www.iheni.com/html-5-to-the-h1-debate-rescue/comment-page-1/#comment-17600 Dan Thu, 08 Oct 2009 10:11:54 +0000 http://www.iheni.com/?p=816#comment-17600 Always happy to help. This is based upon strong / ongoing feedback from multiple seo consultants who have experimented with multiple page versions re headings and gauged their effectiveness in influencing search listings. That said, the focus on H1 should only mean that we maybe spend a little less time on optimising keyword text in these 'lesser' headings. It still pays to observe a well ordered and well worded headings structure given Google's push for best practice / well built websites. Lesser headings may not influence search engine results pages (SERPs) as much as H1, but we can assume spiders still read and index headings below H1 much like it does body copy, bold and italic text (the latter SEO measures are actually whole other debates in themselves because web editors often dislike using 'shouty' bold text in copy, while the use of italics in web copy is frowned upon in terms of web text being fully accessible for the visually impaired). Always happy to help. This is based upon strong / ongoing feedback from multiple seo consultants who have experimented with multiple page versions re headings and gauged their effectiveness in influencing search listings. That said, the focus on H1 should only mean that we maybe spend a little less time on optimising keyword text in these ‘lesser’ headings. It still pays to observe a well ordered and well worded headings structure given Google’s push for best practice / well built websites. Lesser headings may not influence search engine results pages (SERPs) as much as H1, but we can assume spiders still read and index headings below H1 much like it does body copy, bold and italic text (the latter SEO measures are actually whole other debates in themselves because web editors often dislike using ’shouty’ bold text in copy, while the use of italics in web copy is frowned upon in terms of web text being fully accessible for the visually impaired).

]]> By: iheni http://www.iheni.com/html-5-to-the-h1-debate-rescue/comment-page-1/#comment-17598 iheni Thu, 08 Oct 2009 09:47:04 +0000 http://www.iheni.com/?p=816#comment-17598 Hi Gooitzen - thanks for teh detailed response and outline of what you are working on. I'd love to see an actual page if I could so I get a better idea. By all means email me at henny at iheni dot com. Dan - It's always been a bit of a mystery how much search engines give weight to headings in their listing and is no surprise that it's really the H1 that is focused on. SEO per se is not my area so any bits of info like this is great. Hi Gooitzen – thanks for teh detailed response and outline of what you are working on. I’d love to see an actual page if I could so I get a better idea. By all means email me at henny at iheni dot com.

Dan – It’s always been a bit of a mystery how much search engines give weight to headings in their listing and is no surprise that it’s really the H1 that is focused on.

SEO per se is not my area so any bits of info like this is great.

]]> By: Dan http://www.iheni.com/html-5-to-the-h1-debate-rescue/comment-page-1/#comment-17522 Dan Tue, 06 Oct 2009 15:51:04 +0000 http://www.iheni.com/?p=816#comment-17522 It's fair to say the 'SEO camp' won't miss headings all that much anyway - search engines apply very little or no value to H2 or 'below' in terms of influencing SERPs. It’s fair to say the ‘SEO camp’ won’t miss headings all that much anyway – search engines apply very little or no value to H2 or ‘below’ in terms of influencing SERPs.

]]> By: Gooitzen van der Ent http://www.iheni.com/html-5-to-the-h1-debate-rescue/comment-page-1/#comment-15794 Gooitzen van der Ent Tue, 25 Aug 2009 10:41:40 +0000 http://www.iheni.com/?p=816#comment-15794 Thank you for this post. I enjoyed reading it. I fall into the category the second part of your article. Namely trying to use h1 tags to the most benefit, and use them so people that need to can easily, clearly and efficiently navigate through the website. Well that's the idea. Currently I am using heading tags as follows: h1 class accessibility Content h2 post title h3-h6 headings in post h2 comments h1 class accessibility Navigation and information h2 sitemap h3 headings in sitemap e.g. these are the categories, these are the pages h4-h6 additional headings where needed h2 RSS h3 headings in sitemap e.g. these are the categories, these are the tags h4-h6 h2 Contact h2 about me h1 accessibility Website name h1 class accessibility Copyright information h1 class accessibility Search h1 class accessibility Breadcrumbs etc.. The accessibility tag has a display:none in the screen style sheet. So it will only be shown when people need it. In other words the styling layout (for visible people) and the accessible layout are separated. I started with this in order to split the content into sections. From what I read in your article it will be implemented in HTML 5. It seems to me a logical way to go for screen readers, but I am not sure. It may be needed to structure it better, but not yet sure which people prefer. For example should the accessibility breadcrumbs be at the top or do people prefer the content at the top. From what I read (some) blind people ideally like the content first. I have not experienced any problems with search engines, and also pass automated tests for section 508, WCAG 1.0 or WCAG 2.0 on template pages that are completed. The pages pass W3C validation. Somebody was kind enough to point me to your article.. Just wanted to give you feedback on my progress. Thank you for doing a clear writeup. I am open for any suggestions to make the navigation as clear as possible for screen readers in this case. Thank you for this post. I enjoyed reading it. I fall into the category the second part of your article. Namely trying to use h1 tags to the most benefit, and use them so people that need to can easily, clearly and efficiently navigate through the website. Well that’s the idea.

Currently I am using heading tags as follows:

h1 class accessibility Content
h2 post title
h3-h6 headings in post
h2 comments

h1 class accessibility Navigation and information
h2 sitemap
h3 headings in sitemap e.g. these are the categories, these
are the pages
h4-h6 additional headings where needed
h2 RSS
h3 headings in sitemap e.g. these are the categories, these
are the tags
h4-h6
h2 Contact
h2 about me

h1 accessibility Website name
h1 class accessibility Copyright information
h1 class accessibility Search
h1 class accessibility Breadcrumbs
etc..

The accessibility tag has a display:none in the screen style sheet. So it will only be shown when people need it.

In other words the styling layout (for visible people) and the accessible layout are separated. I started with this in order to split the content into sections. From what I read in your article it will be implemented in HTML 5. It seems to me a logical way to go for screen readers, but I am not sure. It may be needed to structure it better, but not yet sure which people prefer. For example should the accessibility breadcrumbs be at the top or do people prefer the content at the top. From what I read (some) blind people ideally like the content first.

I have not experienced any problems with search engines, and also pass automated tests for section 508, WCAG 1.0 or WCAG 2.0 on template pages that are completed. The pages pass W3C validation.

Somebody was kind enough to point me to your article.. Just wanted to give you feedback on my progress. Thank you for doing a clear writeup. I am open for any suggestions to make the navigation as clear as possible for screen readers in this case.

]]>