I had done some manual accessibility audits where it was obvious that content providers used heading level based on their visual design and not on their semantic level. So it got me thinking what would it take to fix this unwanted behaviour that can cause quite serious problems for blind screen-reader users. And not only how to fix but how to prevent this. In this post I will try to reflect on an idea I think could help.
Semantic level of headings is more important than their style
Saying that semantic level is more important than their visual style may seem a bit odd at first. Especially when we don’t understand why semantic levels exist. I did some research and in general the visual style and semantic level should be in sync. So – larger heading levels have larger fonts. It’s simple to choose the correct heading in such cases. Until it’s not.
Before we dive in, let’s just define a common understanding – WCAG doesn’t say anything about the visual style of the heading. It does define the success criterion that text styled as a heading must also be semantically a heading in code. So we can actually have semantic level and visual levels separated. It’s best to keep them in sync, but to cover for border cases we should support such scenario.
Web Content Accessibility Guidelines (WCAG) do not mention visual style of the heading as it’s less relevant than semantic level.
my reflection on WCAG and visual style of headings.
Component level and headings, page level and headings
There are cases where it would make more sense to have a larger font for lower level and the other way around. It happens mostly because of the design choices where we must support nesting of components and their different order.
Sometimes a component need to follow hero component and sometimes same component need to be a sub-component.
And there lies a part of our problem. When we get a component design that don’t have heading levels annotated and if developers are not cautious about the importance of heading levels we risk that they will be wrong. To solve this designers and developers need to cooperate before it’s implemented and simplest way to do it here is that designers understand the impact of the semantics.
When content providers need to use same component on different heading levels they should be able to choose correct level but if they can’t choose correct visual style they often get it wrong. Because it may not be correct visually. Therefore they need to have ability to change the semantic and the visual level independently.
And here lies another part of the problem – content providers need the ability to set the semantic and visual level independently but with such power comes also large responsibility. So firstly they need to understand why this is important and how to use it properly.
Semantic and visual levels should be separated, so that it’s possible to support correct heading level in semantics and visually. But with such a powerful tool content creators need proper training.
my reflection on the solution that can be sustainable, if people got proper training.
Conclusion – cooperation and knowledge are crucial, once again
To conclude – designers, developers and content providers need coordination, components need to support separation of semantic levels and visual levels. “Rich text” components where content creators have the possibility to write their own HTML from scratch also need to have a possibility to set semantic heading levels (correct HTML tags from h1 to h6) and visual levels (for example class .h1 to .h6).
When done with components and eventual “rich text” last check should be made to be sure all headings on page follow correct order, and that can be done with browser extensions like Accessibility Insights (opens in new window).
