Designers should not talk about heading elements

I apologize for the somewhat click-baity title. Of course designers should talk about headings, and so should developers, but there is a difference between the visual hierarchy of headings, and the technical structuring of heading elements in a HTML document. A difference that can cause a lot of trouble, and even hamper the accessibility of your web site.

Writing accessible HTML headings

One fairly basic aspect of writing accessible HTML is to have a correct heading rank. In short this means that the first heading on a page should be a <h1> tag. This should be followed by an <h2> and so on. When a section of content is over and another begins you can go back to a higher rank of heading, but you should never skip a level going down. A <h2> should never be followed by a <h5> for instance.

This example from MDN illustrates a correct order:

<h1>Beetles</h1>
<h2>External morphology</h2>
<h3>Head</h3>
<h4>Mouthparts</h4>
<h3>Thorax</h3>
<h4>Prothorax</h4>
<h4>Pterothorax</h4>

Default heading styling

Since more or less forever, the built in styling that comes with web browsers includes styling for headings. An <h1> is notoriously large, and the subsequent heading levels get smaller and smaller. This makes sense, if you're writing a document in pure HTML. You'll get some automatic styling, and the readability of your text improves with the visual hierarchy of the headings.

Here is an example of the default heading styles in your browser.

However...

Enter the designer

When you're creating your own site or web application you're probably not going to want those default heading styles. You want to design your own of course! So you do this, and they look super good and have a nice visual hierarchy that works with your brand and the rest of the typography in your guidelines. The <h1> is large, but not too large, the <h2> is smaller with a bit of color etc. Time to put them into action on the site itself!

This is where the problem arises. On top of your site you might have a nice big heading - perfect for a <h1> tag, both semantically and visually. But then, in a certain view, the next heading on the site needs to be kinda small. And the heading that you designed that is kinda small is tied to the <h4> tag. If you want to make it look right, you're going to have to use a <h4> right after your <h1> and thus break accessibility guidelines - and that is not good at all.

This is just one example of where this problem can arise. Even worse, if your job is to write guidelines and/or create a design system for others to use, then there really is no telling in which combinations they will use the available headings. Things could break in many ways.

Speaking the same language - and using the right words

It is beneficial for all parties involved in producing software to be "speaking the same language". That is, use the same words for the same concepts, across disciplines and work roles. When it comes to headings on a web page however, I have seen multiple instances of the same language being spoken, but the wrong words used. The HTML tags (<h1>, <h2> etc.) are strictly technical terms and does not matter for anyone who is not writing the actual HTML. If designers start talking about <h1>s and <h2>s, there has been a confounding between the technical and the visual concept. It is not up to a designer wether a heading should be a <h2> or not, it is the developers job to make sure that the heading rank is correct, and then to make sure that is also looks right according to the design.

The solution

The visual design of headings must be decoupled from their HTML elements. On the site or app, a developer must be able to choose the correct heading tag, and then separately choose the correct styling.

If designers are talking about <h1>s and <h2>s, they should "unlearn" these words, and instead, together with the developers", find new words that pertain only to the visuals. Such as "Large heading" and "Medium heading", or whatever fits the situation.

This allows designers and developers to speak a common language, while still leaving it in the developers hands to ensure the correct semantics of the web page.