Component:
Legal Text
Legal text is probably the least thought about component in all of emaildom. I’m talking about the large block of text at the bottom of nearly every piece of email marketing that graces your inbox. The times you look at it as a consumer are small. You’re either desperately trying to find that unsubscribe button (okay the only people that click the unsub button are email marketers, let’s be real) or to check to make sure the thing you want to buy with that Kohl’s 30% off coupon isn’t excluded.
Quick Examples of Legal Text blocks:
The Basics:
Before things get too technical, let’s start with the must-haves. Your legal text must meet the following criteria:
- Color contrast: make sure all your text, even your links, meet minimum color contrast requirements. This helps users with low vision and color blindness.
- Distinguishable links: make sure your links are noticeably different from other text, usually this means underline. This helps users with low vision, color blindness and reading disabilities.
- Alignment: You definitely want to left align this content to make it easier to read for users with reading disabilities and low vision.
- Superscript content: in the days of yore, superscript content was done using a span tag or some other weird hacks. Make sure you use the actual <sup> tag for superscript content. This is just plain semantics, which is important for AT users in general.
- Auto-linking: Be aware of the accessibility ramifications if you try to subvert auto-linking. Do not use a dummy link (an href with no value) and style it to look like the rest of the text. I think you are better off linking this content yourself and controlling where the link goes to than to try to hide the auto-linking or causing confusion by dummy links or span overrides.
Alright, those are easy, let’s get technical and talk about how to structure this content to make it easier for AT users.
Once upon a not-so-long-time-ago:
I would have just dumped the legal text block in one large table cell with line breaks between each block, like this:
<td>
Legal Text Paragraph 1<br/><br/>
Legal Text Paragraph 2<br/><br/>
Legal Text Paragraph 3<br/><br/>
</td>
I’ve also seen folks who have multiple table cells for each block of text. That’s not any better.
Why isn’t this accessible?
Well, the biggest thing to consider here is semantics. Each of these paragraphs of text is its own piece of content. Think about it, the super rare occasion that you DO read footer text, you’re looking for something specific, right? If you’re trying to make sure that your next pair of Levi’s is not an exclusion in the legal text for your 30% off offer at Kohls, you are not reading every single line of text in that footer, are you? You’re skimming for the block of text specific to that deal. When you have a giant block of text with line breaks between each block (or blocks in their own table cell) you are forcing screen reader users to go line by line.
So what’s better?
Actually using paragraph tags around separate paragraphs is the semantic solution and the better option for screen reader users:
<td>
<p>Legal Text Paragraph 1</p>
<p>Legal Text Paragraph 2</p>
<p>Legal Text Paragraph 3</p>
</td>
Screen reader users can jump from paragraph to paragraph, skimming the first few words of a paragraph to find relevant content too. BUT the way that a computer tells the difference between a bucket of text and a paragraph is how you code it, and that’s why the semantic paragraph is the better option.
What could be better than that?
This is a bit of a dream/fantasy world, but if your legal text is super locked down, you should have a numbered disclaimer list that matches up with superscripted content in the main part of the email. If we didn’t work in email, you would then use an anchor tag to bring the user from the superscripted 1 to the first list item in the footer.
Unfortunately, we work in email and anchor tags don’t really work across a very large percentage of email clients. I personally have found that this lack of working anchor links is a real deal-breaker. Usually in email, we are excited enough if something works in one email client and doesn’t break the email everywhere else. But in the realm of accessibility, we don’t want to confuse by having something work one way in one email client and another way in another email client if we can help it.
<td>
<ol>
<li>Legal Text Paragraph 1</li>
<li>Legal Text Paragraph 2</li>
<li>Legal Text Paragraph 3</li>
</ol>
</td>
Do this if your entire email system is working in military precision – ie. probably don’t do this.
The above really only works in a few scenarios where the legal text and email content are all created together and where the numbered content is easy to control. OR, a very large organization that has been working on this for years and has extremely dynamic content, and the team is in total lock-step on how to dial all the pieces together. Anything in the middle is impossible. I have only had one client in my entire history of emailing that was ever able to manage the above solution.
Before you jump on this: Know that you’ll really need to have your legal team on board for this too. Weird other characters like daggers and asterisks aren’t going to work. Your legal team and design team are going to have their heads aligned to ensure that #2 in the design matches #2 in the legal text block. Yes, that is super obvious, but in email, so much is moving all the time that it’s frequently hard to manage these levels of detail.
My final answer?
I think the most accessible and easiest to understand solution for more users is the list option. Super clear for so many users – they know exactly which disclaimer they’re looking for. Keep in mind though, if you don’t get something right, you’re making something inaccessible for nearly all users – ie. If you give #2, #1’s legal block, that isn’t going to give the user access to the content they need. Assuming that your company cannot pull that off, the best and easiest to implement solution is to use paragraph tags to separate your legal text blocks. It helps all users get the content they need as easily as possible and as error-proof as possible.
And so ends another deep dive on the accessibility of a common email component. As always, I’m happy to answer questions or make updates if you think I missed anything important.