Make WordPress Core

Opened 13 years ago

Closed 13 years ago

#17611 closed defect (bug) (fixed)

TwentyEleven Theme H1 Priority

Reported by: emiluzelac's profile emiluzelac Owned by: azaozz's profile azaozz
Milestone: 3.2 Priority: normal
Severity: normal Version: 3.2
Component: Bundled Theme Keywords: has-patch dev-feedback
Focuses: Cc:

Description

As I was going over the codes in TwentyEleven Theme, I've notice that H1 (Headings) are used in places where H1 as the highest priority is not recommended to be used. From SEO Search Engine Optimization point of view giving i.e. (LATEST COMMENTS) priority #1 (H1) is not semantically correct nor Search Engine Friendly. This will most definitely confuse web crawlers not knowing what they need to crawl frist.

My suggestion is to lower the priority to all sidebar titles to at least H4, or even eliminate any headings from this area completely. Simple <div class="widget-title">Some Title</div> will be more than enough and it will serve the purpose just fine.

This will be even greater issue if user activates the widgets in footer area and there we don't really need an H1 titles.

Even uglier scenario is to hide H1 under <h1 class="section-heading">Post navigation</h1> in functions.php

Now I do understand that this is still work in progress and hopefully you will address this issue accordingly. Other than this great job guys I love how far you went with this.

Attachments (6)

screenshot-01.gif (198.9 KB) - added by emiluzelac 13 years ago.
screenshot-02.gif (25.2 KB) - added by emiluzelac 13 years ago.
screenshot-03.gif (43.7 KB) - added by emiluzelac 13 years ago.
17611.diff (6.0 KB) - added by c3mdigital 13 years ago.
Patch
17611b.diff (6.9 KB) - added by c3mdigital 13 years ago.
Reverts to twentyten headings
17611-heading-corrections.diff (15.5 KB) - added by iandstewart 13 years ago.

Download all attachments as: .zip

Change History (74)

#1 @scribu
13 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 3.2
  • Type changed from enhancement to defect (bug)

Traditionally, widget titles have been wrapped in h3 tags.

#2 @emiluzelac
13 years ago

that would be acceptable :)

#3 @scribu
13 years ago

  • Cc iandstewart added

#4 @iandstewart
13 years ago

The widgets in Twenty Eleven, marked up with the aside element, are top-level "sections" of the main page and it's semantically correct for them to have h1 headings in HTML5.

#5 @scribu
13 years ago

It might be semnatically correct, but is is good for SEO?

#6 @iandstewart
13 years ago

As of October of last year it was neither good nor bad with the possibility that it might be good in the future.

"In general, we work hard to understand as much of the web as possible, but I have a feeling that HTML5 markup is not yet as widely in use (and in use correctly) that it would make sense for us to use it as a means of understanding content better. As HTML5 gains in popularity and as we recognize specific markup elements that provide value to our indexing system, this is likely to change, but at the moment I would not assume that you would have an advantage by using HTML5 instead of older variants."

http://www.google.com/support/forum/p/Webmasters/thread?tid=2d4592cbb613e42c&hl=en

#7 follow-up: @iandstewart
13 years ago

Anectdotally, I haven't noticed any negative effects with using h1s as the primary heading in sectioning elements.

#8 in reply to: ↑ 7 @emiluzelac
13 years ago

Replying to iandstewart:

Anectdotally, I haven't noticed any negative effects with using h1s as the primary heading in sectioning elements.

Instead of giving more explanations why this isn't good, here is a video http://www.youtube.com/watch?v=GIn5qJKU8VM.

#9 @iandstewart
13 years ago

That video from 2009 doesn't address HTML5 markup nor does it say using multiple h1 headings is bad. It ends with "I would use [the h1 heading] where it makes sense and more sparingly but you can have it multiple times" What it does say is bad is h1 for everything on the page. "If your entire page is h1, that looks pretty cruddy, right? So don't use ALL h1 …"

#10 @emiluzelac
13 years ago

This Theme will be used by many people and we the community must be sure that it looks good and it does but also with the respect to what is correct as far as the search engines.

I don't buy the idea that:

<h1 class="widget-title">Latest Comments</h1> should be an H1

