The Headings Hierarchy Challenge

November 3, 2014

Topics: Accessibility.

Tweet this post

Working on WordPress core, themes, and in plug-ins, I find myself in frequent discussions about appropriate hierarchical structures for headings.

Headings hierarchies have to do with content relationships and structure, so unless you know everything about the structure of a specific page, it’s pretty hard to know what to choose. It’s not really possible for any independent piece of the front-end to set a perfect hierarchy — whether that’s coming from a plug-in, a theme, or from WordPress core.

Headings are important. They are the first step most screen reader users take when they begin to navigate your web page. 65.5% of users will start by navigating headings.. Solving this problem is worth tackling.

What are the problems?

In a content management system, where the rendered web page is constituted of parts coming from core functions, themes, and plug-ins, establishing a logical hierarchy is tough. These independent pieces of the puzzle don’t know what other pieces are doing. If core defines a heading for accessibility reasons as an H1, it provides a key structural piece for the site. But if the theme sets up the headings hierarchy using a single H1 model, where the site title is an H1 and all other parts descend from that, then this H1 is the wrong element.

If a plug-in describes an internally consistent hierarchy that starts from an H2, and is intended for use in a post, but the theme uses an H2 for post titles, that’s not going to be the right headings hierarchy either.

Ultimately, headings hierarchies are up to site implementation more than they are up to any independent piece of that site. But even in that context, pinning down a logical heading hierarchy isn’t easy.

The Basics of Headings Hierarchy

Test your Hierarchy

For testing, I use the HeadingsMap AddOn for Firefox. It’ll show the headings interpreted either in a standard fashion or in the experimental HTML5 document ouline model.

Headings work the same way that an outline does. When following the tree, you can always stay at the same level, go down the tree one level, or go up the tree any number of levels. What you can’t do is go down the tree an arbitrary number of levels. So an h2 could reasonably be followed by any of an h1, h2 or h3, but not by an h4.

How do you organize heading hierarchies in a site?

Let’s start by describing some of the different philosophies about heading hierarchies.

The single H1

For a long time, it was considered cardinal that a page should only have one H1. This wasn’t part of the HTML specification, but was considered to be significant for SEO and structural reasons. Under this model, a page should have only one H1, and all structures from that point forward should be H2 or lower. This is still a very common model.

Under this model, we have to ask which content should be wrapped in an H1. Most commonly, it’s the site title or logo, as the highest level block that all other parts of the page pertained to. This is simple, but it also means that the first heading on the page is redundant information, since the site title is usually contained in the title element.

Multiple H1 elements

Once we decide that a hierarchy can include multiple H1 elements, life gets a bit simpler – but we still need to decide which regions of the page should have headings.

If we assume that all headings must be visible, this is a big design problem. Add a heading to the sidebar? People don’t generally want to see a heading that just says “Sidebar”, or something to that effect. But if we allow headings to be visually hidden, then we can add a whole suite of structural headings labeling the major structures — header, content area, sidebars, footer — without interfering with our visuals.

Not everybody will agree with this methodology — because it doesn’t work well with the idea that headings should be ordered by something called “importance”. Personally, I hate referring to headings by something that I consider as unquantifiable as importance; but some might argue that the most important parts of any page are always the content — so using headings to mark up structure is a problem.

I think marking structure using headings is great, as long as you’re thorough and consistent.

Multiple H1 elements and HTML5 sections

Under HTML5, each semantic section (section, article, etc.) can have an independent heading structure. With this logic, every section can start with an H1, regardless of the parent section’s structure, and the HTML5 document outline algorithm will decide for the user agent what “virtual level” that heading should be used as.

It’s a brilliant idea — it resolves the need for authors who only create *part* of a document from having to know the headings hierarchy surrounding their work.

But it doesn’t work.

