These guidelines are intended to help members of the University community create email content that provides people with disabilities equally effective and timely access to the same information in emails and attachments that people without disabilities receive.
While primarily intended to help email authors, these guidelines may also help those deciding what and how to forward, to maximize the extent to which all recipients can access the information the email contains.
In addition to improving accessibility, many of these guidelines will create better experiences for recipients using mobile devices
The desktop email clients supported by the University — Microsoft Outlook, Mac Mail and Mozilla Thunderbird — offer authors the ability to format emails in rich text (HTML). Authors using rich text can enhance accessibility by using:
- Sans serif fonts such Arial, Calibri, Helvetica, Verdana, set no smaller than 14 points
- Headings formatted as headings (Heading 1, Heading 2, etc.), not just enlarged or made bold
- Lists formatted as lists, not just with symbols and numbers added
- Color contrast strong enough for users with low vision or colorblindness (generally 4.5 : 1)
- Meaningful links that are self-explanatory even out of context (eg, instead of “click here,” label the link “register now”)
- Left-aligned paragraphs (but not full justified), for even spacing and easier reading across platforms and devices
- Bold to emphasize text. Avoid italics, all-caps and underlines.
If including an image within the body of an email, or attaching a PDF, ensure all relevant information is also contained as text within the body.
Add alternative text to each image placed within the body of an email, to describe the image’s meaning in context. Microsoft Outlook (Windows and Mac) and Mozilla Thunderbird support adding alternative text. Mac Mail does not support adding alternative text, but does keep alternate text when quoting (forwarding or replying to) emails that contain it.
Avoid using images of text.
Avoid including images (such as 11 x 17 posters) within the body of an email, especially large-dimension images that contain text. Mobile devices display large images scaled down, making them difficult to decipher. Some email clients may crop, stretch, or squash the images. “Postcard” versions or details of larger images may suit authors who wish to include images while maintaining accessibility; e.g. use a 600-pixel wide detail or textless version of an 11 x 17-inch poster instead of using the poster itself.
Single-column layouts with left-aligned paragraphs and without tables are most likely to display legibly on all platforms and devices, and maintain basic accessibility if forwarded.
Outlook and Mac Mail do not give authors the means to ensure that multi-column layouts display legibly and consistently on different devices and screen sizes.
Vendors including Constant Contact, Direct Mail for Mac and Mail Chimp offer email template layouts that respond to recipients’ devices and clients, reflowing multiple-column layouts into single columns and scaling up text on small screens. These responsive layouts can deliver enhanced accessibility compared to emails authored in desktop clients, with typography and color palettes designed with accessibility in mind, and with specifications not available through desktop email clients.
If using a third-party platform be sure to:
- Choose a template that meet the Basic Tips above
- Add alternate text for images (the template should include the ability to add alternative text)
- Avoid using an image of text
- Use meaningful language for links
Choosing a Platform
Most platforms offer a free version or trial period. When evaluating platforms, test which tools are available to authors and what recipients will receive.
Third-party platforms should generate plain-text versions of formatted emails. Plain-text versions offer screen readers an additional option for interpreting message content.
Authors using third-party platforms should periodically test their emails in widely used desktop and mobile clients to confirm that layouts continue to display as intended.
Forwarding and Replying
Third-party platforms are most likely to suit authors who whose primary audiences are the emails’ initial recipients.
Outlook and Mac Mail do not include all formatting when replying to or forwarding responsive emails such as those sent through third-party platforms. Text will lose the ability to scale up to maintain a legible size on small screens, and multiple-column layouts will lose the ability to reflow into single-column layouts on narrow screen widths such as on mobile devices.
- Constant Contact
- Direct Mail for Mac | Creating a plain-text alternative in Direct Mail for Mac
- Mail Chimp
For Designers and Developers
Authors experienced in coding HTML may choose to customize free and shareware HTML templates or develop their own. Using Thunderbird’s “insert HTML” option, it is possible to send emails that are equivalent in accessibility and responsive features to email templates offered by third-party vendors. As with third-party templates, subsequent forwarding from Outlook, Mac Mail or mobile devices will remove responsive code and compromise accessibility, especially on mobile devices.
Due to the limitations of common email clients, tables remain commonly used for layout instead of being restricted to presentation of tabular data.
To help screen readers distinguish <table> elements that hold content from tables used for design, add role=”presentation” on each table containing content intended for reading (add it only to each <table> element, not every <td>).
In general, plain text emails are best reserved for short, simple messages without images.
Plain text does not support layout options such as tables and justification, and so precludes some potential obstacles for screen readers. However, plain text does not allow for semantic tools, such as tagged headings (“H1, H2”) and lists, that may assist screen readers.
Current email clients may support embedding images within plain text emails, but since plain text does not support tagging images with alternative text, image descriptions would need to be provided in the message body.