HTML5 Headings in WordPress: A11y versus SEO?

How to get a WordPress developer all emotional and fanatic: discuss about heading structure.

Here’s my point of view on how headings should be set up in a WordPress theme. And an overview of the pros and cons brought up in discussions.

Semantic, meaningful headings in HTML5

One H1 to rule them all

  • One unique H1 per page, post or archive
  • Only on the homepage the H1 can contain the logo or the site title
  • On pages the H1 is the page title
  • On posts the H1 is the post title
  • On archives the H1 is the archive title

Use H2 t/m H6 in the content itself to give meaning to the structure of the content, like the index of a book. H2 for a paragraph, H3 for a sub-paragraph, etc. Don’t skip or mix up headings.

Best practice for the logo or the site title

  • On the homepage the logo or site title can be put into an H1. This is not a link, because that will be a link to the page itself.
  • The H1 can also be a (hidden) page title above the content, your choice.
  • On other pages the logo or site title is a link to the homepage and not an H1 .

Site description or tagline

The site description is no H2 because a heading should be followed by content of any sort (e.g. page content, widgets, navigation).


  • Give the sidebar a (hidden) meaningful H2 heading
  • Give the widgets inside the sidebar an H3 heading
  • Don’t use a H1, H2 or H3 inside a widget


  • Give the footer a (hidden) meaningful H2 heading
  • Give the footer widgets a H3 heading
  • Don’t use a H1, H2 or H3 inside a footer widget


Give a navigation <nav> a meaningful heading, fitting the heading stucture of your theme. Like an H2 containing “Main navigation”.

HTML5 sections

Give HTML5 sections a meaningful semantic heading. Steve Faulker explains this in The HTML5 Document Outline.

Why is this structure important

People using a screen reader depend on headings to understand the structure of a site. What is the page about (H1), where is the navigation, what is important content and how is the content divided.
They can navigate a site using headings, quickly jump to a heading of interest. A heading “main navigation” or “sub menu” saves them a lot of time.

How can I see what the heading structure is like?

Use for example the Firefox Add-on Accessibility Evaluator. It adds a Accessibility menu to your browser with lots of useful info, one of them is “Headings”.

Heading menu

And this is what the heading structure of looks like:

Heading structure of

Homework: take your site and run it through the Accessibility Evaluator, now you can see how a screen reader user understands your web page. Does it tell a story about the structure of your page?


“I only use H1’s, because in HTML5 you can”

When HTML5 came out, using a H1 for every section was a way of dividing your content. Super easy, no thinking needed.

Don’t use only H1’s: screen reader users get lost. What is important? How do I navigate, what is the structure? A sighted person can easily see how a page layout is build, a screen reader user has to listen and often guess. Did I mention Google is blind?

Sidebars and Footers

It’s hard to give a sidebar or footer a meaning full heading. The content may change per page or archive, and a heading like “Primary Sidebar” or “Complementary Content” doesn’t say much about the content. This is the hard part and I am open for suggestions on how to solve this.
One solution could be to give the content manager the option to also add a sidebar title when adding widgets in the Admin.

WCAG 2.0

If your site has to comply with WCAG, a meaningful heading structure is a must. In WCAG 2.0 it is allowed to skip headings, but the headings must be meaningful (descriptive).

The objective is to make section headings within Web content descriptive. Descriptive headings and titles work together to give users an overview of the content and its organization. Descriptive headings identify sections of the content in relation both to the Web page as a whole and to other sections of the same Web page.

More on WCAG 2 and headings:


Theme builders want their HTML optimized for Google. Google needs to be told what is important or not.

Now this is a point of much debate. What does Google need? How much weight should I give a widget or a subtitle? In the Genesis Framework all widgets have an H4, telling Google: this content is not very important.

Giving all pages the same first H1 using the site title and then  give the site description an H2, as most WordPress themes do, is to my opinion bad practice. Even if you change the title in your SEO options. But I’m no SEO expert, if you are: please give me your opinion.

So: who do you build for? For your sighted users and for the search engines? Be honest now. Do accessibility rules conflict with SEO best practice? And how complicated will your code get if you want to address all people, also the ones that depend on their ears to understand your site.

Manga art in the featured image by Suuzan on deviantART.

Storytelling in HTML: practical accessibility

For my work I build sites for blind people. They use a braille line and screen reader to read and navigate a website. During the development of those websites I learned that blind people read a web page differently than I do.

Blind web users read a page linearly and depend on headings and links to navigate.

This changed the way I build site dramatically, I changed from visual coding to story telling coding. Continue reading Storytelling in HTML: practical accessibility

Working on web accessibility at WordCamp San Francisco 2014

WordCamp San Fransisco 2014 (WCSF14), the place to be if you’re seriously into WordPress. Visiting San Francisco with the accessibility contributors team was a week I won’t forget. It was intense, fun, I spoke a zillion people and learned a lot. Continue reading Working on web accessibility at WordCamp San Francisco 2014

Jet lag and double Dutch at WCSF14

For me WordCamps are all about meeting, learning, talking and discussing. Last week I was so lucky to be able to visit WordCamp San Francisco 2014 (WCSF14) with the accessibility contributors team.

After the conference there was a discussion day about several topics to improve WordPress and two days of working with different contributor teams to make new plans and work together. This last three days were held at Automattic, which was kind of special.

Graham Armfield will blog about what we did as a team and what our plans are, and I blogged about WCSF14 itself, but here’s what I learned personally.

Continue reading Jet lag and double Dutch at WCSF14

How to set up an accessible form using Contact Form 7 in WordPress

Recently I discovered Contact Form 7 (CF7) by Takayuki Miyoshi. A plugin to create forms on a WordPress website. I was looking for an accessible alternative for Gravity Forms, and discovered that Contact Form 7 does an excellent job! Continue reading How to set up an accessible form using Contact Form 7 in WordPress

Teaching WordPress to 23 visually impaired content managers

The Oogvereniging (Eye association) has a WordPress WCAG 2.0 AA website that is maintained by more than 20 volunteers, all with different visual impairments. Teaching them in one afternoon how to use WordPress for adding and maintaining content was not an easy task. Continue reading Teaching WordPress to 23 visually impaired content managers