or that we hide the H1 in Main Menu and navigation links such as:

<h1 class="section-heading">Main menu</h1>

You stand correct multiple H1 is not bad practices however we should consider that there will be more H1 added by the user and combining all that with 2011 defaults will create a mess.

#12 @iandstewart
13 years ago

The spec also recommends using h1 elements for sectioning elements. h2 would also be acceptable for the widgets (as noted by the spec), if we're concentrating on those, but I think it outlines better with widgets using h1 as the content there is usually tangentially related to the page as a whole rather than always specifically related to the articles on a page -- as might be suggested in the outline by using h2 elements there.

The same goes for elements like nav.

Here's the home page outline for the Twenty Eleven Demo site:

http://gsnedders.html5.org/outliner/process.py?url=http%3A%2F%2Ftwentyelevendemo.wordpress.com%2F

#13 @iandstewart
13 years ago

Of course, as noted by scribu, the semantics of using h1 as primary headings in sectioning elements aren't necessarily related to SEO. And the position of Google as noted above, at least in October of last year, was that HTML5 markup in general was neither good nor bad as far as they were concerned.

#14 @emiluzelac
13 years ago

Neither good nor bad is the gray area that I am very skeptical about :(

Would it be to complicated to change and make sure that Twenty Eleven SEO falls into current guides and that we change the widgets to H3 for example and footer titles to H4, as well as removing H1 from the elements that are not visible? IMHO this feel like right thing to do.

There was a good article on this from Yoast http://yoast.com/blog-headings-structure/ and http://diveintohtml5.org/semantics.html#header-element

Anyways it's up to you to decide if this needs an attention or not.

#15 @matveb
13 years ago

The last link you posted contains the proper explanation of why using h1 repeatedly for top level elements makes sense. If you scroll to http://diveintohtml5.org/semantics.html#footer-element you will see an almost identical example of turning h3s into h1s for the footer titles, once the sectioning elements are properly laid out.

#16 @emiluzelac
13 years ago

@matveb semantics and search engine friendly are often tied, but not the same. Point well taken from the link and let's say that this will indeed be the new way of proper SEO (and we don't know that yet) but <h1 class="section-heading">Main menu</h1> does not fall into this area. Not from old, current or HTML5 as the future standard.

Experimental is one thing if this was a value-added Theme, however Twenty Eleven is new Twenty Ten and IMHO we cannot experiment with default Theme that will be used by possibly millions of users. My proposal is to abide the old rules and stick with what we know and one day when HTML5 is globally accepted as the new standard we can make changes.

For right now this does not seem to be right or fair to WP users. Not knowing and that neutral area between the hot and cold is the entire point of the original ticket. Once again IMHO only.

Last edited 13 years ago by emiluzelac (previous) (diff)

#17 @emiluzelac
13 years ago

Not to mention many of the devs who will base their Theme on Twenty Eleven.

#18 @iandstewart
13 years ago

Emil, from the articles and video you've linked to and the section from the spec you've pointed to, everything seems A-OK with the markup in Twenty Eleven — as far as nav and aside headings go. I'm not seeing any SEO concerns.

#19 follow-up: @jorbin
13 years ago

  • Keywords close added; needs-patch removed
  • Resolution set to fixed
  • Status changed from new to closed

I agree with Ian. Our concern should be providing a semantic theme that is driving innovation and that is exactly what twenty-eleven does. HTML5 is the doctype that was chosen for twenty-eleven and we are implementing it properly.

I suggest closing as invalid.

#20 @jorbin
13 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#21 @jorbin
13 years ago

Woops, didn't mean to actually close it yet.

#22 @aaroncampbell
13 years ago

I'm inclined to agree with Ian and Aaron. If we're going to use an HTML5 doctype then we should be trying to properly use HTML5.

Also, this certainly doesn't have to affect child themes. True, it will unless the author of the child theme changes it, but it's pretty simple to change.

#23 @emiluzelac
13 years ago

I was pointing to:

<body>
 <h1>Foo</h1>
 <h2>Bar</h2>
 <blockquote>
  <h3>Bla</h3>
 </blockquote>
 <p>Baz</p>
 <h2>Quux</h2>
 <section>
  <h3>Thud</h3>
 </section>
 <p>Grunt</p>
