-
Notifications
You must be signed in to change notification settings - Fork 6
How to Write a 508 Compliant Email
So, you’re looking to ensure the emails you are writing are as accessible as possible to all people. Fantastic!
This guide is intended to support the Department of the Interior’s efforts (and your efforts!) towards digital inclusion and accessibility.
It covers the basics for sending accessible emails: alternative text, accessible links, accessible list formats, fonts, tables, and Outlook’s accessibility checking function.
1. Add alternative text for all visuals
If you are adding visuals, like images, charts, or graphics, to your email, assign descriptive alt text (also called alternative text) to the visual. This text serves as an alternative to images and helps screen readers convey what is contained in the visual.
To add alt text to a visual on an Outlook document, right click the image and select “Edit Alt Text”.
This works for images, SmartArt graphics, and charts.
When writing alt text, answer the question: How would you describe this object and its context to someone who is blind?
2. Utilize meaningful words in link text
When writing text for a link, provide meaningful words to communicate information about the linked page. An individual using a screen reader has a better experience reading several different descriptive link texts than they do reading “Click here” several times on the same page.
3. Use accessible list formats
If you’re using lists, use either a numbered or bulleted list. This helps screen readers to read the list.
4. Ensure color is not the only option to identify information
If color is the only means of identifying information, like in text linking to an external site, some people with color blindness or visual impairments may not be able to see the link. Text that is blue in color is less accessible than text that is both blue and underlined. In your email, underline links as well as indicating the link with color.
5. Use an accessible font setting
Section 508 does not contain specific guidance on font settings. To make your email as accessible as possible, use a font that is clearly defined and easy to read. Familiar fonts like Arial and Calibri help reduce reading load. Avoid using all capital letters or italics for more than 10% of a paragraph if it can be avoided.
When using headers, follow a logical top to bottom order to organize information. Start with an H1, then use and H2, and finally an H3. This helps individuals with impaired vision differentiate between sections and makes it easier for screen readers to read your email.
6. Use an accessible table format
When using tables, keep in mind how screen readers will read them. Keep formatting simple when sending emails, use one header per table. To add alt text to a table, select the full table, right click and select Table Properties. On Table Properties, navigate to the right, click “Alt Text,” and select your alt text.
7. Check text for contrast
If you are using multiple font colors, check them for contrast with each other and with the background.
You can drag a screenshot into https://contrastchecker.com/ to check contrast.
But in general, just use black text for email.
8. Use the Outlook Accessibility Checker
Finally, before sending your email, use Outlook’s Check Accessibility feature. Navigate to the Review tab on the top of the page, and select Check Accessibility from there.
Check Accessibility will check for accessibility options and provide a list of fixes called Recommended Actions. These actions provide easy fixes to accessibility issues. You can also have the Outlook Accessibility Checker run while you work in Outlook by selecting File -> Options -> Ease of Access -> Keep accessibility checker running while I work.
References
This guide draws heavily from the 18F Accessibility Guide (https://accessibility.18f.gov/) and the Microsoft guide titled “Make your Outlook email accessible to people with disabilities” (https://support.microsoft.com/en-us/office/make-your-outlook-email-accessible-to-people-with-disabilities-71ce71f4-7b15-4b7a-a2e3-cf91721bbacb).
- Problem statement
- Product vision
- User scenarios
- What we're not trying to do
- Product risks
- Prioritization scale
- Technical overview
- Contributing to code
- Creating a new branch
- How to prepare and review PRs
- Releasing changes
- Database change management
- Tech Solutions
- Data overview
- How to upload monthly data
- How to upload OGOR-B Data
- Troubleshooting for specific datasets
- Goals and metrics
- Analytics
- DAP-GA4 templates & instructions
- DAP-UA templates & instructions
- User research plans & findings
- Joining the team
- Onboarding checklist
- Working as a distributed team
- Planning and organizing our work
- Sample retro doc
- Human centered design process
- User research study process
- Design Standards
- Usability testing process
- User research participant guide
- User research agreement
- Observing user research
- Design and research in the federal government
- Shaping process
- Research wiki
- Data catalog
- Problem statement (2016)
- Hypotheses (2016)
- Outcomes workshop (2017)
- Transition goals (2018)
- Product management training (2018)
- Information architecture
- NRRD-flavored Markdown (Jekyll site)
For information about our other website see our ONRR.gov wiki.