In some ways, this is expected.

"All Classes" does not express a hierarchical relationship. It is like "Top" or "Index", the same as the other categories to quickly locate a place on the page.

Yes it make sense, but:

• Don't we usually refer to Nodes, Resources, etc., as All the classes? They are at the same level, but the term All the classes seems to encompass other classes as well.
• The “Multiple H1 tags” is an issue which refers to the presence of more than one primary header within a single webpage. The H1 tag is used in HTML to define the main heading of a page, and it is considered one of the most important elements for search engine optimization (SEO). Each page should have only one H1 tag.

It's a link to jump to the top of the page, showing all the classes.

Ideally, each section should be a dedicated page, and All Classes should be listing classes alphabetically. That's also why sections All classes, Nodes, Resources, etc are wrapped in their own separate <section>.

<h1> is a heading, not the page's title which is unique. Different sections can have their own <h1> tags.

MDN help has this to say on the topic:

Using more than one

is allowed by the HTML specification, but is not considered a best practice. Using only one

is beneficial for screenreader users.

Also WebAIM:

The

describes the page as a whole (and should be similar to the page <title>). A page should typically have only one

.

Having spent last 2 months on making our company's site accessible, I recommend having one h1 only. Screen readers and other accessibility software like Dragon Dictate can get confused with multiple h1s

How about:

<h1>A list of all classes</h1>
<!-- ... -->

<h2>All classes</h2>

<h2>Nodes</h2>
<!-- ... -->

<h2>Resources</h2>
<!-- ... -->

<!-- ... -->

Which makes them stay at the same level while fixing multiple h1 issue (bug).

To solve the current awkward situation due to the multifunctional all-in-one index page completely, I suggest generating individual pages for the all-classes index and for each category.

The core problem with the current approach is that it moves all these groups under "All classes" which is not desired:

Before	After

Moving all these heading under a new one has the same problem.

• A single item "All classes" is redundant.
• These categories are different ways to filter the class list. There are intersections between these categories, so they are not logically children of "All classes".

An additional complexity here is that this current implementation results in some documents being listed in multiple of these categories (e.g. Node or Resource, or some of the Editor nodes), and as every category here is a toctree, those documents get listed as part of multiple toctrees, which Sphinx complains about.

So we will likely need to move away from a "All classes" category anyway and need to make sure everything is listed at most once, in a single category. Otherwise, we get tons of warnings like these from more modern Sphinx versions:

class_scripteditor.rst: document is referenced in multiple toctrees: ['classes/index', 'classes/index'], selecting: classes/index <- classes/class_scripteditor