Accordions for really long table of contents pages

[DK-TBS]

Hi @thomasgohard! You mentioned in another thread that the TBS should have avoided using details/summary for grouping together parts of their table of contents page. Would you mind expanding on that a bit for me?

We’re working on putting together some patterns for presenting tables of content, and I find the accordion-style interface kind of appealing because it allows people to quickly scan through the TOC headings and pop open the sections that they’d like to peek inside. Then we’d be able to include lists of links inside each “details” element that point off to different subsections of the document.

This would allow us to handle some mighty large tables of content, packing them into a single screen without burdening users with too many clicks. I’m thinking of excessively long documents, like this one here where currently the TOC is itself so large that it has to be split up across multiple TOC pages.

Do you think the toggle/accordion plugin shouldn’t be used at all in cases like this? Any suggestions for other elements/components that might be more suitable?

Hope life is good over there man :)

[thomasgohard]

That TBS page is not a table of contents page, but a content page. What is contained within the group of details/summary elements are the primary contents of the page.

From the HTML spec:

The details element represents a disclosure widget from which the user can obtain additional information or controls.

— 4.11.1 The details element

So the details/summary elements should not be used for primary content.

If your page contains only a table of contents, then that table of contents is the primary content of the page, not additional information. So, again, you should not use the details/summary elements.

I don't see a problem with the pattern used in your example of a long document. We already know that people will follow links.

I think that most cases of long documents will be because we're taking content that was created for a paper-based world which is being dumped as-is to the Web instead of being adapted to the Web. Finding a solution to long tables of contents is solving the wrong problem.

[DK-TBS]

I can agree that the details & summary elements aren’t semantically appropriate for splitting up segments of a TOC, or for splitting up segments of other pages like acts and regulations. So, markup-wise, I'm with you.

But from a UI perspective, ultra-long TOC pages will function better if they a) aren’t 40 screens tall; and b) aren’t split up into 40 different pages of sub-TOCs. People certainly will follow links, but if we can condense the larger multipage TOCs into single pages in an easily scannable way, it will be a more pleasant experience than clicking down through multiple pages, with all those round trips to the server.

Setting aside the markup concerns, wouldn’t it be nice for people to be able to quickly open and close the nested lists (the sub-lists) inside large TOC pages? And if so, might there be some way for us to achieve the same effect without abusing the markup? For example, perhaps an accordion-style widget could be laid on top of more appropriate markup, like the nested ULs. Or perhaps pages like acts and regs could be divided into tabs using SECTION tags, instead of the DETAILS and SUMMARY tags?

As for the excessively long TOC docs themselves, obviously we agree that just dumping them onto the web isn’t ideal, but – that’s not a problem that’s going to be solved any time soon. Realistically, these things are going to be migrated in as-is, and we’re kind of stuck with that…

[terribly]

I note that no one has come up with any suggestions as to how to better render tables of contents. I have complex documents with multiple levels. I too would love to have accordions to roll these up. Details-summary could be used to basically roll up the entire ToC but that seems like throwing the baby out with the bathwater. This is exactly a good use case for accordions and would greatly assist in mobile access to complex documents that we have.

Is there WET4 guidance for this?

[thomasgohard]

@terribly do you have examples of these documents you can share?

[terribly]

@thomasgohard

Uniform Classification of Accounts https://www.otc-cta.gc.ca/eng/publication/uniform-classification-accounts-and-related-railway-records-2014

• adding the H3 levels was impossible for the sidebar navigation. We do not have a model for ToC in the top of body (would need nested accordions and this is not supported in WET4: we had this in pre-WET4 CMS system).

The legal decision here has a very deep Table of Contents that would be nice to present better than what we have here. Ignore the horrifying ems cascade that showed up after our WET4 migration -this is going to be resolved) https://www.otc-cta.gc.ca/eng/ruling/6-at-a-2008

There are other examples I will need to dig for,