I’ve always suggested that design and semantics are as consistent as possible. It really made sense to me. Heading level one is the most prominent on the site, followed by heading level 2 that is also visually smaller and so on. It’s easy to think about this from the developer perspective. It is way more difficult when you are a designer.
And that is why I decided to investigate more about this subject and write it down, maybe somebody else will stumble upon it in the future and it will hopefully make things a bit more clear.
Visual levels sometimes need to be more loosen while semantic levels need to be correct
There we have it – following semantic heading levels in code – not letting any out – is quite important for screen-reader users, and quite probably also for search engines. It’s defining the “outline” of the whole “document”, so it must make sense and content is tightly related to the levels used. Heading 1 (h1) is the main title and more important than heading level 2 (h2) and so on. It makes total sense – for documents. It also makes total sense for web applications, webpages and all other digital products but at the same time it can quickly be less aesthetic to keep all the semantic level styling (visual font sizes) follow the same level hierarchy.
Sometimes we need lower levels visually smaller than they actually are. That means immediately that we come into a dispute – an disconnect between visual and code level hierarchy. Sometimes h2 needs to be visually smaller than h3.
An example is a site with a “hero” component – having h1, followed by a collection of “cards”. If we use a heading in our card component we would need to use h2 in the code. When cards are followed by another component that tries to be an article it would probably have heading level 3. When our visual hierarchy is following the semantic levels it will mean that cards have quite prominent titles and little text (if any) and our article heading would get a visually lesser heading weight. That may be a huge problem for the designer and content provider alike.
If we complicate things a bit more – in these component based times – the card could also be used with different levels and our designers would like it to have same font size overall, to keep the design consistent. So in theory we could end in situations that would break the semantic level hierarchy quite fast.
That’s why it’s important for developers to support this visual and semantic mismatch and give content providers and designers full control over it.
It’s important for developers to support visual and semantic mismatch – to give content providers and designers full control over it.
my reflection over semantic vs. visual heading hierarchy.
As always – with such power they also need to take full responsibility. Semantic levels and visual levels should in my opinion have as little as possible inconsistencies. Otherwise we can quickly cause mismatches for different assistive technology users – like for example screen-reader users that can see the screens. It’s still important for understanding and sometimes it should really not be used. It can be tolerated in some cases but it should be used with caution.
There are already a lot of different interpretations and recommendations out there and this one is not helping a lot, but with WCAG and usability in mind we must remember that heading levels are not so “binary” that we may have been learned to think about. So we can conclude, once again, that it really depends. And that developers should make it possible for content providers to have a lot of control and with it – full responsibility.
