| title | description | layout |
|---|---|---|
EMC Compliant Standards |
Top level concepts of what the HTML email markup should do |
@layouts/MainLayout |
The Email Markup Consortium (EMC) is working to improve email markup, the code used to structure and style content within an email. This document lays out the standards of what that markup should look like.
This document is aimed at top level ideas of what the email markup should do, not specific ways to code.
This document is for anyone creating email markup, processing email markup, or displaying email markup. This includes (but isn’t limited to) email developers, email creation tools, email sending tools, and email clients.
For this to work it will require developers to make improvements to the markup at the point of creation. As long as that markup is valid it should remain in a recognisable state with minimal changes through to the point the recipient opens the email. This means any processing of that markup by an ESP, mail server, email client or any other technology that touches it, should also follow the guidelines to preserve the standard.
The current state of email markup varies a lot. Email markup goes through several stages from development to being read by the recipient. Each of these stages can make changes to the markup. Depending on what services are used this can result in very different code being seen by the user as each service may take a different approach. This document sets out some top level goals for how the markup should be treated.
Without this, there can be a stalemate in seeing progress in email markup. Senders won’t include updates that email clients don’t support and emails clients don’t see the need to include updates that senders aren’t including. We need changes on both sides.
- This document is not a “how to” guide on how you can be compliant with these standards.
- This document does not cover email design or content choices.
- This document does not cover email sending protocols.
- This document does not take into consideration current levels of markup support; these are targets to strive for.
Accessibility is key to achieving our markup standards. When email markup is properly designed and coded, people of all abilities can use it.
Email content should respond to fit the size of the container it is loaded in. A recipient should not have to scroll on more than one axis to see parts of the email, nor should content be cut off.
Content should adjust to fit the available space with fluid content or @media queries.
User preferences should be applied to any email they are viewing. These could potentially be set at the OS level, browser level, or email client level. They should inherit down through these layers into the email markup which should respect the user’s preference and be allowed to change the content accordingly.
Level 5 media queries can pass preferences like motion, colour schemes, transparency. We can also use rem units to pass prefered font size.
Assistive technology should be able to quickly and easily discover an email in a webmail page or app using landmark navigation.
Using a semantically appropriate landmark with a descriptive label, often this may be the same as the subject line.
Keyboard focus should be visible at all times within the email content.
Either use default :focus or suitable custom styling.
A recipient should be able to manipulate the content to a point to make it readable. This aligns with the W3C Technical Architecture Group (TAG)'s Ethical Web Principles:
People must be able to change web pages according to their needs. For example, people should be able to install style sheets, assistive browser extensions, and blockers of unwanted content or scripts or auto-played videos.
This can include zoom tools, style adjustment tools, and translation tools.
Email markup should work in a logical semantic structure without interfering with the email client structure.
Use logical heading structure. Avoid using a <main> landmark in the email content as this is likely to already include a <main>
landmark.
Emails should define a language and language direction for the content. Any changes of language should also be defined in the markup.
Set lang and dir attributes
In addition to these recommendations, you should also consult the latest WCAG standards.
Markup should follow Postel’s Law: “Be conservative in what you send; be liberal in what you accept.”
All code should be within the WHATWG HTML Standard. Any use of non-standard code should follow the guidelines for valid custom element names, custom data-attributes, etc.
Don’t make up custom elements, attributes, styles, etc. as it may interfere with future development of HTML.
Supported code should remain intact when unsupported code is removed from around or alongside it by a code sanitizer.
If invalid or unsupported code is removed, the code around it should remain unchanged. Gmail currently removes an entire style block for one mistake.
Unsupported elements should keep their supported attributes and be replaced with a semantically neutral element or valid custom element.
Replace <main class="foo"> with <div class="foo">
Code that is dependent on support of other code should be grouped in a way that it can fallback without showing broken partial support.
Issues can arise when display: flex is supported but not flex-wrap. We can use approaches such as @supports targeting to help group these so they fallback cleanly.
Email is a global format, and should be built for all. Some recipients may experience very low bandwidth or very high data costs. This needs to be a consideration so email markup can perform with these restrictions.
Emails should be able to display and perform all actions in a low bandwidth environment.
Keep external assets to a minimum file size.
When assets fail to load the content should still be consumable.
Fallback fonts, good alt text, placeholder background colors behind solid images, or background images.
Unused hidden assets should not be downloaded.
Swapping images should be done with <picture> elements.
Assets should load using suitable formats with optimum compression.
Use AVIF, WebP, SVG in <picture> and/or srcset.
Alternate content should be provided when requested.
plain text version, use prefers-reduced-data query
- (no changes yet)