WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#30065 closed enhancement (fixed)

Twenty Fifteen: Heading Structure

Reported by: bramd Owned by: iandstewart
Milestone: 4.1 Priority: normal
Severity: normal Version: 4.1
Component: Bundled Theme Keywords: has-patch commit
Focuses: accessibility Cc:

Description

In Twenty Fifteen almost all section headings are h1.
Since such an HTML 5 outline does not really work in practise and there is no support from assistive technology (screenreaders etc) for it, I propose to change all section headings to h2 to get a consistent document outline in all user agents and assistive technologies.

I know we have a main role for the main content, but there is often a hotkey to directly jump to h1's in screenreaders, but there is no hotkey to go directly to main. So, changing heading levels will also help screenreader users wishing to go directly to the main content and not using the skip link for various reasons.

Attachments (5)

30065.patch (5.3 KB) - added by davidakennedy 3 years ago.
30065.1.patch (5.4 KB) - added by rianrietveld 3 years ago.
changed is_single() ) into ( is_singular() )
30065.2.diff (5.0 KB) - added by iamtakashi 3 years ago.
30065.3.patch (6.0 KB) - added by afercia 3 years ago.
30065.4.patch (7.3 KB) - added by davidakennedy 3 years ago.

Download all attachments as: .zip

Change History (30)

#2 @davidakennedy
3 years ago

Bram,

Thanks for filing this ticket! This came out of the Accessibility team's testing session.

To explain it a bit further: As Bram mentioned, the way the theme is coded now is perfectly valid, but screen readers and other assistive technology do not support the HTML5 document outline, where nested h1 elements are nested properly to convey a meaningful structure. This blog post by the Paciello Group explains it well: http://www.paciellogroup.com/blog/2013/10/html5-document-outline/

This is one of the cases where the technology doesn't support the standard yet.

@davidakennedy
3 years ago

#3 @davidakennedy
3 years ago

My patch turns a number of h1 elements into h2 elements, making the structure a bit more meaningful for all users. Most of the changes were on archive page views.

#4 follow-ups: @rianrietveld
3 years ago

  • Keywords has-patch needs-testing added

Hi David,

Tested the patch. Looks good :-)
In content.php there is a check

if ( is_single() )

, maybe it's better to do

if ( is_singular() )

, then it works also with attachments and page post types.
http://codex.wordpress.org/Function_Reference/is_single

Added a patch for that, 30065.1.patch

Furthermore, and this may be a bridge to far to change for this theme: There still is always a double H1. One for the site title, and one actual H1 that represents the content.

To my opinion, the best solution would be:
Don't put headings on the site title and the site description.
And put the (real) H1 directly above the content, in this theme:
In <header> of <main>.
If home is "Your latest posts", use the site title as H1 and hide it by adding a screen-reader-text class, because in this case home is in fact an archive without a visual title.

This way every webpage has a unique and meaningful H1 and the title is always on the same place in the HTML, super easy for screen reader users and (to my opinion) also better for SEO.

Last edited 3 years ago by rianrietveld (previous) (diff)

@rianrietveld
3 years ago

changed is_single() ) into ( is_singular() )

#5 in reply to: ↑ 4 @iamtakashi
3 years ago

Replying to rianrietveld:

, then it works also with attachments and page post types.

I'm not sure if this is necessary. We have content-page.php for pages, image.php for image attachments, and is_single() returns true for the single view of non-image attachments.

#6 @iandstewart
3 years ago

  • Milestone changed from Awaiting Review to 4.1

#7 @afercia
3 years ago

about content-link.php please consider you can always get the "single" link post clicking on the date in the post footer, and in the single view the title should be H1

#8 follow-up: @iamtakashi
3 years ago

I've looked into closely 30065.patch.

Shouldn't the entry-title on image.php be h1?
Also I think we need a condition to switch h1 and h2 in content-link.php to give h1 for single view like afercia mentioned above.

@davidakennedy, I could update your patch myself but I wanted to hear your opinion.

@iamtakashi
3 years ago

#9 @iamtakashi
3 years ago

I went ahead to update the patch.

#10 in reply to: ↑ 8 @davidakennedy
3 years ago

Replying to iamtakashi:

Shouldn't the entry-title on image.php be h1?

Yes, you're right. My fault there. Sorry about that. :)

Also I think we need a condition to switch h1 and h2 in content-link.php to give h1 for single view like afercia mentioned above.

That looks good!

Thanks for making my patch better!

#11 @iandstewart
3 years ago

In 30009:

Twenty Fifteen: Use a p for the site description for a better experience when using a screenreader.

Props rianrietveld, fixes #30057, see #30065.

#12 in reply to: ↑ 4 @davidakennedy
3 years ago

Replying to rianrietveld:

Furthermore, and this may be a bridge to far to change for this theme: There still is always a double H1. One for the site title, and one actual H1 that represents the content.

To my opinion, the best solution would be:
Don't put headings on the site title and the site description.
And put the (real) H1 directly above the content, in this theme:
In <header> of <main>.
If home is "Your latest posts", use the site title as H1 and hide it by adding a screen-reader-text class, because in this case home is in fact an archive without a visual title.

