Email

Owned by Kim Collins (Unlicensed)
Last updated: Nov 02, 2022 by Joseph McLartyVersion comment
4 min read

While the information provided in this page will assist email authors, the purpose of this page is to provide information on ensuring email generated by applications is accessible.

Emails have several development issues because email clients have different levels of support for HTML and CSS elements. Some experienced web developers describe a steep learning curve with email because of the tendency to not follow modern web design standards.

Use a Fallback

Many users, including users of assistive technologies, prefer to read email entirely in plain text. They do not use HTML email and they do not download images.

Adding a text-based version of an email as a fallback provides a user with the option of not viewing the HTML version. This can be achieved using a MIME multipart email.

The following is an example of the body of a MIME multipart email that includes both plain text and HTML versions of the message:

From: Example Sender <info@example.com>
To: A User <a.user@example.net>
Date: Sat, 16 May 2019 17:40:11 -0500
Subject: An example multipart message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=asdfghjkl
--asdfghjkl
Content-Type: text/plain; charset=utf-8
Hello world!
--asdfghjkl
Content-Type: text/html; charset=utf-8
<!DOCTYPE html>
<body>
<p>Hello world!</p>
</body>
--asdfghjkl--


Use the text/plain portion of the email to provide a plain text version of all of the intended message content. Use the text/html portion of the email to provide the full HTML version.

All email should include both HTML and plain-text versions.

Layout Tables

Sometimes it is necessary to design email content to fit a specific layout. If layout is a concern, you may need to use tables for layout. Email is one of the few places where it is appropriate to use tables for layout. Using layout tables avoids the positioning and box-model issues experienced with <div>s in different email clients.

Since tables are for data, screen readers and other assistive technologies will provide users with information about their position in the table. To avoid this behaviour, add the ARIA role="presentation" to every <table> element that is being used purely for formatting, including any nested tables.

TIPS:

  • ARIA’s role="presentation" only needs to be added to each <table> element (not every <td>, etc.).

  • If a table is being used as a table of data, then do not add this ARIA role.

See Table Anti-Patterns - Layout Tables for further discussion and an example.

Example table structure used by most HTML emails:
<table border="0" cellpadding="0" cellspacing="0" role="presentation">
 <tr>
   <td>
     <!-- Content goes here. -->
   </td>
 </tr>
</table>

Images and ALT text

Modern email frequently contains images. Image blocking, somewhat uncommon on the web, is a common experience with email. For sighted users, blocked images create an accessibility issue.

Where an image is embedded in an email, use the alt attribute to include a description of the purpose of the image. If the image includes text, the alt text must include that text. The same alt text content rules apply as on the web.

By using alternative text, we not only create usable emails for low vision and blind users but also for sighted users who want (or need) to keep images disabled. Using alt text provides equivalent information to users who choose to not download images (e.g., for security or privacy purposes) as well as users who cannot see the images. Many email clients will display alt text, when available, in place of images.

Often, the entire email content is simply one or more images. This design should be avoided. The best approach is to design defensively against image blocking. Use live text, not text in images.

Remember to use an empty alt attribute (i.e., alt="") for graphics that have no purpose. Examples include graphics intended to provide whitespace (e.g., <img src="spacer.jpg" alt="">).

Semantic HTML

Like accessible web design, accessible HTML email depends on the use of semantic HTML that is valid and correctly nested.

While not all HTML5 elements are supported by all email clients, basic HTML elements like paragraph and header (<p>, <h1>, etc.) are well supported.

HTML5 landmark elements (e.g., <header>, <main>, <footer>) are not well supported across every email client. Some email clients will remove landmark elements and roles completely, so any class, id, role, or inline styles applied to these will be lost. It is strongly recommended that landmark elements not be used in email.

If you choose to include landmarks, use ARIA roles in combination with these elements (e.g. <header role="banner">). Some webmail clients already use landmarks for their own user interface so ensure landmarks used in the email are specifically labelled <header role="banner" aria-labelledby="header-title">. You may need to avoid using <main> or role="main" as this landmark may already be in use. Finally, consider using lower-level and nestable landmarks (e.g. <section>).

CSS

Many email clients do not support CSS style sheets or <style> blocks. Some clients will remove any CSS that is not inline. For this reason, it is necessary to use inline styling in email.

However, using inline styling can significantly impact the accessibility of content. It makes it impossible for recipients to use their own stylesheets and settings. Providing a plain text fallback is one way to address this issue.

Use visual styling to provide high contrast. Colour contrast should meet or exceed the contrast guidelines outlined in the Contrast Knowledge Base page.

Resources