Landmarks in Email

TLDR; Email clients do support landmarks and they should definitely be used (sparingly) to let users navigate emails more easily. The most supported landmark solution is to apply the aria role landmark and an aria-label to table containers for each landmark. Your aria-label should be short and sweet and should not contain the name of the landmark. A simple “Oracle” in Oracle email landmarks would suffice to separate the landmarks from the webmail clients. I suggest using banner, nav, main, and contentinfo landmarks, but not article and region.

Well over a year ago I did a lot of digging into landmarks – I did a lot of testing, read a whole lot, talked to some Oracle accessibility people, and then I did some more testing. I wanted to make sure I understood this critical navigation aid so that I could better understand what I’m doing and what my goals are when using landmarks in email. I have since largely hibernated on them because I wasn’t sure if I was right, and because I wasn’t sure they would actually be useful in email.

A few months ago the Accessibility Program Director at Oracle asked about using landmarks on an extremely long internal email that Oracle folks get every month. Turns out, one of our coworkers was pretty annoyed at having to read through the entire message to get to one part of the email that he wanted to read. I explained some of my hesitations, but that I had found a solution. He acknowledged the gap in support/favor but wanted me to implement it regardless, so I made the changes. The user stopped having trouble getting through the extra long email – a total win!

This request really challenged my thinking on landmarks in email so I have decided to share my findings.

First up – what even is a landmark?

On websites, landmarks are used to organize larger sections of content for assistive technology users – mostly screen reader users. Screen readers have a specific way of navigating web pages to jump from landmark to landmark. Usually there is a header, footer, navigation and main – but there are a handful others that can be useful as well in specific circumstances.

Landmarks are absolutely critical when reading long websites, like news sites, so that you can quickly get to the article you’re looking for. Another good use case is needing to get to the contact us link in the footer navigation – a screen reader user is able to quickly jump to the footer to find the link they need. Using landmarks is much faster than any other methods that screen reader users have to jump through the page. And even though it’s most helpful with long websites – it’s also just useful in general as a good way to get to exactly where you want to be on a web page or site.

A screenshot of a template using landmarks, displaying the landmarks using this landmarks extension on my browser.

In proper HTML5, you would use the semantic <header> <footer> <main> <nav> tags to wrap around these content sections. However, my testing (and common sense because I’ve been an email dev for a while) showed that these just don’t work in email.

Luckily, we can use aria roles instead which do the same thing. w3.org has a really good mini site that has a lot of great examples and descriptions inside it: https://www.w3.org/WAI/ARIA/apg/patterns/landmarks/examples/HTML5.html
(I have spent SO MUCH time on this page!)

Clicking the “Show Landmarks” button on that page will show you visually how these sections work and when you select the tabs down the left you can get specific information for each landmark type. And then within each landmark type there are examples in HTML and ARIA so you can see how each is coded differently.

So if we want to use the Navigation landmark we will want to use the role="navigation" instead of the html5 <nav> element. Okay, that’s easy.

But one of the items called out in this mini site is that you really shouldn’t have duplicated landmarks, and if you do, you should name them both so that they are clearly separate landmarks. Their example is to use an arialabeledby to control the accessible name of that landmark, however, my testing (and Mark Robbins’ post goes into deeper detail) shows that the arialabeledby attribute does not work well in email. Worse yet, it knocks the connection between the arialabeledby item and the landmark completely, meaning that you can’t even use a fallback aria-label. Unfortunately, the only good option is to use an aria-label to define those landmarks without the arialabeledby attribute at all.

So – If I were to make a navigation element in my email and give it a landmark, I would add role="navigation" and aria-label="(insert your landmark name here)" to the containing table that holds the navigation content.

There’s two parts of what I just said that are going to bug you, so let me explain:

1. If you’ve been paying attention you know that we are supposed to add role="presentation" to every table in our email and we functionally cannot have two roles on one table. Using a landmark role here will result in a technical failure if you’re running your email through an automated accessibility checker.
   
   Let me explain my thought process here: From a purely functional perspective, adding role="presentation" (or "none") to your tables doesn’t change much from an experience standpoint. Yes – we’ve all heard the awful description of table content when read through screen readers, but, hear me out: that’s not a very typical experience anymore. In every email client that I have tested, the addition or removal of the role presentation has zero impact on the readout and experience of reading the email with a screen reader. The one email client that is a total pain and reads out the table columns and cells does so with the role="presentation" included anyways. :/ (This does not mean that you should not include role="presentation" when you can, just that it doesn’t directly impact the user experience the way you may think. It’s important even if it doesn’t change the readout!)
   
   So from my experience, it is worth removing the role="presentation" on these containing tables to add the functionality of a landmark, when one is needed.

2. Before you even say it – from my testing landmarks didn’t work as well in divs or any other kind of container. Or at least they didn’t work better than putting the landmark in the table, which won by a landslide.
   
   What I found was that when used on the table element with an aria-label, nearly every email client I tested captured the landmark and aria-label exactly how it was supposed to. My only caveats here are all things Yahoo (not surprising because Yahoo really isn’t great with supporting accessibility anyways), and another non-surpriser called PC Outlook. What actually surprised me was that I tested these landmarks on “New Outlook” and was absolutely flabbergasted to discover that New Outlook on a PC supports landmarks with aria-labels perfectly, but again best when used on the table element.

Alrighty – hopefully you’re with me that the best solution is to put the role and aria-label on the containing table element of these sections. 

Next up is the question of whether or not to duplicate them.

If you’ve read about landmarks as I have, you’ll discover that there really are a lot of differing guidance on landmarks and whether or not they can (or should) be duplicated. It’s rare to find any kind of caveat or nuanced conversation on atypical experiences like what we have with email.

