Component:
Headings
Accessible headings in email seem to be a bit of a side quest for many email marketers. On its face, it seems very straightforward: Wrap the main points of the email in a heading tag. That makes it a heading – poof! – you’ve made an accessible email! Right? RIGHT?!?!
The answer is… not quite. In a standard email about one concept, headings are pretty easy to implement. Your retail store is having a 30% off sale, so you have a big headline/hero declaring the sale and everything underneath that sale headline supports that heading. Subheadings that show off specific sale items, exclusions, or sale dates are all filed down under that main headline. So easy!
But our emails tend to have lots of different content. Stakeholders LOVE to cram every single nugget of information that might get a user’s attention: 30% off sale! Check out our new product that’s not on sale! Look at our new partnership with this influencer! Hey look at how we give back to the community!
These items are not cohesive and don’t really group into distinct heading hierarchies – what’s an email geek to do?
Why are headings important?
Before we get too far into the details here, it probably makes sense to talk about what headings do. Headings are larger, bolder, shorter bits of text that visually help a user get through the content. Without headings, text would just be one large block separated by paragraphs, which would be super boring and hard to read. Headings also help users get to the content they want. A user can skim through the headings to determine whether or not they want to read the content under the heading. That means there’s a relationship between the heading and the content under it. If your heading declared that you’re having a sale and the content under that heading was not about the sale, you would be confused.
Assistive technology users, like screen reader users, use headings the same way. They can use a keyboard shortcut (usually the “h” key) to navigate through the headings on their email to find the content they want. However, this will *only* show them items that are marked as headings in the code, and that’s why it’s so important that we use the heading tag on our headings. Content that is not in a heading tag will not be read as a heading, so content in paragraph tags, table cells, or divs will be skipped. This is a good thing if you set your code up using proper semantics because the user doesn’t want to read the whole paragraph if they’re using this heading command.
How do you structure headings?
Headings should be set in levels – <h1>, <h2>, <h3>, <h4>, <h5>, <h6>. Those levels should go in order numerically, with the most important part being a <h1>, and then go down from there. However, the lower level headings should support each other, so content in a <h2> should directly relate to the content in the <h1>. A <h3> should support the <h2> directly and the <h1> in concept. It’s also important to note that there can only be one <h1>, this is an important rule, as there can only be one main point! I like to visualize this in a classic outline format to make it easier to understand:
<h1>Main Point<h2>Supports the Main Point<h3>Supports the Second Point<h4>Supports the Third Point<h5>Supports the Fourth Point<h6>Supports the Fifth Point
It’s pretty unlikely that your emails will go through all six headings unless your email is very long. It’s more likely your email will look more like this:
<h1>Main Point<h2>Supports the Main Point<h3>Supports the Second Point
<h2>Supports the Main Point<h3>Supports the Second Point<h4>Supports the Third Point
When things go right:
Here are some example designs with clear hierarchy that is pretty easy to sort out:
Bloomscape – Don’t let this summer find slip away…
<h1>A Fresh New Find – The Lemon Tree<h2>Why We Love the Lemon Tree<h3>Freshly Squeezed Citrus Delights<h3>Lively & Vibrant<h3>Refreshing Aromatherapy<h3>Enchanting Beauty
Rael – Glow with every phase of your cycle✨
<h1>Cycle Sync Your Skin Care<h2>Made for Every Phase of Your Cycle<h3>Menstrual Phase<h4>Hydration Sheet Masks
<h3>Follicular Phase<h4>Collagen Sheet Masks
<h3>Ovulation Phase<h4>Vitamin C Sheet Masks
<h3>Luteal Phase<h4>Tea Tree Sheet Masks
<h2>Supports the Main Point
<h1>Orange you glad we added these?<h2>Vitamin C<h2>Organic Turmeric<h2>Beta Carotene<h2>Pumpkin
When things go wrong:
And this is where things get tricky. Frequently, our emails don’t actually have one cohesive main point. That’s one of the (many) ways that email deviates from web pages. Most web pages can be about one specific topic, and that’s where the hierarchy makes sense. Take a look at this Wikipedia article on Barack Obama, and you’ll notice that the main article title is the <h1>. The secondary headline “Early life and career” is an <h2>, and within that section, the heading “Education” is an <h3>. This makes sense in most web pages and especially informational sites.
Our emails frequently have multiple different kinds of content in them, and very often content lower down in an email may have very little to do with the content at the top, aside from tangentially being related to the company that sent the email. Here are some examples:
<h1>Switch the Shampoo<h2>Shampoo Bars<h3>Meet your match
<h?>Conditioner Bars<h?>Carbon Positive Cork<h?>Leave the world lusher than we found it???????
Sling – ⚔️ Outlander Season 7 premieres tonight!
<h1>New season streaming now<h2>Watch every outlander episode and so much more!<h3>Check out the trailer!
<h?>More on Starz<h?>Other channels you might like on Sling Freestream?????
VidAngel – Streaming something this weekend?
<h1>Customize your streaming experience<h?>New to VidAngel<h?>New Episodes<h?>In Case You Missed It<h?>Trending this Week????????
So, if you can’t have more than one <h1> and there isn’t one main point of your email, what can you do?
How to solve for multiple points in an email:
This solution is great for any email that has multiple points, or where you really don’t know what is going to go in the different sections of an email. I do this a lot when I’m creating modular systems that might have varying bits of content. I put the company logo in an <h1> tag. Remember when I said that sometimes the headings can be only tangentially related to the company that sends the email? This is basically making that happen from a code perspective:
<h1><img src=”company_logo.png” alt=”Company”></a></h1>Note: Because this image is now a heading, that means this image *must* have alt text so that the heading has an accessible name. If you link this image, it becomes a functional image and must now also include alt text that tells the user where that link will take them.
You’ll note that this varies from common suggestions in the web world where the logo should not be an <h1>. My distinction here is that we’re not talking about a website with a common header. We’re talking about separate and distinct emails, where a user can view several emails from different companies one after another. It’s worth noting here that while your total email campaigns may be similar, for example, they may have the same header, users rarely come across your email campaigns as a whole so it’s worth thinking on how a user most typically experiences your emails. Screen reader users will also get the from name and subject line read to them before getting into the email content so this isn’t necessarily going to be something to distinguish one email from the other. The point is that it’s not going to be horribly repetitive like it is in the web experience and it provides you with more flexibility to properly structure your email content in a way that supports AT users.
This allows the other headings in the email to start at <h2> and gives you a bit of flexibility in how these can be structured, so now we can update those more complex emails:
<h1>Lush<h2>Switch the Shampoo<h3>Shampoo Bars<h4>Meet your match
<h2>Conditioner Bars<h2>Carbon Positive Cork<h2>Leave the world lusher than we found it
Sling – ⚔️ Outlander Season 7 premieres tonight!
<h1>Sling<h2>New season streaming now<h3>Watch every outlander episode and so much more!<h4>Check out the trailer!
<h2>More on Starz<h2>Other channels you might like on Sling Freestream
VidAngel – Streaming something this weekend?
<h1>VidAngel<h2>Customize your streaming experience<h2>New to VidAngel<h2>New Episodes<h2>In Case You Missed It<h2>Trending this Week
Feels better, doesn’t it? This way you don’t have to try to shoehorn some of these elements together. It’s okay that we have emails with multiple points!
How to solve for heading variables in modular design systems:
Our industry has been digging modular systems for quite some time, and why wouldn’t you? They are easy to implement, can give amazing versatility, and take less time to build individual emails. Amazing! But how do we organize headings if we don’t know which modules will go above/below the others? I have a few solutions that may/may not work for you:
- Update headings at the end of email creation
In this scenario, it doesn’t matter too much what the module says the heading is, you change it once you have an email built from those modules and use the content in the email to determine what the heading levels should be. That way if a designer removes a heading or adds an eyebrow, you just adjust it as needed. - Lock down heading hierarchy
This one is harder to make work. In this scenario you have very clear categories of modules: primary, secondary, tertiary. You will have to commit (and get your designers to commit 😅) to rigid adherence that there will *always* be a primary and secondary module used, each with their own heading adherence. I don’t think this one is very realistic, but would be necessary if you’re doing a lot of dynamic modules being pulled into your email. <h2>all the things!
So in this scenario your logo in the header would be an<h1>and you would just make every module start with an<h2>and follow hierarchy within that module only. This can work when you have larger modules and are pretty confident that you would have a lot of different points to make in your email. I tend to do a mix of this and #1 – so I use<h2>’s in the modules themselves, but still update them when I’m building an email from those modules.
What are some other things I need to know about creating accessible headings?
- Don’t use headings as a way to style text. Wrapping text in a heading usually makes it bigger and bolder, but that can be confusing for users if that text doesn’t have heading content. The biggest piece of text or the first piece of text doesn’t have to be a heading if the content doesn’t warrant that.
- Do not skip a heading level. This can be hard when your email might have dynamic content or is part of a modular system. Plan ahead and/or create a process in which your headings can be updated when creating an email from modules.
- Try not to link your headings if you already have other linked content in that heading section. It’s annoying and confusing if you have an image, headline and CTA all linked to the same place. It also gets really redundant when using a screen reader.
- Try to keep your headings short and easy to understand.
- If your headline has typographic variations like this:
Wrap the entire headline in one heading tag and use span tags to control the styling like this:<h2><span class=”serif”>Fonts <em>for</em></span> Complex Data</h2> - Color contrast! You still (always) need to have good color contrast between your headings and their backgrounds – especially if you’re using a background image. (But please don’t use VML)
- Don’t use images in your headings unless you have to. And if you do use images as your headings, make sure you are using appropriate alt text.
- Don’t use all caps – Screen readers are not great at discerning the difference between all caps and abbreviations and frequently spell out words set in all caps. Unfortunately this can also happen with a text-transform applied, sorry folks! (If you have to I prefer text-transform over using real caps)
- Do not use multiple
<h1>tags. I know I already said this, but saying it here in case you weren’t reading above. - You don’t have to start with an
<h1>tag, sometimes your design might have an eyebrow or other supporting text above your heading, that’s okay! - All bold text doesn’t have to be a heading. Product names, article titles or other elements that are important but don’t really provide structure to the page wouldn’t usually be a heading and might be weird to have in the heading list. Remember that this is a way to guide a user through the email, not just a style.
- Every email doesn’t need a heading. Short emails, like transactional or notification emails, that are just a paragraph of text don’t need headings. No need to force one in there if the content doesn’t support it.
Note: Mark Robbins of GoodEmailCode.com has some detailed notes on issues pertaining to <h1> tags that might already be in webmail clients that’s worth a read-through. This gets us into a broader topic that I think is worth discussing – are we or are we not responsible for the existing code outside of our emails when it comes to accessibility? Which I think deserves its own post so I’m going to skip over that for now. My answer is to use the <h1> because that makes our email HTML files accessible and because that will work in the majority of popular email clients.
Another note: As always I pulled these examples and am using them the way I’d want them to be, not necessarily the way they are used. In truth, I was looking for visual structure/hierarchy and didn’t look at the code at all. Lots of these examples don’t fit my criteria for accessibility and I’m not claiming any of them here do!
Phew – this is a lot of info about headings. As always, I’d be curious to hear if your thoughts vary from my own or if you have any other solutions in structuring your headings in modular systems. I always love hearing from other developers about how they work.