Improving email accessibility

Although constantly evolving, emails often still don’t fully comply with web accessibility standards.

To be compatible with older email clients or those that don't follow current HTML and CSS standards, we have to use HTML tables (<table>) for the page layout. Although old-fashioned, this practice is necessary to ensure better compatibility across different email clients.

However, the Email Builder is resolutely committed to the mission of making email and the web more accessible and inclusive. Here are a few measures we've put in place to help you improve the experience for all your readers: 

The Email Builder automatically detects the language of your email and adds it to the generated email code.

This feature helps assistive technologies (for example : speech synthesis) to better interpret the content.

You will see new lang and xml:lang attributes appear at the beginning of your email indicating the detected language:

To learn more, find additional information on the w3c website.

Structured headings (h1, h2, etc.) are recommended by the Web Content Accessibility Guidelines (WCAG) to improve document navigation.

Unfortunately, they are tricky to use in email, as they often generate visual inconsistencies.

In the email, we therefore use role=‘heading’ and aria-level attributes, to avoid visually impacting your email while maximizing accessibility.

In the Designer, select your text element and then define its heading level using the field provided.

To learn more, find additional information on the w3c website.

The ability to navigate emails using the keyboard is a crucial aspect of accessibility. We generate the code needed to provide users with visual feedback on keyboard navigation, without degrading the experience of mouse users.

When using keyboard navigation, we display a purple frame on clickable elements.

Keyboard navigation is explained in these two articles:

• W3C article
• Webaim article

By using attributes such as aria-hidden=‘true’ or role=‘presentation’ we indicate to assistive technologies which elements should be ignored because they do not contribute to the meaning of the message.

This practice, which complies with good accessibility practice for web applications, can be transposed to emails:

To learn more, find additional information on the Mozilla website.

We recommend using the target=‘_blank’ attribute carefully to avoid confusing users, in line with WCAG recommendations.

A judicious use would be to reserve this feature for outgoing links in your environment (e.g. links to social networks, links to another website, etc.).

Accessibility is a constantly evolving field, and while we can't automate everything yet, it's crucial that you actively participate in this process by understanding and using the tools available to you on our platform.

Improving accessibility is an ongoing process, and we are committed to continuing to update our platform to make the web ever more inclusive.

And that's not all. Accessibility is also a question of design and layout. Check out our blog article about Email accessibility.