search

whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
7.9k stars 2.58k forks source link

Element request: `<h>` to reconcile heading levels, outlines, and components #7390

Open kellytk opened 2 years ago

kellytk commented 2 years ago

The problem with using specific heading levels ("<h4>") is it couples components to their containing context.

On the other hand, using <h1> everywhere and relying upon the outline algorithm makes an incorrect and contradictory assertion; every heading is of '1' level.

<h>'s level would be dynamic to the outline as composed.

brennanyoung commented 2 years ago

Possible duplicate of https://github.com/whatwg/html/issues/5033

Current spec has proved a damn nuisance when making components WCAG compliant.

Please note that there are no UAs that fully support the HTML5 Document Outliner Algorithm - it is not communicated to the accessibility tree either. I think the effort has lost steam, but not necessarily for the best reasons.

WCAG does not require heading levels to follow absolutely consecutively, but if the level suddenly jumps "backwards" (e.g. a H2 inside something that has a H3 at the top) it is flagged as a WCAG compliance failure by most reputable auditors.

This puts a burden on components to inspect the context, to discover the current heading level to start from, which is a fragile sort of practice. Components are supposed to be self-contained.

I really don't think a level-less <h> element will solve these problems. Accessibility still requires heading levels, so that the inherent document structure is communicated non-visually.

It would be better if we could express headings relative to that of the nearest ancestor heading, e.g. <h level="+1"> (deeper) or <h level="-1"> (back up).

So the following snippets would be semantically identical:

<section>
  <h1>Foo</h1>
  <div>
    <h2>Bar</h2>
    <div>
      <h3>Beer</h3>
    </div>
  </div>
<section>

<section>
  <h1>Foo</h1>
  <div>
    <h level="+1">Bar</h>
    <div>
      <h level="+1">Beer</h>
    </div>
  </div>
<section>

Side note: Aria distinguishes the heading semantic from the heading level semantic, but has no relative level mechanism, although it is under discussion.

Malvoz commented 2 years ago

Other related discussions/proposals:

j9t commented 2 years ago

No vote or preference, just—markup history: h in XHTML 2.0.

kellytk commented 2 years ago

Thank you for the prior, related links.

Although I would typically close the issue, to reiterate https://github.com/w3c/html/issues/774#issuecomment-277657080 I'll leave it open and another can close it when they wish.

This is a really common request for HTML. The use cases seem clear, there have been several attempts to make it happen, and it would seem helpful.

mihaon commented 2 years ago

I'm very annoyed that <h> tag hasn't been added to the spec yet. As a web developer, I have been suffering from the lack of this tag for many years, in the absence of which I have to use <h1>-<h6> tags, which creates a lot of problems when splitting an internal application structure into modules. Like many other web developers, I look forward to when this tag will appear in the specification. Please consider adding <h> tag to the specification.

lukewarlow commented 1 year ago

I know +1 comments are generally not good so I will try to make this something more than that. Having just a <h> and the browser work out the semantic level based on the rest of the DOM would be a brilliant addition to the web.

Rough HTML

<body>
    <header><h>This would be a h1</h></header>
    <section>
        <h>This would be a h2</h>
        <section>
            <h>This would be a h3</h>
        </section>
    </section>
</body>

Having a level attribute to override the automatic behaviour for when thats needed would make sense.

Then CSS styling can be something like "h[level=1]" ideally this would match all of (but certainly the first two)

This would be particularly helpful given how many web pages are authored in a way that uses reusable components that don't necessarily know their context. In the same way container queries allow the author to worry less about the context of the markups usage. A element would also allow us to do the right thing for any usage of the component.

jakearchibald commented 4 months ago

We should just make <h1> work this way.

jakearchibald commented 4 months ago

Related: https://github.com/whatwg/html/issues/5033#issuecomment-1733292070