I wanted to reply to Rian and leave my thoughts. This also relates to #30057.

Previously, the heading structure was very future-leaning, a fantastic thing. I think the solution we have currently in the patch is an improvement. It takes a bunch of <h1>s and a flat document structure and creates a nice middle ground with less <h1>s and more structure, which is also future leaning but mindful of current support in browsers and assistive technology. I always favor better than before and released code over aiming for perfection in unreleased patches.

About potentially moving to one <h1> per page: I think it's a good goal. I also think that if we have two <h1>s, the site title and the main content heading, it's not the end of the world. That's me though, someone who tests for accessibility with assistive technology but doesn't use it each and every day, all day.

There isn't any hard advice in the WCAG 2.0 guidelines about specifically using one <h1> per page:

http://www.w3.org/TR/WCAG20-TECHS/H42.html

But the code examples provided only use one <h1>. :)

The W3C recently changed its advice on headings because of the outline issue:

All of the well-known accessibility consultant agencies use one <h1> per page:

The Paciello Group: http://www.paciellogroup.com/blog/
WebAIM: http://webaim.org/blog/
Deque: http://www.deque.com/blog/
Nomensa : http://www.nomensa.com/insights

Simply Accessible uses two <h1>s on the index page, one for site title and one for main content heading. The single view page has one <h1>: http://simplyaccessible.com/

Knowing all this: What's the best decision for this default theme, WordPress and the many sites and situations it will power?

Maybe a good middle ground is two <h1>s for the index/home page and one everywhere else?

#13 follow-up: @joedolson
3 years ago

It's my opinion that the site title should never be a heading -- it doesn't serve structurally as a heading within the page; and any 'heading' characteristics it should have semantically are easily fulfilled by using the <header> structural container.

If you consider the value of headings from a structural and navigational perspective, having a top-level heading for the site title is almost never valuable -- all it does is affirm that yes, you're still on this site. This is information that you've already received from the <title> element, so it's hardly new information.

#14 @afercia
3 years ago

About the site description, users may enter the optional "Tagline" or may not, in the second case the theme will print an empty paragraph:
<p class="site-description"></p>
I'd propose to add a simple check for an empty description. Also, the updated patch is now based on the root directory of your SVN WP install

@afercia
3 years ago

This ticket was mentioned in IRC in #wordpress-ui by _Redd. View the logs.


3 years ago

#16 @sharonaustin
3 years ago

Tested patch 30065.3 on this site http://red-hound.com/trunk29747/trunk/src/ (4.1-alpha-30031 at the time of testing) and it works as intended; only site-title and entry-title have <h1> after the incorporation of this patch. Great thanks to all for the commitment to accessibility!

#17 @sharonaustin
3 years ago

  • Keywords needs-testing removed

#18 in reply to: ↑ 13 @davidakennedy
3 years ago

Replying to joedolson:

It's my opinion that the site title should never be a heading -- it doesn't serve structurally as a heading within the page; and any 'heading' characteristics it should have semantically are easily fulfilled by using the <header> structural container.

If you consider the value of headings from a structural and navigational perspective, having a top-level heading for the site title is almost never valuable -- all it does is affirm that yes, you're still on this site. This is information that you've already received from the <title> element, so it's hardly new information.

Thanks for weighing in Joe. That's a good point about the <title> element. I think it makes sense to move to one <h1> per page here. It would give us an even cleaner outline and structure, good for semantics, assistive technology and search engines.

If

  • home page is blog index and front page: site title is <h1>
  • home page is page and blog index is page: site tile is <p> on home page and hidden <h1> in <header> above post listing on blo index page is the title for the blog index page: get_the_title( get_option( 'page_for_posts' ) );. Similar to .page-title markup.

This should give us a unique <h1> on every page.

Am I missing any use cases with the combination of is_home() and is_front_page()?

#19 @davidakennedy
3 years ago

  • Keywords needs-testing added

With my latest patch, I:

  • Change site title markup depending on page.
  • Add H1 to blog index page (if it's not the front page).
  • Improve patch with check on site description from @afercia.

This ticket was mentioned in Slack in #core-themes by iandstewart. View the logs.


3 years ago

#21 @iandstewart
3 years ago

  • Keywords commit added; needs-testing removed

This ticket was mentioned in Slack in #core-themes by iandstewart. View the logs.


3 years ago

#23 @iandstewart
3 years ago

  • Owner set to iandstewart
  • Resolution set to fixed
  • Status changed from new to closed

In 30072:

Twenty Fifteen: Use a heading heirarchy to provide a better navigation experience when using screenreading software.

Props davidakennedy, rianrietveld, iamtakashi, afercia, davidakennedy, fixes #30065.

This ticket was mentioned in Slack in #core-themes by philip. View the logs.


3 years ago

This ticket was mentioned in Slack in #core-themes by philip. View the logs.


3 years ago

Note: See TracTickets for help on using tickets.