Subheadings, subtitles, alternative titles and taglines in HTML

Book cover with the text used in the examples and a picture of a bloke wearing a sailors outfit holding a ventrioquist dummy in his arms.

Until recently there was no dedicated method in HTML to identify content as a subheading, subtitle, alternative title or tagline. Now there is.

Previously, a common method for subheadings was to use a heading of lower rank, for example:

<h1>All At Sea Over Ventriloquism<h1>

<h2>Captain Dick's Logbook</h2>

<h3>By Richard P. Wightman alias Captain Dick</h3>

The problem with using headings of a lower rank in this context is that headings signify the start of a new section or subsection of a document.

In the example code provided, the document outline ends up like this:

diagram representation of the document outline shows 3 nested headings.

Having 2 nested sections is not an accurate representation of the document outline.

Now we can accurately reflect the document outline and the semantics of subtitles like this:

<hgroup>
<h1>All At Sea Over Ventriloquism<h1> 
<p>Captain Dick's Logbook</p> 
<p>By Richard P. Wightman alias Captain Dick</p>
</hgroup>

In the example code we have 1 heading and 2 paragraphs containing information related to the heading of the section.

diagram represntation of the document outline shows a single heading.

When nested within a <hgroup> element, the <p> element’s content represents a subheading, alternative title, or tagline which are not included in the document outline.

How is this exposed in the accessibility tree?

Currently <hgroup> has a generic role and is either ignored or not mapped in the accessibility tree. The output of the code example is the heading and paragraph(s).

output of the accessibility tree inspector in Firefox, showing the heading and paragraphs ungrouped.

It is proposed that the mapping for <hgroup> be changed to role=group. In this case the accessibility tree will be like this:

Output of the accessibility tree inspector in Firefox, showing the heading and paragraphs grouped.

In theory, this would provide the means for screen readers to convey the more specific semantics of the <p> element(s) in the <hgroup> but the software would need to walk through the descendants of each object with a group role and ascertain whether the code followed the content model for <hgroup>:

Zero or more p elements, followed by one h1, h2, h3, h4, h5, or h6 element, followed by zero or more p elements, optionally intermixed with script-supporting elements.

As much existing hgroup code will not follow this new content model. Scott O’hara has suggested that for legacy markup only the heading with highest rank be exposed as a heading:

as there are lots of instances of hgroup in the wild where multiple headings are used – […] these will [have] become invalid markup patterns, and indicating that the headings of lower level be treated as p elements will at least mitigate for that.

Considering the issues, I have floated the idea of a more specific group role for <hgroup> which would make it easier to identify instances of the element in the accessibility tree.

Semantic experimentation with ARIA

Existing ARIA attributes can be used to experiment with how the semantic information could be conveyed to users, for example:

could convey the following semantic information:

heading group, start
subtitle, Magazine of the Decade
Heading level 1, The Month
subtitle, The Best of UK and Foreign Media
heading group, end

The following code emulates the above:

<hgroup role="group" aria-roledescription="Heading group">
<p aria-roledescription="subtitle">Magazine of the Decade</p>
<h1>THE MONTH</h1>
<p aria-roledescription="subtitle">The Best of UK and Foreign Media</p>
</hgroup>

Considerations for developers

Do not use h1-h6 to mark up Subheadings, subtitles, alternative titles and taglines in <hgroup>, use <p> elements.

Whether the semantics of the <hgroup> and the specifics of child <p> elements are to be conveyed to users is a decision for the assistive technology developers in consultation with their users. What browsers can and should do is ensure that unambiguous semantics are exposed in the accessibility tree.

Apply additional semantic information via ARIA with an abundance of caution as it may well end up being unwanted noise for users. Unless there is a specific need to convey additional information, for example, the subject matter is about Subheadings, subtitles, alternative titles and taglines in HTML or for someone proofreading the text, developers should allow the implicit, built-in semantics of HTML to do its job.

Try it for yourself:

See the Pen hgroup example by steve faulkner (@stevef) on CodePen.

Like to be notified about more articles like this? Subscribe to the Knowledge Center Newsletter. It not only gives you summaries and links to our technical blog posts but also TPGi webinars, podcasts, and business blog posts – as well as accessibility and web tech conferences and other events, and a reading list of other relevant articles. You get one email a month, it’s free, requires just your email address, and we promise we won’t share that with anyone. Check the archive.
Categories: Technical
Tags:

About Steve Faulkner

Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.

Comments

Seirdy says:

Technically, we already did have a way to mark up subtitles.DPUB-ARIA defines the “doc-subtitle” role:

I imagine this change to the HTML Living Standard could obsolete the “doc-subtitle” role.