</body>

Take a look at the source from Google's very own Paul Irish - http://html5boilerplate.com this is the perfect example of what I think we should do.

Let me break the code and refer to exact comparison:

H1 & H2

    <div id="header">  
         <p class="lang" dir="ltr">Now offered in:          
         </p>        
         <h1>HTML5  <i>&#x2605;</i> <b>Boilerplate</b></h1> 
         <h2>A rock-solid default for HTML5 awesome.</h2>

This is good comparing to Twenty Eleven √

H3

         <div id="intro" > 
           <p>HTML5 Boilerplate is the professional badass's base HTML/CSS/JS template for a fast, robust and future-proof site.</p>  
       
       
           <h3>Why it is awesome</h3> 
           <ul> 
             <li>Cross-browser compatible (IE6, yeah we got that.)</li>  
           </ul>

H4

      <div class="focus"> 
        <div id="builder" class="clearfix"> 
          <p>Click on your favourite option for each feature! Default options are highlighted.</p> 
          <div id="cond"> 
            <h4>Conditional classes</h4>          
            <a id="no-cond" href="#">Nope</a> 
          </div> 

H5

    <h4>Webserver Configs</h4> 
    <h5>.htaccess</h5> 
    <ul> 
      <li>.htaccess is far more documented now. Take a read through it!</li> 

Let's disregard all* links posted by me above and take this example into consideration please. This is 100% HTML5 site correct? and no H1 is hidden and no H1 used where there is no need of H1 priority.

Your thoughts?

#24 @emiluzelac
13 years ago

Well it isn't 100% HTML5 it's rather mix, but you see my point.

#25 in reply to: ↑ 19 @emiluzelac
13 years ago

Replying to jorbin:

I agree with Ian. Our concern should be providing a semantic theme that is driving innovation and that is exactly what twenty-eleven does. HTML5 is the doctype that was chosen for twenty-eleven and we are implementing it properly.

I suggest closing as invalid.

Our concern is not to experiment with default Theme if there is something we don't really know about than I suggest we don't use it. HTML5 great I am all for that, but we can't assume that every site owner will actually create children and make the changes that fits their needs.

This is not a big deal at all and the changes are/can be done in 10 minutes.

#26 @emiluzelac
13 years ago

Anyways feel free to close my ticket.

#27 @iandstewart
13 years ago

The HTML5 Boilerplate site doesn't have any sectioning elements. It's not an exact comparison. I don't see how it compares to how Twenty Eleven uses the h1 element as a primary heading for nav and aside alongside the main page and each article.

#28 @emiluzelac
13 years ago

