History and Demonstrated Need

A list head or title is the element that provides a title or caption to a list. This is not the same as titling sections of nested lists.

The Web and Publishing industries need a standardized method to state the title or caption of a list. The Digital Publishing Interest Group highlighted this need from an accessibility perspective in a note published in May 2016, explaining that there are many methods of creating a visual differentiated list title, but those methods convey no semantic meaning.

JATS, Journal Article Tag Suite, is the standard markup for the National Institutes of Health and therefore a widely-used XML tag suite for scholarly article archiving interchange. The content model for list and def-list both allow for the inclusion of the title element, which takes on different meaning, depending on context. In JATS, the distinction between ordered list and unordered list is conveyed by the list-type attribute.

What has been tried?

A common recommendation is to simply use HTML h1 - h6 elements. This has implications for sectioning, usability, and accessibility. Additionally, the heading element is not a part of the actual list. This also has implications for the number of headings available for other content. In this example, the list title is tagged as h4. What are the implications for the content that should be have level-4 headings? How does one using AT interact with list titles tagged as headings as opposed to those heading elements that are intended as headings?

        
Influences
        ...
        
Books that Influenced my Writing
        ...
        
Dr. Seuss
        ...
        
Important Seussian Characters
        

• Thing One</li>
• The Cat in the Hat
• The Lorax
• Sally

Other solutions have included nesting lists in the <figure> element to take advantage of <figcaption>. Science.ai, an organization that works with scholarly publishing has chosen this path, as it is congruous with JATS. This is illustrated at https://gist.github.com/darobin/6b1342e080925d5ed7ced89921a9f4de by Robin Berjon.

Past discussions in earlier versions of HTML and with the WHAT WG have revolved around titling sections of nested lists. This is a much simpler problem to solve.

Proposal

This proposal is to create an element that can be the child of <ul>, <ol>, or <dl> called listhead, listtitle, or listcaption. It could be modeled largely on the figcaption element, as its function for the different types of lists is parallel to the function that a caption serves for a figure.

The above example would be rewritten as:

        
Influences
        ...
        
Books that Influenced my Writing
        ...
        
Dr. Seuss
        ...
    <ul>
    <lh>Important Seussian Characters</lh>
    <li>Thing One</li>
    <li>The Cat in the Hat</li>
    <li>The Lorax</li>
    <li>Sally</li>
    </ul>
    </pre>

Both Docbook and TEI have list titles as well. This has always been an issue when transforming from those vocabularies to HTML.

The idea of having a list heading is nice, but instead of inventing a separate heading element for each element like a list, it would probably make sense to finally introduce a generic levelless heading element like <h></h> that would act as a heading for its first structural (semantic) ancestor element — be it a list or anything else.

For example:

<ul>
    <h>List heading</h>

    <li>Lorem</li>
    <li>Ipsum</li>
</ul>

<section>
    <h>Section heading</h>
    <p>Section contents.</p>
</section>

<section>
    <div>
        <!--
          DIV is semantically transparent, so the heading is for
          the SECTION, not for the DIV the heading is the direct child of.
        -->
        <h>Section (not DIV) heading</h>
        <p>Section contents.</p>
    </div>
</section>

In this case it would not be a heading or acting as a heading , so suggest lt (list title) or lc (list caption) would be preferred element names, rather than lh, which would imply that it is somehow a sectioning element (like h1-h6)

While i agree that having <h> would be nice, it would involve a lot more work and need buy in from implementers. I don’t agree that usage of heading semantics for a list caption/title is a good idea as it complicates further the already complex semantics of headings (and sectioning). Having potentially an extra heading (and implied section) for each list (I suggest) would not be useful for users who consume the semantics.

I have sketched out an element definition to help the discussion along: the lt element

Really useful result often needs serious work, that’s perfectly fine. But thanks to HTML5 parsing algorithm, introducing a new element does not currently involve huge efforts, any new element immediately works as is in any HTML5-conformant implementation (i. e. any modern web browser). And searching the first semantic ancestor of a levelless heading element is as easy as calling h.parentNode.closest(':not(DIV)').

If you can get implementer interest then go for it. But it is orthogonal to the addition of a list title as the semantics of such an element is not that of a heading.

AFAICT, introducing a new element does not need implementor’s efforts. It’s just a matter of formal validity on spec level. AT could then probably call h.parentNode.closest(':not(DIV)') on their own.

You should probably be more specific on what difference you mean given that the new heading element is intended to be displayed as a regular element (e. g. unlike the title attribute). The topic starter has proposed a heading for lists, I’ve just extended the idea.

from the proposal:

It could be modeled largely on the figcaption element

Which is what I have done. differences with headings: It is not a sectioning element , and is not a heading:

From the element definition proposal

The lt element represents a title or caption for the rest of the contents of the lt element’s parent ul, ol or dl element