It just doesn’t exist in any practical way. Real world usage shows that no user agent has actually implemented this algorithm. And it won’t be a viable system until not just some users get it – but until all users get it, because headings structure has a deep and fundamental effect on the experience that users of assistive technology have with your site. (Not to mention complicated design issues in the CSS to tackle chains of nested headings.)

So, good idea, but it doesn’t work — and probably won’t for a long time, if ever.

ARIA landmark roles and HTML5 landmarks

There is, of course, a method of shaping the structure of a web page without any use of headings at all — using landmark roles from the ARIA (Accessible Rich Internet Application) specifications or using the HTML5 content wrappers that map to them. And these are absolutely things that you should use in every site or theme you build, because they have great potential for future use — and unlike the HTML5 document outline, without immediate negative repercussions.

But as a replacement for a good headings hierarchy, they aren’t a candidate. Document landmark regions are best used with labels, either with aria-labelledby or aria-label:

Using aria-labelledby

<nav role="navigation" aria-labelledby="primary">
    <h1 id="primary">Primary Navigation</h1>
    <ul>...</ul>
</nav>

Using aria-label

<nav role="navigation" aria-label="Primary Navigation">
    <ul>...</ul>
</nav>

Either case is valid, and in the first case, the label wouldn’t even need to be a heading. The structure would still be present. This is a great long-term future idea; but at the moment, support is not sufficient to depend on it, and user awareness of the option is still insufficient. Survey data shows that users of assistive technology usually start their search process by navigating headings — 65.6% of respondents to WebAIM’s fifth screen reader survey (2014) stated that this was their first step in navigating a long web page. Landmark roles, while increasing in awareness, was only the first step for a measly 2.8% of respondents.

While purely structural headings can be omitted entirely with ARIA roles, this creates a significant usability problem for a large percentage of users. Not cool.

What do I recommend?

Either the single H1 model or the multiple H1 model are fine — the most important key is to use headings; and after that the next issue is to try and maintain an internal hierarchy that’s consistent. Use ARIA landmark roles, as well, so that your page has an explicit semantic structure, but don’t depend on them.

Always remember that there’s a huge value to hidden heading elements that are primarily in place to provide structure. Having a specific top level heading for your section wrapper can make it much easier to manage the whole hierarchy.

If you want to look at what I’ve actually done, check out Universal, my accessible theme framework. (You can also find it on GitHub.)

Handling Headings in WordPress

For theme developers, you need to come up with a logical hierarchy that you like and stick to it. Whether a single H1 or multiple H1 elements, your theme should have an internal hierarchy that works – even though it’ll break the minute a user throws an H1 into post content.

For plug-in developers, this is a bigger problem. Ideally, you need to make your headings structure filterable, so that a theme or developer can specify where your plug-in’s hierarchy should start. But I haven’t done that with my plug-ins, I have to admit.

For content authors, you need to know the hierarchy of the theme you’re using, so that you know what headings you can and can’t use. (And you get a whole new network of problems if you switch to a theme with a different hierarchy.)

Ideally, themes could declare what heading level is their content’s top heading, and both plug-ins and the WordPress editor could pick up on that declaration to figure out which heading levels to use. Right now, you just have to know.

Have something to contribute?




« Read my Comment Policy

