#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)
Change History (30)
#2
@
10 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.
#3
@
10 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:
↓ 5
↓ 12
@
10 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.
#5
in reply to:
↑ 4
@
10 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.
#7
@
10 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:
↓ 10
@
10 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.
#10
in reply to:
↑ 8
@
10 years ago
Replying to iamtakashi:
Shouldn't the
entry-title
onimage.php
beh1
?
Yes, you're right. My fault there. Sorry about that. :)
Also I think we need a condition to switch
h1
andh2
incontent-link.php
to giveh1
for single view like afercia mentioned above.
That looks good!
Thanks for making my patch better!
#12
in reply to:
↑ 4
@
10 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:
- http://lists.w3.org/Archives/Public/public-html/2014Jan/0004.html
- http://www.w3.org/html/wg/drafts/html/master/sections.html#outlines
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:
↓ 18
@
10 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
@
10 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
This ticket was mentioned in IRC in #wordpress-ui by _Redd. View the logs.
10 years ago
#16
@
10 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!
#18
in reply to:
↑ 13
@
10 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
@
10 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.
10 years ago
This ticket was mentioned in Slack in #core-themes by iandstewart. View the logs.
10 years ago
#23
@
10 years ago
- Owner set to iandstewart
- Resolution set to fixed
- Status changed from new to closed
In 30072:
Related: #30057