I think you are incorrect in this case as the implementation of an element that acts as a generic heading would require the implementation of the outline algorithm, which has been floated in the past but no implementations in browsers have occured; Some links to related bugs. AT don’t generally use the DOM, in many cases they interact solely with the accessibility tree, in some browsers they don’t have access to the DOM at all.

I think @SteveF is right - as @MT recognised - that this proposal needs thinking.

It is clear that people would like to have the outline algorithm, and be able to use a generic header that is automatically sectioned, which is why we tried to introduce it in HTML5. But failed.

It makes sense to me that there is a list heading available, as opposed to a title. That means complicating the section thing a bit, since it implies that its parent list becomes a section, whereas a list without one - even if it had a title element - wouldn’t.

So you could do

<ul>
   <lt>A list title</lt>
   …
</ul>
<ul>
  <h>A heading that participates in outline</h>
  …
</ul>

Which moves the sectioning issue to the generic problem of outline and copy-paste-friendly headings.

I don’t think that is a lot of work, but it certainly requires buy-in from implementation to do that work if we’re going to put it into HTML.

An alternative we have already is

<h1>Influences</h1>
    ...
  <h2>Books that Influenced my Writing</h2>
    ...
    <h3>Dr. Seuss</h3>
    ...
    <section>
        <h4>Important Seussian Characters</h4>
          <ul>
           <li>Thing One</li>
           <li>The Cat in the Hat</li>
           <li>The Lorax</li>
           <li>Sally</li>
         </ul>
    </section>

Although that may hit the 6 level limit which is one motivation for a generic header.

@steveF Thanks for the <lt> sketch. This is exactly the kind of thing I had in mind. I have concerns about proposals involving <h>. We’ve seen that the outline algorithm is a great concept but hasn’t been implemented. Using <hx> is not ideal. The author will run out of headings as @chaals pointed out. I think it is also misleading from a structural perspective. The heading is not really part of the list, and it implies that the list title is of greater structural importance than it should be (IMO).

In my opinion, this approach only solves part of the problem unless browsers decide to treat this new element the same way they treat <caption>. This is because <caption> elements can be styled as if they were not nested inside the table they belong to.

I think it is very important that authors can style the container and its first child as if they were siblings. Because if they can’t do that then I’m afraid many will end up using other means (i.e. a heading) to easily achieve common layouts, like the one below for example:

    Title with no border, no background, no offset
    ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
    ┃                                                       ┃
    ┃   list with a border, a background, and some padding  ┃
    ┃                                                       ┃
    ┃                                                       ┃
    ┃                                                       ┃
    ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

In other words, I’m afraid that this “title” (first-child of a list) may be in the way more often than not and that authors will end up hiding it from view (like many used to do with <caption>). Worse, some may create redundancy by also using a heading to cater for their design needs.

For what it is worth, I prefer the <figure> “hack”:

• it works out-of-the-box
• it does not interfere with data scrapers
• it creates a structural hierarchy

Also, reading 4.9.2. (The caption element)

When a <table> element is the only content in a <figure> element other than the <figcaption>, the <caption> element should be omitted in favor of the <figcaption>.

If it works for tables, why not for lists too?

In my opinion, “extending” the definition of <figure> may be the best way to go here.

Yes, I will have to agree. I think the much more general <figure> and <figcaption> should be used instead of a more specifc‐purposed <lt>.

Could you provide several use cases? I personally don’t remember any use case in which I need a “list heading” specifically designed for a list.

When I need to markup a section of navigational hyperlinks, I put the list in <nav> and use <h2>-<h6> as the heading; when I need to markup a list mentioned in an article, I don’t need to give it a heading because the purpose of the list is always already described by the previous element (usually a paragraph).

i believe the use cases are described in the proposal [proposal] list head/caption/title

If the use case is the one that uses <h4>Important Seussian Characters</h4> as the heading at first, then I would say the entire markup should be:

<h1>My biography or something</h1>
<section>
    <h2>Influences</h1>
    ...
</section>
<section>
    <h2>Books that Influenced my Writing</h2>
    ...
</section>
<section>
    <h2>Dr. Seuss</h3>
    ...
</section>
<section>
    <h2>Important Seussian Characters</h4>
    <ul>
        <li>Thing One</li>
        <li>The Cat in the Hat</li>
        <li>The Lorax</li>
        <li>Sally</li>
    </ul>
</section>

The list belongs to a section. And it is fine to use <h2> as the section heading.

I disagree:

• The markup you suggest does not respect the original structure.
• more to the point, if I understand correctly one requirement is explicitly that the list head should not contribute to the outline (in the general sense and not only the HTML meaning of “outline”) for sectioning and accessibility reasons, which voids any solution based on h1-h6.

@TzviyaSiegman you mentioned an alternative solution based on figure and figcaption (as implemented by @Robin). Can you please elaborate on the drawbacks on this solution (compared to the lt proposal)?