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.
...
| Code Block | ||
|---|---|---|
| ||
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 necessary 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.
...