How JUNE automatically makes your emails accessible
1. Structure & HTML Semantics: Clean Basis for Screen Readers
lang attribute for <html> and <body>:JUNE automatically sets the correct language tags for better screen reader support.→ <html lang="en">
Semantics for tables:All <table> elements that are not used for data (e.g. layout tables) are automatically assigned role="presentation" or role="none".→ This prevents screen readers from reading out unnecessary structural information.
Button semantics:role="button" is automatically added to all interactive elements that are used as buttons - for better interpretation by screen readers.
Remove empty attributes:Automatic cleanup of empty alt="", title="" etc. to avoid misunderstandings for screen readers.
Automatic creation of accessible plain text versions:When you send via JUNE, a plain text version is sent automatically. This can then be displayed or downloaded by recipients in the mail client.
2. Images: Alt texts
Alt text field in the editor:
Users can decide for each image whether an alternative text should be set - or whether the image should be marked as "purely decorative".Alt text recognition:
The editor automatically checks whether images have an alt attribute. All empty attributes are automatically deleted to avoid misunderstandings with screen readers.
3. Export & Localization: Emails in the Right Language
Export with language option:
A specific language can be selected when downloading or exporting emails. This ensures that the lang attributes are set correctly - especially for multilingual campaigns.
The languages you can export here are the locales you have defined in advance. You can find more information on this topic here Multilingual Emails.
What you should consider as a user in order to send WCAG-compliant email campaigns
💡 WCAG = (Web Content Accessibility Guidelines)
1. Headlines
Use meaningful headings: Use <h1>, <h2> etc. for headings - and avoid simply working with styled <div> or <span> tags.you can easily use the rich text editor for this:
2. Semantic HTML
Use semantic HTML for text elements: Use <p> for paragraphs, <ul>/<ol> for lists and <blockquote> for quotations. Avoid purely visual tricks with no structural meaning: simply use "Paragraph" in the rich text editor for this too:
💡 To check your text, you can easily access the source code and check the HTML:
3. Checking the Color Contrasts
1. Recommended Tools:
How-to:
Copy the text color (e.g. #333333) and the background color (e.g. #FFFFFF) from your email design.
Paste both values into the tool.
Check whether the contrast ratio meets the WCAG 2.1 minimum requirements:
Normal text (under 18px): 4.5 : 1
Large text (at least 18px bold or 24px normal): 3 : 1
Notes if text only carries meaning via color (e.g. "red = error")
Checking the minimum font size (≥ 14px)
2. Use Browser Tools (for preview or live emails)
Open the email preview in the browser.
Open the developer tools (right-click → "Explore").
Select the text element.
Many browsers (e.g. Chrome) automatically display the contrast ratio in the Styles area - including a warning if the value is too low.
4. Automated "View in Browser" Link for Each Email
If you want to give your recipients the option of opening your email in a web browser (e.g. in the event of display problems or for accessibility), you can simply use a dynamic placeholder.
How-to:
Open your email editor.
Insert a rich text element at the desired position in your email (e.g. at the top or in the footer).
Enter the following text - or link any formulation to it:
<a href="[%=browserview%]">Im Browser ansehen</a>
💡 Alternatively, you can also integrate the placeholder into a button - depending on the design.
What does the placeholder do?
The placeholder [%=browserview%] is automatically replaced by an individual link pointing to the web-based version of the email when it is sent.
💡 Tip:
A common standard text is e.g:
"Problems with the display? <a href="[%=browserview%]">View here in the browser</a>"
Best Practice
💡 Use tools such as WAVE for additional quality control.
Conclusion:
With these new features, we want to make it easier for all users of our editor to create newsletters that are not only visually appealing - but also accessible to all recipients.
Accessibility is not a one-off feature, but an ongoing process. We look forward to your feedback so that we can continue on this path together!