just that yes, the use of headings, I did correct myself above, sorry :(

#29 @emiluzelac
13 years ago

Please take a look at the screenshots and let me know if you think that this is reasonable and acceptable. I had to convert PNG to GIF due to upload size limits. Hopefully I did not take too much of your time guys.

#30 @iandstewart
13 years ago

Thanks for the screenshots, Emil. I don't think that would be an improvement over the existing semantic markup in Twenty Eleven. All the examples you've provided point to the current markup being correct as-is and not a concern SEO-wise.

#31 @emiluzelac
13 years ago

Do you mind sharing why the heading priorities are no SEO concern?

#32 @emiluzelac
13 years ago

Hi guys this is what I got from Paul Irish - https://twitter.com/#!/paul_irish/status/75747971232305152

Would this be enough proof to make changes or we still think that as is and not concern? http://www.w3.org/TR/html5/sections.html#outlines

What I gathered is that Twenty Eleven is great example of:

"Sectioning content is content that defines the scope of headings and footers article aside nav section"

And it seems to fail here:

"Heading content defines the header of a section (whether explicitly marked up using sectioning content elements, or implied by the heading content itself)."

h1 h2 h3 h4 h5 h6 hgroup

Even noted on the above link Note: Recall that h1 has the highest rank, and h6 has the lowest rank.

I am not going to waste your time here and please forgive me for going that extra mile and asking Paul about this, maybe, just maybe we can look at the subject bit differently if the information comes from someone like him.

Thanks and I really appreciate all of your comments here and also sorry for providing few bad examples above.

#33 @nacin
13 years ago

Your question to Paul failed to address the use of <section>, which changes the semantic context.

I'm all for a definitive theoretical answer, and a definitive practical one. But I also don't think we're off base.

#34 @emiluzelac
13 years ago

I understand what you are saying Nacin and yes everything is implemented properly much better than what I would personally do at this time and no that part was not off base at all. But I still believe that H1 tag should not be hidden or any other heading tags for that matter and also H1 to every and all titles across the site. Even without definitive answer that don't seem to make sense to me.

Paul confirms that headings and their priorities do apply to HTML5 and the patch is very straight forward and it will not hurt the Theme in any way. If I knew how to submit one via SVN I would do it and if needed I am willing to make an off-trac changes and submit them.

If somehow we can gather more information to prove my original theory (other than Paul) this would be helpful for Duster and Toolbox as well I am not sure what other Themes are using similar tags.

#35 @emiluzelac
13 years ago

Unless this answers my and your question: http://www.w3.org/TR/html5/sections.html#the-h1-h2-h3-h4-h5-and-h6-elements

These two snippets are equivalent:

<body>
<h1>Let's call it a draw(ing surface)</h1>
<h2>Diving in</h2>
<h2>Simple shapes</h2>
<h2>Canvas coordinates</h2>
<h3>Canvas coordinates diagram</h3>
<h2>Paths</h2>
</body>
<body>

 <h1>Let's call it a draw(ing surface)</h1>
 <section>
  <h1>Diving in</h1>
 </section>
 <section>
  <h1>Simple shapes</h1>
 </section>
 <section>
  <h1>Canvas coordinates</h1>
  <section>
   <h1>Canvas coordinates diagram</h1>
  </section>
 </section>
 <section>
  <h1>Paths</h1>
 </section>
</body>

#36 @nacin
13 years ago

Money quote:

Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section's nesting level.

See: http://www.w3.org/TR/html5/sections.html#headings-and-sections

So if we're nesting <sections>, then we *could* start at h2. The document goes on to suggest that with each nested <section>, increasing the heading # might result in the document being "more clearly expressed", but emphasizes according to the spec that "Both of the documents above are semantically identical and would produce the same outline in compliant user agents.".

It finally states "This third example is also semantically identical, and might be easier to maintain (e.g. if sections are often moved around in editing)" and goes on to suggest straight h1's at the top of every section element.

I support our current markup. But I'm inclined to go along with the third example, and thus any h1 inside a section becomes an h2. This is for purely practical and anti-pedantic reasons -- I'm not looking forward to the Trac tickets or support threads, and I agree that it will be more clear to someone deriving a theme from Twenty Eleven what's going on (who hasn't learned PHP and even HTML semantics from the default WordPress theme?). And who knows what'll happen when this post becomes flooded with proclaimed SEO experts.

I'm just surprised there hasn't been a wp-hackers thread yet.

#37 @emiluzelac
13 years ago

Very well good enough for me. We have 36 comments here and I feel that everyones time is wasted by me and I apologize for that.

#38 @iandstewart
13 years ago

@nacin I think dropping down a heading level to h2 on nav and aside (widget) elements would be OK but dropping down a heading for every sectioning element would get weird with articles leading off with an h1 on single.php, h2 on index.php, and h2 or h3 on archive.php (where you have article elements nested in a section nested in a page). Said weirdness is why I went with the specs recommendation of using h1 as the primary heading in sectioning content.

But h2 would be OK for nav and aside if it heads off tickets, support threads, and proclaimed SEO experts.

#39 follow-up: @emiluzelac
13 years ago

@ianstewart you probably seen this http://yoast.com/wordpress-seo-theme/ (post from yesterday)

Use the H1 for the logo, on every page.
The H1 should be used for the most important heading on the page. In most cases, that is the article title, not the logo, on every page but the homepage. There's a lot more to say about headings, which I've done in my HTML Heading Structure article.

#40 in reply to: ↑ 39 ; follow-up: @joostdevalk
13 years ago

  • Cc joost@… added

Replying to emiluzelac:

@ianstewart you probably seen this http://yoast.com/wordpress-seo-theme/ (post from yesterday)

Use the H1 for the logo, on every page.
The H1 should be used for the most important heading on the page. In most cases, that is the article title, not the logo, on every page but the homepage. There's a lot more to say about headings, which I've done in my HTML Heading Structure article.

In all fairness, my post should have stated "if it's not HTML5". I wouldn't change 1 bit from how it is now, even when Google doesn't get it right now, they will soon enough.

#41 @aaroncampbell
13 years ago

  • Keywords close removed
  • Milestone 3.2 deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

#42 in reply to: ↑ 40 @emiluzelac
13 years ago

Replying to joostdevalk:

Replying to emiluzelac:

@ianstewart you probably seen this http://yoast.com/wordpress-seo-theme/ (post from yesterday)

Use the H1 for the logo, on every page.
The H1 should be used for the most important heading on the page. In most cases, that is the article title, not the logo, on every page but the homepage. There's a lot more to say about headings, which I've done in my HTML Heading Structure article.

In all fairness, my post should have stated "if it's not HTML5". I wouldn't change 1 bit from how it is now, even when Google doesn't get it right now, they will soon enough.

I know that we had many comments here and IMO that's definitely good thing, not only for me but for all future tickets we might have in the future. This is most certainly great stuff now that at least I know that Google doesn't understands HTML5 the way they do for previous types.

Thanks!

#43 follow-up: @scribu
13 years ago

  • Milestone set to 3.2
  • Resolution wontfix deleted
  • Status changed from closed to reopened

I think the following article makes a very valid point on why H1-everywhere headings should not be used yet:

You can keep using h1-h6 in HTML5, but you can also choose to use only h1 elements for all headings and rely on the HTML5 outline algorithm to sort out the heading hierarchy. If you do this, however, you should be aware that currently there is very little support for the HTML5 outline in web browsers, screen readers and developer tools.

http://www.456bereastreet.com/archive/201106/on_using_h1_for_all_heading_levels_in_html5/

Last edited 13 years ago by scribu (previous) (diff)

#44 in reply to: ↑ 43 @emiluzelac
13 years ago

  • Cc emil@… added

Replying to scribu:

Good find!

Last edited 13 years ago by scribu (previous) (diff)

#45 @nacin
13 years ago

  • Component changed from Themes to Bundled Theme

#46 follow-up: @iandstewart
13 years ago

If we're going to fall back to a more traditional heading structure I'd stick with following Twenty Ten's example.

#47 in reply to: ↑ 46 @emiluzelac
13 years ago

Replying to iandstewart:

If we're going to fall back to a more traditional heading structure I'd stick with following Twenty Ten's example.

That would be good.

#48 follow-up: @iandstewart
13 years ago

After thinking it over, I think I'd rather use h2 headings for nav and sidebar aside elements as I initially suggested earlier in the thread. It'd be a cleaner change, simpler compromise, and should address the concerns noted by 456 Berea St. A patch should only have to address header.php, comments.php, the sidebar templates, and the Twenty Eleven nav function.

@c3mdigital
13 years ago

Patch

#49 in reply to: ↑ 48 @c3mdigital
13 years ago

  • Cc chris@… added
  • Keywords has-patch added

Replying to iandstewart:

After thinking it over, I think I'd rather use h2 headings for nav and sidebar aside elements as I initially suggested earlier in the thread. It'd be a cleaner change, simpler compromise, and should address the concerns noted by 456 Berea St. A patch should only have to address header.php, comments.php, the sidebar templates, and the Twenty Eleven nav function.

Patch based on Ian's comments above.

#50 @Elpie
13 years ago

  • Cc Elpie added

Just a few issues I want to raise:

A more traditional h1-h6 heading structure is the ONLY structure that currently works for all browsers and assistive devices. Ref: http://www.456bereastreet.com/archive/201106/on_using_h1_for_all_heading_levels_in_html5/

Using <hgroup> is perilous. In the last couple of months it has been in the draft, removed from the draft, and back in - pending more research. It is designed only for outline algorithms, with the outline algorithm showing only the highest level heading tag. It is currently not used by any browsers or assistive devices.