It’s an admittedly weird problem: In webmail clients there already are landmarks, so if we send in an email with landmarks, we are most certainly going to duplicate them. However, if we send an email without landmarks, users aren’t going to get the benefit of the extra navigation aid on all the other kinds of email clients.

So what’s an email marketer to do?

In the w3 page I provided earlier, there are specific notes about each landmark type. In the Banner tab, under “Design Patterns” we have: 

“Each page may have one banner landmark.”

Which is pretty clear! But a few lines later it says:

“When a page contains nested document and/or application roles (e.g. typically through the use of iframe and frame elements), each document or application role may have one banner landmark.”

To me – this sounds like a fairly decent description of a web email client as it is displaying a document, our emails. To me, this means that we can have duplicated landmarks in our specific instance.

And:

“If a page includes more than one banner landmark, each should have a unique label.”

This is where things get a bit tricky because most webmail clients do not have their landmarks labeled, so we literally can’t make each duplicate landmark labeled. But – we can make sure our landmarks are labeled, and it works really well, so I think this is “as good as we can get until/unless email clients step up their game”. We can’t control what email clients do or do not do, but I think it makes sense to use landmarks in this way to support more users.

There is similar verbiage on each of the landmarks listed on that W3 site, even for the main landmark. So from a duplicate landmarks perspective, I don’t see any reason to write off any specific landmarks.

When should we use landmarks?

Like I said earlier, landmarks help screen reader users navigate throughout a web page to quickly get to the section of content the user wants to get to. I think there’s two trains of thoughts on whether we should use landmarks at all, so I wanted to explore those here with you as well.

In favor of the use of landmarks:

There’s plenty of instruction around landmarks that states that you really should be minimal in your use of landmarks. Not every section of a page needs a landmark! We’re really going for generalized and standardized content that makes it easier to navigate without bogging the user down with a bunch of useless information. So I’m going to stick with that trend and make sure I call out that we don’t want to over-landmark our emails.

With great power comes great responsibility. I think it makes sense to include landmarks generally – with a banner, nav, main and content info. Especially on longer emails – or for those of you that have giant blocks of links in the bottom of your email. I think it just makes sense to use landmarks to make it easier for users to get to the content that they want.

In favor of not using landmarks:

I think there’s some good reasons not to use landmarks – namely in shorter transactional emails. Does your password reminder email need landmarks? Probably not. Your shipment confirmation? Depends what’s in it. I think that smaller emails (like a few lines of text and a link) are just going to be more annoying for users if you include landmarks. So best to leave those well enough alone.

Which landmarks should we use?

For the purposes of my testing, I tested the following aria roles: banner, main, contentinfo, region, article, and navigation. I had two navigation landmarks nested in the header and contentinfo, and the region and article landmarks were nested within the main landmark.

I overwhelmingly found good support for the banner, main, contentinfo and navigation landmark roles. They worked well and navigated well when tested across most email clients and with all screen readers.

I found less support for the region and article roles. Strictly speaking, the article role isn’t really a navigational landmark, but I know lots of emailers use it, so I thought it was worth testing. Generally, I found that articles and regions were supported in some email clients but not most, and rarely supported in the same email clients. This is a bummer because it would be great to highlight certain sections in our emails that would be useful to users outside of just being within the main landmark, but it doesn’t seem to be much of an option. (It’s okay – once into the main landmark users can switch to navigating by heading and you’re already adding appropriate headings, right??) I think you can still use region and article landmarks, just be aware that you’re only reaching a few email clients on android devices.

Note: I’m going to add that it’s possible that the nested nature of those landmarks could be part of that issue and I will test again to see if that changes anything. It’s worth noting that this didn’t impact the nested navigation landmarks in any way, but this is email and some of this stuff is just really weird.

What should our landmarks say?

Just like we don’t need to call out in our alt text that something is an “image of” a pair of shoes, we also don’t need to include the landmark type in our aria-label. The screen reader calls that out to users as part of the structure of the page, so it’s not needed. In scenarios where we are competing against a webmail landmark, I think it’s important to call out the landmark using the company name of where the email is from. (I’m saying company name here because generally email marketing comes from a company – but mostly just trying to make sure we are distinguishing these landmarks clearly from any webmail landmarks that may exist)

Short and sweet is the guidance here – we don’t want to say “Tide, part of the Procter & Gamble family, where your cleanliness always comes first” 

We just want to say “Tide” as the screen reader will have already communicated to the user that they are reading an email from Tide, what the subject line is, etc. 

By putting the company name there, you’re differentiating the landmark effectively and connecting it to the email they are reading, which is the goal here. There’s no sense using additional structural terms here like “email” or “from Jamie” – or again, the landmark type – in the aria-label. This really should be short and sweet.

This also makes implementing landmarks in our modular systems much simpler as well – one less thing on our checklists to chase after.

Final Thoughts

As I said earlier, this is something I have spent a lot of time researching and testing and I’m fairly confident in the direction I have taken and laid out here. I have started to implement these practices in the emails I build and I believe they are really helping screen reader users better access the content in their emails. In most emails I will include a banner, main, and contentinfo landmarks, along with a nested nav landmark where appropriate.

——–

Mark Robbins has posted this great article on landmarks that goes into a lot of detail and talks about some of the intricacies/problems/questions of using landmarks in email. This post is hopefully a “yes, and” to that, in the sense that I found a lot of the same things, but ultimately came to some different conclusions than Mark did. In the end, email accessibility is pretty complex and without direct guidance, we are somewhat left to our own devices to sort out what works and what doesn’t work. This is my thought process, available for full dissection.