Email & E-Newsletters

Outlook has a built-in accessibility checker and supports heading structure, but how you compose your email significantly affects the output.

• Use Format → Styles to apply heading levels (Heading 1, Heading 2, etc.) for any email with multiple sections. Do not simulate headings by manually changing font size or applying bold — this creates visual structure only, not semantic structure, and screen readers will not recognize it as a heading.
• Avoid pasting content directly from Word. Word's HTML is notoriously bloated and frequently breaks screen reader reading order when rendered in Outlook. Instead, paste without formatting (Ctrl+Shift+V) and re-apply formatting manually within Outlook.
• Avoid using tables for layout. If you need to display actual tabular data, use a table — but ensure it has a header row. Never use tables to create visual column layouts; they scramble reading order for screen reader users.
• Animated GIFs: Outlook desktop does not play animated GIFs. It displays only the first frame as a static image. If you use an animated header or GIF, design it so the first frame is the complete, fully readable version — not a mid-animation state.
• For email signatures, use real text for your name and contact information. Image-based signatures are invisible to screen readers and fail to display when images are blocked. Review the University's Brand Guide for more information on proper email signature formatting.

Running the accessibility checker: In the Outlook desktop app, go to Review → Check Accessibility. In Outlook on the web, look for the accessibility option under the three-dot menu (More options) before sending. The checker flags missing alt text, ambiguous link text, and some contrast issues — but it does not catch all WCAG failures. It is a first pass, not a complete audit.

Known limitations: The Outlook accessibility checker does not verify color contrast ratios. Check contrast separately using the WebAIM Contrast Checker before sending any email with custom colors or branded templates. The checker also does not evaluate reading order or the logical structure of multi-column layouts.

Constant Contact has useful accessibility features, but a significant structural limitation that you need to work around.

• Always use Text blocks for body content. Never place all your content inside image blocks — image-based email is invisible to screen readers and fails entirely when images are blocked by the recipient's email client.
• Alt text: When you upload an image, Constant Contact defaults the alt text to the filename. This is almost never appropriate. Click into the image settings and write a descriptive alt text for every informational image. For purely decorative images, clear the alt text field entirely so it is empty — this tells screen readers to skip the image.
• Link text: Use the Insert Link button to set descriptive link text alongside the URL. Do not paste bare URLs or use "click here" — Constant Contact makes it easy to add proper link text, so there is no workaround needed here.
• Plain text version: Constant Contact auto-generates a plain text version from your HTML content. Review it manually before sending. The auto-generated version frequently truncates or drops links, removes section breaks, and misorders content. Every link must appear as a full, spelled-out URL in the plain text version.
• Use a single-column layout wherever possible. Multi-column layouts in Constant Contact can produce unpredictable reading order for screen readers depending on how the template renders.
• Run the built-in accessibility checker before sending, then verify color contrast separately — the built-in checker does not evaluate contrast ratios.

Known limitation: Constant Contact does not currently provide a way to identify headings programmatically. You can enlarge or bold text to create visual headings, but these are not recognized as heading tags by screen readers. This means screen reader users cannot navigate your email by heading structure the way they can on a properly structured web page. To partially compensate: keep your email structure simple and linear, use clear section labels as the first line of each text block, and avoid complex nested layouts that depend on visual hierarchy to make sense.

Gmail does not have a built-in accessibility checker, so the responsibility for accessible composition falls entirely on the sender, though extensions are available for the toolbar .

• Use Format → Heading to apply heading structure when composing emails with multiple sections. Gmail supports H1, H2, and H3 through its formatting toolbar — use these instead of manually increasing font size.
• Use the built-in list formatting (bulleted and numbered lists) for any list content. Do not create lists by typing dashes or asterisks manually — these are not recognized as lists by screen readers.
• Avoid using tables for layout. Gmail's rendering of table-based layouts is inconsistent across email clients and frequently breaks reading order.
• For images inserted into Gmail messages, right-click the image after inserting it to add alt text. This step is easy to skip — make it a habit before sending any email with images.
• Link text: Highlight the text you want to link, then use Ctrl+K (or Cmd+K on Mac) to insert the link. Write descriptive link text in the highlighted selection before linking — do not link bare URLs.

Known limitations: Gmail has no built-in accessibility checker. There are browser extensions available — including WAVE for Chrome — that can evaluate a composed email before sending, but this requires an extra step that most senders will not take. For important or high-volume communications composed in Gmail, use the pre-send checklist on this page as your manual verification. Gmail's auto-generated plain text version also requires manual review, as with other platforms.

Delivra includes a built-in accessibility checker, which is its primary accessibility asset.

• Run the built-in accessibility checker before every send. Delivra's checker flags common issues including missing alt text, contrast failures, and link text problems.
• As with all platform checkers, Delivra's built-in tool does not catch every WCAG failure. Use it as a first pass and complete the manual pre-send checklist for any high-volume or high-stakes communications.
• Apply the same content practices as other platforms: use text blocks rather than image blocks for body content, write alt text for every informational image, use descriptive link text, and review the plain text version before sending.

Known limitations: Delivra's accessibility checker varies in depth depending on your account tier and template type. If you are unsure whether the checker is active for your account configuration, contact your Delivra account manager or submit a support request through the University's digital accessibility support form.