Post titles on the home page should not be all h1. This makes the outline completely flat and will cause problems for screen readers and other assistive devices.

Not related to heading elements:
tabindex can be (and should be) removed. This was a useful technique back in the 1990's to provide some keyboard accessibility for documents that were badly structured. TwentyEleven has issues with keyboard navigation at the moment. However, changing headers and removing tabindex should eliminate these.

For consistency, you might want to look at using HTML 5 for the forms. Some other elements are also not HTML 5 - such as <br />. This should be <br>. type="text/css" and type='text/javascript' are also not used in HTML 5. Removing these only saves a few bytes but would be good practise in a showcase theme.

#51 @bobeaston
13 years ago

Accessibility is the reason I would encourage using a properly structured outline of heading tags. (hearty support of Elpie) Someone, somewhere (reference not at hand at the moment) recently bemoaned that only about half of screen reader users actually use the heading identification feature of their screen readers. The other part of that half-full glass is that almost half DO use the features. In a world of feature rich, and sometimes too-rich, software, a feature that gains usage by half the users is very impressive.

Knowing the intended heading level is a way for the blind user to understand the relative importance of a bit of content. For those who have never experienced a screen reader, one of the features is to navigate from heading to heading by pressing a "heading hot key." At each heading the level is announced, followed by the actual text. It is provides a very fast way of gaining the sense of a document without having to listen to every bit being read ... much like the visual scan many of us can perform every time we open a new page. Having everything shout "Hey, look at me. I'm the most important." is a sure recipe for confusion. In this regard, blind users and SEO are very similar.

The HTML5 outline algorithm might someday give us relief in this area, but it is FAR too early to consider it even half done, let alone ready to eat. Few browsers accommodate it so far, and even fewer screen readers.

Vote for the people who need every accessibility option we can accommodate. Use as good a heading structure as we know how, and let the HTML5 stuff cook until it's done.

Last edited 13 years ago by bobeaston (previous) (diff)

#52 @emiluzelac
13 years ago

Visually impaired do rely on screen readers and magnifications, however there are others who use special browsers, where this special browser will need to determine, site structure and navigation as well. http://www.afb.org/Section.asp?SectionID=57&TopicID=167&DocumentID=2175

<br /> from above, well someone said this nicely: <br/> is an indication of poor semantic HTML.

I am leaning towards Ian's #comment:48

#53 follow-ups: @iandstewart
13 years ago

So. h1 should be used as the primary heading for all sectioning content (the page itself, section, article) with the exception of navigation and widgets (nav, aside) which will use h2. This is semantically OK, should be OK for SEO, and should be OK for accessibility since it reduces the importance of menus and widgets in a screen reader.

Is that the consensus we've reached?

#54 in reply to: ↑ 53 @emiluzelac
13 years ago

Replying to iandstewart:

So. h1 should be used as the primary heading for all sectioning content (the page itself, section, article) with the exception of navigation and widgets (nav, aside) which will use h2. This is semantically OK, should be OK for SEO, and should be OK for accessibility since it reduces the importance of menus and widgets in a screen reader.

Is that the consensus we've reached?

If we could use H3 for Widgets (nav, aside) that IMO would be even better and if not your proposition is all right by me. The reason why H3 there is because of the users, just in case they add H2 as subheadings and most of them do. With this, both SEO and Semantics will be satisfied.

#55 in reply to: ↑ 53 ; follow-up: @bobeaston
13 years ago

Replying to iandstewart:

So. h1 should be used as the primary heading for all sectioning content (the page itself, section, article) with the exception of navigation and widgets (nav, aside) which will use h2. This is semantically OK, should be OK for SEO, and should be OK for accessibility since it reduces the importance of menus and widgets in a screen reader.

Is that the consensus we've reached?

While quite a bit better, the strict accessibility consultants among us will object. The Web Content Accessibility Guidelines (W3C)http://www.w3.org/TR/WCAG20-TECHS/G141 advise strict outlining, and many accessibility consultants agree that the ONLY one H1 should be the page title. All else, articles, sections, etc. should be H2 or lower. That would leave H3 or H4 for nav and widgets.

#56 in reply to: ↑ 55 ; follow-up: @emiluzelac
13 years ago

