This "headings closer to the content" suggestion is very good.

I came across it when reading Butterick's Practical Typography and it's possibly the lowest effort/clearest improvement guideline in the book.

Now I can't unsee websites that do it wrong.

moreover h* is just broken whenever dealing with more dynamic content — it simply can’t reasonably be made to work according to accessibility recommendations — and the accessibility guidelines around never skipping a level themselves are ridiculous given the practical reality that dynamic content exists and we have only h1, h2, etc. to work with — the readers and specs are what need to adapt here, not the entire internet

there should really be one header tag and its level should be based on some nesting depth

and don’t get me started on the maintainability mess that is z-index… better we have a system to centrally maintain an ordering list than a distributed one which only works reasonably consistently if you already know everything in the whole system

I like how z-index works, currently. And though I agree with the article, it should apply to all elements by default, I'm not sure how you'd do stacking differently in a way that'd work any better than the current situation?

You can't do away with stacking contexts, you need those to isolate content you don't control to prevent it from breaking the stacking order of content you do control.

I completely agree with you about h* tags, though. I wish html5 sectioning hadn't been killed by the browser vendors. As is there's no safe way to put headings inside custom elements. We almost had it, it was specified and everything.

Lile XHTML2?

https://www.w3.org/TR/xhtml2/mod-structural.html#edef_struct...

The problem with trying determine heading depth automatically is the depth is not something that can be deduced just by the structure. If headings are siblings, for example, the may be on the same level semantically or not.

One way I've dealt with this in react is combine a Heading component with ContentGroup component. Each content group needs exactly one heading, and heading can't exist without it. Content group can contain other content groups. The tag for heading can then be determined by how many content groups are in the tree above it.

This works pretty well ime, but it can be hard to get devs to use (or think about accessibility at all).

That's how html should have been designed from the start. HTML is originally designed as a very flat hierarchy, e.g. h1 p p p h2 p p h2 p p h3 p h2 p just following each other. When really it would make much more sense to have h{p p p h{p p} h{p p h{p}} h{p}}.

That's what sectioning elements [1] like <section> and <article> where once introduced.Opposite to just using <div> elements their purpose was to create a real document outline, where it would have been possible to only use <h1> and their level would be determined by how deep the section is nested, but this approach was never really adapted.

[1] https://www.w3schools.com/html/html5_semantic_elements.asp

That's sensible, but I think default styles for specific elements are not part of the CSS standard, and are instead dictated by the user-agent stylesheet of your browser.

> h1, h2, h3 should not have different styles. it's an anti-pattern that leads to broken accessibility

How does that hurt accessibility? Are you saying people use h3 in order to get its style even when they didn't mean h3?

I think the opposite could happen too - if they all have the same style then people might just use h1 everywhere which is probably just as bad. People tend not to use elements that have no obvious use, like <output> which apparently has better accessibility but does absolutely nothing else, so nobody bothers. The whole "semantic web" thing failed partly because of this.

> Are you saying people use h3 in order to get its style

yes, and that people assume the purpose of having different tags is to control styling

I mean, they aren't wrong. That is part of the purpose. Of course now we try and do it via CSS but it's definitely still fine to use <b> as bold and <i> as italic, even if the semantic pedants will insist that they mean "Bring attention to" and "Idiomatic" (that name's stretched so thin you can see through it!).