Basics:

Structural Content in Email Accessibility

TLDR; Structural content is the bones of your html file and are already described by Assistive technologies so you don’t need to label them. 

I’ve caught myself talking about structural content a few times in my posts and I really haven’t talked about exactly what that is, so now seems like a good time to do a bit of a side quest mini chat about what I mean by that.

It’s a little confusing when you’re starting out in accessibility determining what and how your digital content is interacted with by different Assistive Technologies. 

As an example – until you’ve read about and/or experienced how screen readers interact with headings, it’s hard to understand the value of putting important information inside of them and at appropriate heading levels.

What even is structural content?

When I talk about structural content – I’m talking about the code that surrounds the content of your email. It’s the framework that makes your content an HTML file and not a text file.

Examples of structural content:

• text elements like headings and paragraphs
• table elements and components like table cells
• landmarks!
• image and anchor elements
• To/From and subject lines

Obviously, we don’t have to tell the user what these things are. It would be super silly if we added an aria label on a paragraph tag and called it “paragraph”. (This is sarcasm) Different screen readers might read or interact with the same elements slightly differently, but that’s okay and is expected. Example: Different screen readers might not read the image, alt text, and link in the same order – totally fine!

We don’t really have much (if any) control over how structural content is described to the user. A really good example of this is the from name, subject line and preheader text. We just really don’t have any control over that at all when it comes to how AT reads it. 

In this context, it might be helpful to think about how different email clients visually display those three items differently:

Usually you have lines of rows that represent individual emails, and the from name is displayed first, then the subject line, and then the preheader. There’s a lot of variation within each email client though – how many characters of the preheader are visible, what emoticon library is being used to display emoji in the subject line, does the from line include the actual email address? Is an unread email bold or normal weight, or is it a different color? Sometimes when you click on the email, the email opens in the inbox pane to the right of the list of emails, sometimes the entire list is replaced by the open email. 

In that same way – content is read differently across different email clients when using a screen reader. It really is just like variation we have visually, just using the auditory sense instead of the visual one. Some email clients when read with a screen reader might read the entire preheader text, some will not. Some will include the email address with the from name, some will not. Some might say the subject line and then “sent by” the from name. Some might start with the from name and then read the subject line.

These variations are expected the same way we expect an outlook inbox to look different than a gmail inbox. 

It all goes back to semantics

This conversation goes hand in hand with semantic coding, because semantic coding is essentially the structure I’m talking about here.

That’s why we want to use an actual image with an alt attribute instead of some weird janky background image’d div – a div with a background image can’t give a screen reader user any valuable information. (well, in email anyways) But an image with alt text is going to tell the user what that image is all about and that there is even an image there at all.

Heading text that is set in a heading element isn’t just telling the screen reader user the text, it’s also telling them that this text is really important in the hierarchy of the page. Heading text that is just in a styled table cell doesn’t give the user any additional information and has no way to differentiate itself against the rest of the content on the page.

All of these structural elements can be communicated to the screen reader user as part of the screen reader experience. 

And that’s why we don’t need to describe these structural elements when we are labeling our content. I mentioned this earlier in the alt text deep dive, but we don’t want alt text that starts with “Image of” or “Pic of” or anything like that unless we really are providing additional context. 

Examples of situations we do not need to provide structural content:

1. We shouldn’t have super detailed alt text that explains the font and color of text in an image – unless that is relevant – ie. you sell fonts. (We want descriptions of things that are important to the message and communicating what the image is communicating)
   
2. We don’t need to tell users that they are reading an email when they are in an email client. (ie against the grain here a bit, but there’s no added value in labeling an email as an email)

3. Likewise, when we’re using landmarks, we’re not labeling the landmark itself by calling it “Company Name Navigation” as the landmark structural information will already be described to those users. (ie. You don’t need to include the kind of landmark it is in the label)

The case for declaring structural content:

The only real use case for actually describing structural content is when it truly is an atypical experience and you’re not able to use the typical structural elements. 

Examples of situations where you might want to provide structural content:

1. In my accessible slider, I labeled each slide individually as “Slide 3 of 6” to give users additional context since the way they are coded doesn’t really feel obvious as a slider experience. It’s not read across all email clients (of course lol) but it’s something useful for those that get it.

2. Really, most kinetic content or content that would be obvious visually but not as obvious when using AT should have more detailed descriptions/instructions.
   
3. When the content of the thing is being distinguished – ie. you send emails about famous artists and while referencing an artist’s wide variety of mediums or obsession with certain kinds of subjects. Ie. “Photograph of camels” “Painting of camels” “Drawing of camels”. (obvi in real life these would be more descriptive, I’m being concise.)
   

A lot of this becomes more clear when you start testing on your own devices and really trying out different screen readers on different devices. My best advice is to test against your own assumptions and see what you learn.

In the meantime – you can chill out a bit on your accessible name descriptions. Be clear – yes, but you’re not reinventing the wheel here, you can rely on the structural elements to help users navigate your emails. 🙂