Replying to bobeaston:

Replying to iandstewart:

So. h1 should be used as the primary heading for all sectioning content (the page itself, section, article) with the exception of navigation and widgets (nav, aside) which will use h2. This is semantically OK, should be OK for SEO, and should be OK for accessibility since it reduces the importance of menus and widgets in a screen reader.

Is that the consensus we've reached?

While quite a bit better, the strict accessibility consultants among us will object. The Web Content Accessibility Guidelines (W3C)http://www.w3.org/TR/WCAG20-TECHS/G141 advise strict outlining, and many accessibility consultants agree that the ONLY one H1 should be the page title. All else, articles, sections, etc. should be H2 or lower. That would leave H3 or H4 for nav and widgets.

Twenty Ten uses HTML5 doctype, Twenty Eleven is HTML5. There is no point going back with an old markup at all.

#57 in reply to: ↑ 56 ; follow-up: @bobeaston
13 years ago

Twenty Ten uses HTML5 doctype, Twenty Eleven is HTML5. There is no point going back with an old markup at all.

Perhaps you missed the earlier remarks about HTML5...

  1. Very few browsers currently exploit the HTML5 outline constructs.
  2. Currently ----NO---- screen readers or other assistive technology interpret the HTML5 outline constructs.

There *IS* a point to going back to the old markup: making it accessible ... until user agents catch up.

#58 in reply to: ↑ 57 ; follow-up: @emiluzelac
13 years ago

Replying to bobeaston:

Twenty Ten uses HTML5 doctype, Twenty Eleven is HTML5. There is no point going back with an old markup at all.

Perhaps you missed the earlier remarks about HTML5...

  1. Very few browsers currently exploit the HTML5 outline constructs.
  2. Currently ----NO---- screen readers or other assistive technology interpret the HTML5 outline constructs.

There *IS* a point to going back to the old markup: making it accessible ... until user agents catch up.

I think that we are taking this ticket away from the subject and going back instead of forward. WordPress already stepped into HTML5 and this big improvement must not be degraded in any way, especially going back to HTML4, completely or just partially. Twenty Ten uses HTML5 doctype since 3.0 release, Twenty Eleven is a huge step towards the future and HTML5 Themes, suggestion to go back honestly makes little sense.

See: http://googleenterprise.blogspot.com/2011/06/our-plans-to-support-modern-browsers.html

As of August 1st, we will discontinue support for the following browsers and their predecessors: Firefox 3.5, Internet Explorer 7, and Safari 3. In these older browsers you may have trouble using certain features in Gmail, Google Calendar, Google Talk, Google Docs and Google Sites, and eventually these apps may stop working entirely.


#59 follow-up: @scribu
13 years ago

@emiluzelac: What exactly are you arguing against? When I suggested we use H3 tags for widgets, at the beginning of this thread, you were ok with it.

#60 in reply to: ↑ 58 ; follow-ups: @bobeaston
13 years ago

Replying to emiluzelac:

...

I think that we are taking this ticket away from the subject and going back instead of forward. WordPress already stepped into HTML5 and this big improvement must not be degraded in any way, especially going back to HTML4, completely or just partially. ...

Who said anything about reverting the DOCTYPE?

* Using the HTML5 DOCTYPE and providing accessibility are not mutually exclusive. *

All of the W3C documents about accessibility constantly advise using proven techniques until user agents catch up when new technology is introduced. Since few browsers and NO screen readers support the section / outline technology, traditional heading structures should be preferred.

My interest in this ticket arose from Jane Wells' repeated call for accessibility experts. In both of the recent releases she has made the call to improve WP accessibility. Most recently here: http://make.wordpress.org/accessibility/2011/05/06/hello-accessibility-experts-we-were-re/ and here: http://make.wordpress.org/accessibility/2011/05/06/if-anyone-would-like-to-take-a-stroll-th/

Yet, it seems that advancing to the latest and greatest technology is more important than improving accessibility. I think I'm done here.

Last edited 13 years ago by bobeaston (previous) (diff)

#61 in reply to: ↑ 60 @Elpie
13 years ago

Agreeing with bobeaston:

Who said anything about reverting the DOCTYPE?

