Accessibility Requirements for Email

This service is for faculty, staff, and students.

Accessibility Requirements for Email

  • Always include Alt Text on all images. 
    • For how to, select this Microsoft Office 365 article on how to create accessible emails in Outlook.  
    • Select whether you are accessing your email from Windows, MacOS, iOS, Android, or web
    • Then scroll down to the heading Add Alt Text to visuals for detailed instructions for adding your alt text. 
  • Use size 16 font minimum
  • Spacing must be between 1.5 and doubled spaced
  • Single-column format for emails to make them more mobile-friendly 
  • Avoid using justified text alignment.
    • Centered may be used for headings or subheadings.
    • Body should be left-aligned.
  • Tag the language of your email in the <html> tag in the beginning of your email so that screen readers read it in the appropriate language. 
    • Example: <html lang="en">
  • Use descriptive hyperlink text. 
    • Hyperlink text refers to the blue underlined text that is clickable and goes to a link location. Creating them well will make the email easier to read for both sighted users and screen reader users. 
    • Hyperlinks should always be descriptive and unique.
      • Avoid "click here" or "learn more" links.
      • A link or button should make sense if read alone, outside the context of the page.
      • Screen readers can read off all the hyperlinks on a page.
    • Hyperlink text should be a label, not the URL where the link is going.
      • Example: University of St. Thomas instead of www.stthomas.edu
    • The exception is for email addresses, where you want the link to be the email and the link location to be mailto:EMAIL-ADDRESS.
      • Example: example@stthomas.edu vs Example Email
  • Template / tables:
    • Most email templates are built using HTML tables. HTML tables are still the most reliable way to structure emails and have them display properly across the 90+ email clients in popular use. However, HTML tables are actually meant to be used for tabular data, not layouts.
      • The default for most screen readers is to read each individual table, table row, and table cell out loud to the user. For emails that often rely on multiple nested tables, this means that subscribers have to wade through a lot of markup garbage to get to the actual content. We can easily disable this behavior by including an attribute on each table in our email’s HTML. 
    • By including the role attribute with the value “presentation,” we effectively remove the table from the screen reader’s model and prevent it from being read aloud. The screen reader then skips to the content within, allowing the subscriber to focus on the content instead of manually skipping through useless layout markup.
      • It should be noted that other ARIA roles could be used instead of presentation. Presentation is set to be deprecated in future versions of the ARIA spec, with the “none” role replacing it. However, support for none is currently limited, so it’s up to you to decide which role works for your specific audience.
      • If you’re using tables to create bullet proof buttons, you may want to include the button role to provide additional context for users that need it. Just like with alternative text on images, though, you shouldn’t leave roles off of tables, as that will result in screen readers reading each individual table, table row, and table cell to the user.
    • HTML example: <table role="presentation" border="0" cellpadding="0" cellspacing="0"></table>
  • Tip: Use Litmus to run an accessibility check. It also has a feature that will allow you to hear how your email is read by a screen reader.
 To report a problem or receive additional troubleshooting, please contact the Tech Desk. 
Request Service Print Article

Related Services / Offerings (1)

Digital Accessibility Services
Services to help you to improve your digital accessibility use including Academic Technology, Closed Captioning with Media, Documents, Website, and Other Areas for Consultation.