11 Comments to “The Headings Hierarchy Challenge”

  1. Thank you Joe for your response! I will use this knowledge in my future adventure with WordPress 🙂

  2. Absolutely right! We cannot abandon older design methods, but change is an incremental process. This is what makes web design a big challenge. Ignoring future trends and modern techniques is not a growth strategy that any business will acept. Designing web sites for the lowest common denominator is not a good business strategy, and implies screen reader users are a hinderence to growth. Content authors must be aware of changing user needs, and the importance of universal design for inclusiveness in reaching the largest possible market. This is why Heading hierarchy is still so very important, and must be a design consideration for themes and widget plugins. Innovation is about meeting the challenge, and you have captured the importance of balanced design.

  3. Interesting. Apparently, if a heading actually has the role of banner, it isn’t read as a heading. That makes sense, but was an oversight when I wrote that. Oversimplification!

  4. You know, you commented that the heading hierarchy started with H2, and there was no H1 until the complementary sidebar, and my first thought was “well, that’s not true!”. And it’s not – there is an H1 in the header. However, it’s not being read by NVDA, and I’m not sure why; I’ll have to look into that.

  5. Sorry, the examples did not appear in the post, but are here for clarity:
    (nav role=”navigation” aria-label=”Primary Navigation”)
    would cause the screen reader to read this as “Primary Navigation Navigation”.

    (DIV class=sidebar id=nav role=complementary aria-labelledby=sidebar
    H1 id=sidebar class=screen-reader-text level=1>Sidebar /H1
    /DIV)
    would cause the screen reader to read this as “Sidebar complementary region”.

  6. I agree that it’s necessary to consider the future in design; but it’s also crucial to consider the present. And as much as ARIA landmarks are valuable, they are relatively little used and poorly known, as well as having incomplete support. Given that the cost of upgrading tools such as JAWS can be prohibitive, and many corporate or government organizations are still using very old tools such as IE versions before 9, it would be foolhardy to abandon older methods in favor of being future thinking.

    The future is important, but it should not be a tool we use to force users to have an inferior experience because they can’t afford the future.

  7. Joe, very good article and thanks for raising this important accessibility issue. However, there are two important design factors that you neglected.

    First, we should be designing for the future and not for past best practices. About 65% of screen reader users navigate a page by the Heading structure. That was because it was the most convenient method in the past. Currently many screen reader users use older assistive technologies (largely due to cost and usage complexity of newer applications), that do not employ the latest ARIA API features, which means Heading structure is still important. However, moving forward page Landmark structure (particularly in dynamically refreshing pages) will be critical for page navigation. HTML5 Regions and ARIA Landmarks defines the page structure for a screen reader user, and the Heading hierarchy defines the content context within the page structure. For example, on your blog page the Main Content starts with a H2 element, and a H1 does not appear until after the Main Content, for the “complementary” region and the “footer” content, bypassing the “banner” region which has no Headings at all. This is not necessarily wrong, but I would think confusing for someone navigating by Heading hierarchy and cannot see the visual page layout.

    Secondly, the words used in Headings and elemetn text labels is very important for content understandability. That is, your example would cause the screen reader to read this as “Primary Navigation Navigation”. Words that define ARIA Landmarks should not be used as part of a text label. On your blog page this is done correctly (“Primary Menu”), but the word “Menu” adds unnecessary verbosity and misleading information. The Navigation Links are presented as a List and Sublist of Links, not a Menu element. There are available widgets that would allow a keyboard user to navigate this Link List with arrow keys within a contained Menu element. Also, page regions must be labelled for understandability, as some pages may contain multiple regions of the same type (Navigation, Complementary, Article). For example:

    Sidebar

    So, content authors need to know the Theme structure used (both Page regions and Header hierarchy). This may be a challenge when using public Java Script library widget plugins, but nevertheless must be considered. Designing for the future is a big challenge!

  8. Can you describe for me how having multiple H1’s is a problem for screen readers?

  9. Hi Joe,

    Excellent post!

    I have one question: You write that 65% us screen reader users navigate by heading first, why allow multiple H1’s if you know that will make the page harder to navigate?

  10. First, the size of a heading is a design question, and has nothing to do with anything inherent in the H1 or H2; I’ve seen many sites where an H2 was larger than an H1 for design reasons.

    From an SEO perspective, what matters is *that* you use a heading, and that the content of that heading is appropriate to the context you’re using it in. Without knowing the context of what you’re writing, there’s no way for me to know whether you should be using an H1, H2, or even an H3.

    When we’re talking about post content in WordPress, it would be an extremely rare exception that writing an H1 would be appropriate.

  11. When I am normally using H2 because the H1 looks to big for me it is wrong for SEO optimization or do not make any difference?