Ensure the contrast between foreground and background colors meets WCAG 2.1 AA minimum contrast ratio thresholds.
Ensure the order of headings is semantically correct especially if reordering or adding new headings. Use heading tags <h1> to <h6> and only use <p> tags on body copy, not headlines.
Follow the guidelines in the Alt text in emails Accessibility Standards v1 Feb 2025 PDF in the Guidelines section of the M-EDS pack - ensure there is appropriate alt text present for every image, graphic or icon that needs it. Version 2 of this document will also cover dynamic content such as Moveable Ink.
Ensure tables have the appropriate role attribute - adding a presentation role to the table enables a screen reader to read the customer-facing text in a more accessible way. Do not delete any ARIA labels already present in the HTML.
ARIA is not supported by all email clients and can be removed by some HTML sanitizers, but if good semantic HTML is used, the need for ARIA labels can be kept to a minimum. Email Design System has always followed best practice in email by utilizing the ARIA attribute of role=“presentation” to ensure the table is read in a more accessible way rather than as table based data. In M-EDS 4.2 we have added more ARIA roles in the following ways:
- For links that open in a new window, the WCAG 3.2.5 Change on Request Success Criterion requires us to inform screen readers about the change in context. So now, in addition to the text provided for the link, we have included an ARIA label “opens a new tab” to indicate the change.
- ARIA labels have been added to links to convey the purpose of the link in some modules.
- The kinetic modules needed significant updates for better accessibility and ARIA labels have been used in some places to facilitate these.
Please note, do not remove ARIA labels when editing the code.
Emails should be fully navigable without a mouse. Ensure that all interactive elements (links, buttons, forms) can be accessed and operated using a keyboard.
Ensure this value is not left empty. If no title is available the title element can repeat the subject line.
Ensure the final HTML document has the correct ‘lang ’ attribute defined for the market, so a screen reader knows how to interpret the text, characters and what to accent for optimal pronunciation.
Links should have discernible text that semantically relate to the content and are obvious about where they are directing the user. This is why we never use “click here” in a CTA Link.
Lists should be constructed using the appropriate semantic markup - ensure to correctly apply <ul>/<li> or <ol>/<li> markup.
Version 4.1 of the M-EDS introduced new guidelines for Dark Mode and how it affects email rendering. Solving for Dark Mode is still very much a work in progress and needs regular monitoring to check for updates and changes.
The M-EDS palette contains styles and color combinations that will optimize the reading experience of our emails and protect against any operational risk that could arise from sending emails with illegible or inaccessible content.
The main watch-outs for Dark Mode are:
- Text, background and icon colors: Use the recommended combinations in our updated M-EDS palette and style guide.
- CTA links: Use CTA styles that follow the Dark Mode optimized ones in the updated M-EDS palette.
- Background patterns: Use transparent PNGs, never opaque
- Text over images: Test thoroughly and remember an alternate version or flat background color can be loaded for Outlook clients
- Logos/wordmarks: Check if an image that works in both modes is available image as a transparent PNG - if not create an appropriately cropped image with a tinted background
- Code adaptations: There are a variety of ways of targeting specific email clients, for example text in Gmail can be prevented from lightening if a blend mode style is applied to it. However, none of these hacks work across all clients so our policy is to use styles that will work across all clients.
Managing Dark Mode
Litmus and Email on Acid both offer previews of emails in various Dark Modes and are our recommended way to check for legibility and accessibility issues. Device testing is also advised if possible.
Dark Mode only on iOS and Apple Devices
Currently, Dark Mode styles are not specified in our email code. The issues we deal with come from the clients that impose their own Dark Mode styles on our emails. Discovery is underway into how we will implement our own Design System that appears in web and mobile app into M-EDS so that users of Apple and iOS email clients will see our customized Dark Mode themes.
Regularly test emails for accessibility with screen readers and other assistive technologies. An M-EDS policy for screen reader testing is still in development, meanwhile we advise designers and developers to use the native ones that work on your own devices.
Emails can be listened to by using the Litmus ‘read my email’ feature when testing. We only recommend doing this when making significant changes to module code, rather than on every email.
