Designers can help developers build more accessible websites by separating visual heading styles from content hierarchy with a naming convention that communicates intent.
Hi designers, I’m not one of you, but I am someone who often works with your creations. Over the years, I’ve noticed a few common mistakes that can cause problems once your work reaches the development stage. This isn’t about pointing fingers (I have an article for developers, too.) It’s about helping you design more effectively, especially when it comes to something as deceptively simple as headings.
Forget About Heading Levels in Your Design (kind of)
When designing for the web, you already know that websites rely on headings at different levels (<h1> through <h6>). But here’s the thing: when you’re creating your typography system, you can throw that knowledge out the window — at least at first.
Why? Because I often see designers name their text styles things like “Heading 1,” “Heading 2,” and so on. While that makes sense visually, it can unintentionally mislead developers into thinking those styles should be tied directly to the corresponding HTML heading levels. Instead of working within the confines of a 1–6 heading system, focus on creating a typography system that works for the content.
To meet WCAG 2.2 accessibility standards, developers can’t skip heading levels in the markup (WCAG 1.3.1). That means if your design includes two headings that look different but are at the same level in the content hierarchy, we can’t just assign them to <h2> and <h3>. Instead, both need to be the same heading level in code, styled differently with classes.
Alternative Naming Conventions for Headings
Instead of labeling styles as “Heading 1,” “Heading 2,” and so on, try naming them based on their role or visual treatment. For example:
Display for large, attention-grabbing text (often what people think of as “Heading 1″)
Section Title for headings that introduce new chunks of content
Subsection Title for smaller, supporting headings
Eyebrow or Overline for smaller text above a headline
These kinds of names communicate intent rather than hierarchy, which helps developers know how to apply them correctly in code without making accessibility mistakes. If needed you can also include different sizes variants such as small, medium, large. etc. Any of these classes should be able to apply to any of the heading elements.
Now, Bring Heading Levels Back
There is one big exception to this rule: rich text editors.
A rich text editor is the tool content creators use inside a Content Management System (CMS) or publishing platform. The tricky part is that these editors often don’t allow developers to add custom classes. If someone selects “Heading 2,” it’s going to render as an <h2> every time. You can still apply existing typography styles to the <h2> but note that developers can’t make one <h2> look different from another.
In this situation, developers do need a set of styles tied to heading levels because the editor enforces it. Think of it as a separate, parallel system from the typography you designed for the rest of the site. The styles can still align visually with your overall system, but here they are locked to specific elements. The content hierarchy controls which levels appear, and accessibility requirements still apply. The difference is that styling options are much more limited.
Wrapping Up
Headings can seem like a small detail in the grand scheme of a website’s design, but they carry a lot of weight for both accessibility and development. By separating style from hierarchy and by clearly communicating the intended structure, you’ll make life easier for your developers and help ensure your designs are interpreted correctly in the final product while also being accessible to everyone.