* Using the HTML5 DOCTYPE and providing accessibility are not mutually exclusive. *

All of the W3C documents about accessibility constantly advise using proven techniques until user agents catch up when new technology is introduced. Since few browsers and NO screen readers support the section / outline technology, traditional heading structures should be preferred.

Using h1 elements for section, article etc just because the draft HTML 5 spec says this *may* be done does not mean its a good idea. HTML 5 uses h1-h6 headers. The draft spec's references to h1 tags relies very much on the HTML 5 outline algorithm. This is not implemented in any browsers yet.
The outline algorithm that is currently used is the same as it was for HTML4/XHTML1.

HTML5 is great. I am developing almost solely with it myself BUT care has to be taken to present the right structure with the right emphasis. One of the reasons we can use it is that browsers are designed to ignore any elements they don't understand. Screen readers and other assistive devices are designed to read the browsers but they rely on documents being accessible.

If you haven't already read it, here's a great article that shows the current state of screen reader handling of HTML5 and WAI-ARIA roles: http://www.accessibleculture.org/research/html5-aria-2011/

#62 in reply to: ↑ 59 @emiluzelac
13 years ago

Replying to scribu:

@emiluzelac: What exactly are you arguing against? When I suggested we use H3 tags for widgets, at the beginning of this thread, you were ok with it.

I am no arguing against H3 and I am all for that :)

#63 in reply to: ↑ 60 @emiluzelac
13 years ago

Replying to bobeaston:

Replying to emiluzelac:

...

I think that we are taking this ticket away from the subject and going back instead of forward. WordPress already stepped into HTML5 and this big improvement must not be degraded in any way, especially going back to HTML4, completely or just partially. ...

Who said anything about reverting the DOCTYPE?

* Using the HTML5 DOCTYPE and providing accessibility are not mutually exclusive. *

All of the W3C documents about accessibility constantly advise using proven techniques until user agents catch up when new technology is introduced. Since few browsers and NO screen readers support the section / outline technology, traditional heading structures should be preferred.

My interest in this ticket arose from Jane Wells' repeated call for accessibility experts. In both of the recent releases she has made the call to improve WP accessibility. Most recently here: http://make.wordpress.org/accessibility/2011/05/06/hello-accessibility-experts-we-were-re/ and here: http://make.wordpress.org/accessibility/2011/05/06/if-anyone-would-like-to-take-a-stroll-th/

Yet, it seems that advancing to the latest and greatest technology is more important than improving accessibility. I think I'm done here.

You wrote:

There *IS* a point to going back to the old markup: making it accessible ... until user agents catch up.

And I was only going by what you said that is all :(

#64 @nacin
13 years ago

There's been enough discussion -- patch please. Patch should revert to Twenty Ten's headings structure.

#65 @nacin
13 years ago

  • Keywords needs-patch added; has-patch removed

@c3mdigital
13 years ago

Reverts to twentyten headings

#66 @c3mdigital
13 years ago

  • Keywords has-patch dev-feedback added; needs-patch removed

Patch reverts to Twenty Ten's headings. <hgroup> left in place, removing would require additional css changes.

#67 @iandstewart
13 years ago

I've added an updated patch that

  • Reduces the heading level by 1 for posts that aren't is_singular, making the headings h2 for "indexed" posts
  • Makes the headings in nav and page-level aside elements h3
  • Leaves the site title an h1 element with the tagline an h2 on all pages inside an hgroup. To fully match Twenty Ten's heading pattern, with a dynamic heading for the site title, we should also use a dynamic heading for the first nav element on the page too which seems like too much for me.
  • Add a missing nav heading in image.php
  • Removes unneeded nav and heading in single.php

There are still pages with multiple h1s. Archive pages will have 1 for the site title and 1 for the page title (Category Archives: X). The Showcase will have three h1s; the site title, the featured post heading, and the recent post heading. I don't see this as a problem though.

#68 @azaozz
13 years ago

  • Owner set to azaozz
  • Resolution set to fixed
  • Status changed from reopened to closed

In [18335]:

TwentyEleven Theme H1 Priority, props iandstewart, fixes #17611

Note: See TracTickets for help on using tickets.