Data about books is much more complex than any of the OOP exercises I’ve done in my life have indicated and they did little to prepare me for how convoluted real-world books and their attributes can be — and the presentation and markup of the actual title of each book.

The re-introduced <hgroup> HTML element was intended for this purpose. Simply get your “heading block” in there and you should trust the browser to interpret what’s in there and it somehow becomes semantic and accessible by magic. Add a paragraph tag containing a subheading that represents the next heading level below — and voila, you have something that models a heading and a subheading.

Here’s the kicker — assumptions and structures that most people would assume to be correct without exception, such as “each book has a single publisher” or “the person writing the original text in the book is the main author” start melting down as soon as you dive into the taxonomy of books and you start to realise why librarians and archivists spend years in university learning about information systems specific to books and other written works and why library systems are so weirdly esoteric.

But that is a subject for another post.

Wrangling Titles

Creative works such as books and films need to be called something, so they have titles — and even a simple thing like the title of a book can be difficult to wrap one’s head around and it does not look like the intricacies of them are fully accounted for in web standards.

Creative works sometimes have sub-titles and that is accounted for anywhere you read about the <hgroup> element, so a book or film may be marked up in HTML like this:

<article>
  <hgroup>
    <h1>Dr. Strangelove or:</h1>
    <p>How I Learned to Stop Worrying and Love the Bomb</p>
  </hgroup>
  <p>...</p>
</article>

I only recently found out that subheadings are now supposed to be paragraph tags. (You blink an eye and the world changes, ha!) The convention before it was removed and then added again used to be that you use a h2-h6 element that is one level below the main title, which isn’t great in my mind when you have a certain consistency, but the new way of using the <hgroup> tag still feels icky to me.

Now, what’s the issue? Are we literally going to argue semantics?

Yes — yes we are, because semantics are important when we are writing or generating semantic HTML based on complex relational data. In my use case, I’m not just running a website, but a web based data entry system that hooks into Adobe InDesign so I need those to be separate attributes and elements.

On Kickers and Overlines

The issue here is that books sometimes have “super-headings” — also known as eyebrows, kickers or overlines amongst working in the design print industries. Those can be an introduction, the name of the series a written work belongs to and its sequence number in a series of books or articles.

The issue is that in the reading order, the super-heading comes first and then the heading itself, which according to a lot of the code example on the <hgroup> element that I’ve seen online is done like this:

<article>
  <hgroup>
    <p>The Lord of the Rings</p>
    <h1>The Two Towers</h1>
  </hgroup>
  <p>...</p>
</article>

This really rubs me the wrong way because there’s a paragraph element before the heading and that breaks everything we know about heading levels and reading flow, let alone the separation concerns.

While the <hgroup> element is supposed to solve issues with hierarchical titles, I know it for a fact that assistive technologies or any other parser are almost always years or even decades behind the times, so I have made a habit out of using the “new” HTML 5 elements in a backwards-compatible way that doesn’t put its trust in them being interpreted in any other way than the non-semantic <div> or a <span> element — and using <hgroup> this way is exactly not that.

I think the best way to put it into words is that I trust the browser (and other parsers) to do its thing in ways that are backwards compatible. Just to name two examples, adding a PWA manifest or speculation rules to your markup doesn’t break how older browsers or stale versions of assistive devices interpret your markup if they don’t provide support for it.

Putting Things Right

Now, how do you maintain a consistent heading level throughout the document or app while also supporting overlines above the main heading?

The markup is messy, but this is similar to how I’ve been doing semantically correct headings with an overline and a subheading, using Bootstrap utility classes for clarification for this example:

<article id=”book-74205” aria-labelledby=”book-heading-74205”>
  <hgroup id=”book-heading-74205”>
    <h1>
      <small class=”h2 d-block”>The Adventures of Tintin</small>
      Tintin and the Blue Oranges
    </h1>
    <p class=”h2”>Special 60th Anniversary Edition</p>
  </hgroup>
  <p>...</p>
</article>

Here we have a book that uses a main title along with a subheading and an overline. The <hgroup> element is then assigned as the content title using ARIA tags and in this example, I am using Bootstrap’s utility classes to make sure we display the overline <small> element as a block and we’re using the correct font size.

The real magic here is with where the overline is located semantically — inside the <h1> element, because it’s both a prefix and a sub-attribute of the heading.

But can’t we just do the same thing with the subheading for consistency?

Is <hgroup> Actually an Antipattern?

This does make me wonder if the hgroup element is actually solving any issue that can’t be solved using a single heading element with <span> or perhaps the now-rarely used <small> element in addition to a couple of new ARIA roles:

<article id=”book-74656”>
  <h1>
    <small class=”h2 d-block”>Star Trek: Voyager</small>
    Distant Shores
    <small class=”h2 d-block”>A Tenth-Anniversary Celebration</small>
  </h1>
</article>

I know <small> isn’t cool anymore because it doesn’t fully separate presentation and data, but if it is supposed to fit in anywhere, it would be to represent subheadings and overlines. It is also technically allowed inside of heading elements like <span> as it is a “phrasing content” element.

I also feel like this makes much better sense if we’re using conditionals to display overlines and subheadings in a view component of a website.

To me, the goals of HTML 5 and semantically correct markup is and was always to enable rich content, accessible documents and web apps without relying on workarounds and tricks. Unfortunately, the <hgroup> element does not serve that purpose as well as it should and it’s hard to see that relying on this wrapper element in its current form is any better than cramming all the associated elements into a single heading tag.

I for one do not think that <hgroup> has or has ever had a discernible semantic use in its current or past form and if there is one, then perhaps it belongs to a <div> with a specific ARIA role if the intention was to ever make it backwards-compatible (which is important to those who actually care about accessibility).

Furthermore there is no official guideline or standard that covers how to include a text element above the heading without breaking the heading level, so it feels strange that the continued inclusion of the <hgroup> element does not account for this.