Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
kellytk opened this issue Dec 4, 2021 · 8 comments
Open

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

kellytk opened this issue Dec 4, 2021 · 8 comments
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest

Comments

@kellytk
Copy link

kellytk commented Dec 4, 2021

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
Copy link

brennanyoung commented Jan 14, 2022 •
edited
Loading

Possible duplicate of #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
Copy link
Contributor

Malvoz commented Jan 19, 2022

Other related discussions/proposals:

@j9t
Copy link
Contributor

j9t commented Jan 19, 2022

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

@kellytk
Copy link
Author

kellytk commented Jan 21, 2022

Thank you for the prior, related links.

Although I would typically close the issue, to reiterate w3c/html#774 (comment) 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
Copy link

mihaon commented May 6, 2022

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
Copy link
Member

lukewarlow commented Jun 26, 2023 •
edited
Loading

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)

  • <h level="1">
  • <h> that the browser determines to be level 1
  • <h1> elements.

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
Copy link
Contributor

We should just make <h1> work this way.

@jakearchibald
Copy link
Contributor

Related: #5033 (comment)

@annevk annevk added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest labels Mar 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest
Milestone
No milestone
Development

No branches or pull requests
8 participants
@jakearchibald @mihaon @brennanyoung @annevk @j9t @kellytk @Malvoz @lukewarlow